Warum die Router-Verwaltung nach einer VPN-Änderung nicht mehr antwortet

Du hast eine Route oder eine Firewall-Regel geändert, um einen Tunnel auf dem Router zu testen, und jetzt antwortet die Admin-Seite nicht mehr von dem Laptop, der vor zehn Minuten noch einwandfrei funktionierte. Der Reflex ist, dem VPN die Schuld zu geben. Meistens ist der Tunnel gesund, und eines von drei anderen Dingen ist kaputt: keine Route zurück zur eigenen Adresse des Routers, eine Eingangsrichtlinie, die die Anfrage verwirft, oder ein Webdienst, der nicht auf der Adresse lauscht, die du aufrufst. Alle drei sehen im Browser gleich aus, deshalb starten Leute den Tunnel eine Stunde lang neu und lernen nichts.

Hier ist der Mythos, den man zuerst töten sollte: ein funktionierender Tunnel ist kein Weg zurück hinein. Er ist ein neuer Netzwerkanschluss mit eigenen Vertrauensfragen, und er kann deinen alten Verwaltungspfad still entfernen, während er einen neuen öffnet, den niemand geprüft hat.

Der Tunnel war nie der Verwaltungspfad

Weiterleitung und Eingang sind verschiedene Aufgaben. „Kann ein Client über den Tunnel das NAS erreichen?“ ist eine Weiterleitungsfrage zu Paketen, die durch den Router gehen. „Kann ich den SSH-Port des Routers öffnen?“ ist eine Eingangsfrage zu Paketen, die an den Router selbst adressiert sind. Eine Durchlassregel, die für weitergeleiteten Verkehr geschrieben wurde, tut für die zweite Frage nichts, und das ist der häufigste Grund, warum ein Tunnel, der Verkehr einwandfrei trägt, deine Admin-Sitzung trotzdem ablehnt.

Der umgekehrte Fehler ist, einem Schnittstellennamen zu vertrauen. Ein Tunnel ist zum Peer hin verschlüsselt, nicht zu jedem Dienst dahinter, und das Wort VPN in einem Schnittstellenlabel sagt nichts darüber, welchen Quellen die Anmeldung erlaubt sein sollte.

Ebene eins: Gibt es eine Route zur eigenen Adresse des Routers?

Beginne auf dem Client und frage den Kernel, wohin das Paket geht. Unter Linux gibt ip route get 10.6.0.1 die gewählte Route, die ausgehende Schnittstelle und die Quelladresse aus. Meldet es die Standardroute zu deinem Provider, gelangt das Paket nie in den Tunnel, und keine Regel auf dem Router kann es retten.

Die Tunnelseite hat ihre eigene Version der Frage. WireGuard behandelt AllowedIPs als Kryptoschlüssel-Routingtabelle: an jedem Ende erklärt sie, welche Quelladressen ein Peer verwenden darf und welche Ziele an diesen Peer gesendet werden. Enthält der Client-Eintrag die Tunneladresse des Routers nicht, hat der Client keine Route dorthin. Deckt der Server-Eintrag für diesen Client die Tunneladresse des Clients nicht ab, verwirft der Server das Paket, bevor irgendeine Firewall-Regel herangezogen wird.

Bestätige die genaue Adresse, die du erreichen willst, bevor du die Richtlinie debuggst. Ein veralteter DNS-Eintrag oder ein zwischengespeicherter Nachbareintrag von vor der Änderung schickt dich zu einer Adresse, die der Router nie besessen hat.

Ebene zwei: die Eingangsrichtlinie, nicht die Weiterleitungsrichtlinie

Firewalls bewerten Regeln auf der Schnittstelle, auf der das Paket ankommt. Bei pfSense und OPNsense entscheiden der Schnittstellen-Tab und die Regelreihenfolge, ob Verkehr zu den eigenen Diensten der Firewall erlaubt ist; eine Regel, die LAN-Clients ins Internet lässt, ist keine Regel, die einem Tunnel-Peer das Öffnen der Weboberfläche erlaubt. Bei OpenWrt mit firewall4 trägt jede Zone eine Eingangsrichtlinie, option input 'ACCEPT' oder 'REJECT', und eine Tunnelschnittstelle in einer Zone mit Eingang REJECT lehnt Verwaltungsverbindungen ab, während sie Verkehr weiterleitet, wenn Weiterleitung erlaubt ist.

Deaktiviere nicht die Anti-Lockout-Regel, damit der neue Pfad funktioniert. Diese Regel verhindert, dass die LAN-Verwaltungsadresse durch eine schlechte Regel ausgesperrt wird; sie schützt das LAN-Subnetz, nicht das Tunnel-Subnetz, das du gerade angelegt hast. Füge eine schmale Regel für die Administratorquelle hinzu und lass das Sicherheitsnetz in Ruhe. Die pfSense-Dokumentation zum Admin-Zugang erklärt, wo diese Steuerungen liegen.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Ebene drei: Lauscht überhaupt etwas auf dieser Adresse?

