Ich habe die zentrale Routerfunktion von einem Allroundrouter auf einen dedizierten x86-Rechner mit OpenMPTCProuter verlagert. VLANs und Dienste wurden schrittweise übernommen, zwei WANs und ein VPS angebunden und die Übergangsadressen später bereinigt.

 

Die bisherige Architektur ist hier beschrieben

n

n

Warum ich die Architektur geändert habe

Mein Ziel war, zwei Internetanschlüsse gemeinsam zu nutzen, den LAN-Kern zu beschleunigen und Routing und WLAN voneinander zu trennen. Die rechnerische Gesamtbandbreite war dabei zunächst ein Zielbild und kein automatisch belegtes Messergebnis.

Der bisherige Router sollte weiterhin als WLAN-Access-Point und gegebenenfalls als Layer-2-Verteiler dienen. Ein dedizierter Rechner übernahm die Routingfunktion. Dabei musste ich Hardware, Netzwerkpfade, VLANs und die bestehenden Dienste gemeinsam betrachten.

Der Zielaufbau

Die beiden Internetanschlüsse führen getrennt zum OpenMPTCProuter. Eine weitere Schnittstelle dient als LAN- und VLAN-Trunk. Der Router verbindet das lokale Netz über einen Tunnel mit einem VPS. Dadurch können mehrere Pfade genutzt werden, ohne dass jeder einzelne Datenstrom automatisch einen vollständigen Bonding-Nachweis liefert.

Die vorhandenen VLANs blieben erhalten. Ich ergänzte die Firewall schrittweise und übernahm WireGuard nur dort, wo es für die neue Architektur sinnvoll und überprüfbar war.

 

n

n

Schrittweise Vorbereitung statt Gesamtrestore

Ich habe die Umstellung zunächst parallel vorbereitet. Dabei wurden WANs, VLANs, Firewall, Monitoring, WireGuard, Gaming-Netzwerk und DHCP getrennt betrachtet. Übergangsadressen ermöglichten Tests, ohne sofort alle Routerfunktionen umzuschalten.

nnnn

Ein altes Backup war dabei eine wichtige Informationsquelle, aber kein fertiges Restore-Image für die neue Architektur. OMR-eigene Dienste und Regeln mussten erhalten bleiben; nicht mehr benötigte Komponenten habe ich bewusst nicht übernommen.

Ausschnitt aus dem AP-Umbau

# Ausschnitt aus dem AP-Umbau des Cudy
for interface in wan wan2 wan6; do
if uci -q get "network.${interface}" >/dev/null 2>&1; then
uci set "network.${interface}.proto=none"

for option in ipaddr netmask gateway dns metric; do
uci -q delete "network.${interface}.${option}" || true
done
fi
done

Ergebnis und verbleibende Grenzen

OpenMPTCProuter arbeitet als produktiver Gateway. Die alten Übergangsadressen wurden entfernt, die VLANs verwenden die vorgesehenen Gateways und der Multi-WAN-/Bonding-Betrieb wurde im laufenden Betrieb erfolgreich verifiziert.

Offen bleiben getrennte Themen wie einzelne DHCP-Prüfungen, Gaming-Regeln und Konfigurationsreste. Eine spätere Firewall- oder 10-GbE-Erweiterung bleibt eine mögliche Option, ist aber kein abgeschlossenes Ergebnis dieser Migration.

Was ich aus der Migration mitnehme

Die wichtigste Erkenntnis ist, dass eine Routermigration nicht mit dem Einspielen einer Konfiguration endet. Ich muss jede Funktion einzeln zuordnen, Übergänge kontrollieren und nach jeder Änderung prüfen, ob die übrigen Dienste weiterhin erreichbar sind.

Welche Grenzen und Erfahrungen habe ich für Codex und ChatGPT mitgenommen

Bei der Migration haben sich einige Themen ergeben, die aufgrund meiner Prompts und durch die Grenzen von ChatGPT 5.4  aufgefallen sind.

Besonders ärgerlich sind die diversen Fehler die ChatGPT und Codex machen bei der Analyse und bei den Vorschlägen von Befehlen.

So muss man immer wieder insbesondere die Chatoberfläche darauf hinweisen welche Tools nicht verfügbar sind. Das beste Beispiel hier ist, die Änderung von OpenWRT von OPKG auf APK.

Aber auch die Tatsache, dass die gesamte grafische Oberfläche von Codex als Obsolet angesehen wurde beim OpenWRT Systemupgrade war in der Nachinstallation sehr zeitraubend.

Deshalb ist es zwingend erforderlich jeden Befehl und jedes Skript noch einmal selbst zu prüfen und nicht blind auf die KI zu vertrauen