Ein Dienst kann laufen und trotzdem unerreichbar sein, weil er an eine Adresse gebunden ist. OpenWrts uhttpd führt ausdrückliche Listener-Einträge in /etc/config/uhttpd, zum Beispiel list listen_http '0.0.0.0:80'; ein Build, der nur an die LAN-Adresse bindet, nimmt nichts auf der Tunneladresse an, und Produkte mit einer Einstellung für die Lausch-Schnittstelle verhalten sich genauso. Die Listener-Befehle oben beantworten das direkt.

Trenne dann Ablehnung von Stille. nc -vz 10.6.0.1 443, das eine abgelehnte Verbindung zurückgibt, bedeutet, dass das Paket den Router erreicht hat und etwas es abgelehnt hat, entweder ein geschlossener Port oder eine ausdrückliche Ablehnungsregel. Ein Hängen bis zum Timeout bedeutet, dass das Paket verworfen oder nie geroutet wurde. Dieser Unterschied sagt dir, welche Ebene du als Nächstes prüfst, und er kostet fünf Sekunden.

Eine VPN-Schnittstelle ist eine Grenze, kein Wiederherstellungspfad

Verschlüsselung schützt die Leitung; sie sagt nichts darüber, wer die Admin-Seite öffnen darf. Wenn der Tunnel läuft, widerstehe der Versuchung, Erreichbarkeit zu lösen, indem du auf der Tunnelschnittstelle alles erlaubst. Gib Administratoren eine Regel, die an ihre eigene Tunneladresse gebunden ist, oder einen separaten Admin-Tunnel, und halte normale Nutzer, das NAS, die Kameras und die Familien-Laptops vom Verwaltungsport fern. Ein Peer, der eine Dateifreigabe braucht, sollte nicht eine Regel vom Router-Login entfernt sein.

Die Rolle des Routers ändert die Antwort. Ein Router, der den Tunnel terminiert, darf Administratoren legitimerweise von dort annehmen, während ein Router, der den Tunnel nur als Internetausgang nutzt, das normalerweise nicht sollte. In beiden Fällen ist die Subnetz-Erlaubnis nicht das Login, also lass Kontenauthentifizierung und Transportsicherheit aktiviert.

Der Ausgleichsschritt, den Leute nach einem Lockout machen, ist schlimmer: WAN-Verwaltung einschalten oder einen Port auf die Weboberfläche weiterleiten. Das macht aus einem kurzen Ausfall eine dauerhafte Exposition, und die Login-Seite ist dann für jeden Scanner im Internet erreichbar. Teste auch die abgelehnte Seite, nicht nur die erlaubte, damit ein Peer, der keinen Admin-Zugang haben sollte, in einen Timeout läuft oder abgelehnt wird, statt eine Login-Aufforderung zu bekommen.

Teste auch mit einer frischen Verbindung. Eine zustandsbehaftete Firewall hält bestehende Flows in ihrer State-Tabelle, deshalb kann die bereits offene SSH-Sitzung eine Änderung überleben, die jede neue Verbindung blockiert. So bleibt ein Lockout unsichtbar bis zum nächsten Neustart oder dem nächsten Schlaf des Laptops.

Bereite den Rückweg vor, bevor du die Richtlinie anfasst

Schreibe vier Dinge vor der ersten Änderung auf: wie du das Gerät erreichst, wenn der Tunnel stirbt, etwa über eine serielle Konsole, eine Provider-Konsole oder eine Maschine im LAN; wohin die aktuelle Konfiguration exportiert wird; welche einzelne Regel oder Route du ändern willst; und wie du genau diesen Punkt zurückrollst. Unter OpenWrt erfasst sysupgrade -b /tmp/backup.tar.gz die Konfiguration, und Änderungen bleiben ausstehend bis uci commit, was dir ein billiges Rückgängigmachen gibt, wenn du es rechtzeitig bemerkst. pfSense führt eine Konfigurationshistorie, und AutoConfigBackup hilft nur, wenn es bereits aktiviert war. Läuft der Router mit einem fail-closed-Regelsatz, prüfe, ob der geplante Wartungspfad nicht in dem Verkehr liegt, den diese Regel blockiert, und denke daran, dass ein Neustart dauerhafte Regeln erneut anwendet, statt sie zu löschen.

Ändere eine Grenze pro Versuch und teste dann von einer neuen Verbindung statt aus der Shell, die du offen hältst. Schlägt der Test fehl, mache diese eine Änderung rückgängig, bevor du die nächste Ebene anfasst. Der Tunnel kann die ganze Zeit oben bleiben, aber sein grünes Statussymbol ist kein Beweis dafür, dass du noch hineinkommst.

Schnelltest, bevor du gehst:

• Erreichst du den Router von einer Quelle aus, die nicht von der gerade bearbeiteten Regel abhängt?
• Erlaubt die Eingangsrichtlinie auf der Tunnelschnittstelle nur die Administratorquelle?
• Ist der Verwaltungsdienst an eine Adresse gebunden, die im Tunnel existiert?
• Hast du einen abgelehnten Peer und eine frische Sitzung getestet?
• Ist die WAN-Verwaltungsoberfläche noch geschlossen?