Router im VPN-Clientmodus: Warum LAN-Geräte verschwinden

Der Glaube, der Clientmodus selbst töte den LAN-Zugriff, führt Menschen in das falsche Einstellungsmenü, und die eigentlichen Ursachen sind meist zwei. Der Tunnel entfernt weder die LAN-Brücke noch hindert er kabelgebundene und kabellose Clients daran, einander zu erreichen. Was den lokalen Zugriff bricht, ist entweder eine Inspektionsfunktion im Weiterleitungspfad des Routers oder ein LAN-Adressbereich, der sich verschoben hat, als die Firmware es tat. Beide erzeugen dieselbe Beschwerde, und keine wird durch Neuinstallieren des VPN-Profils behoben.

Der Mythos und was der Clientmodus wirklich ändert

Der Clientmodus fügt eine Tunnelschnittstelle und eine Standardroute hinzu, die durch sie zeigt, und leitet dann LAN-Verkehr in diesen Tunnel weiter. Die Brücke zwischen den kabelgebundenen Ports und den Funkmodulen bleibt unberührt, ebenso das lokale Switching. Was sich ändert, ist die Richtlinie: welcher Verkehr weitergeleitet wird, wo er übersetzt wird und welchen Resolver die Clients erhalten.

Dieser Unterschied ist wichtig, weil ein defektes LAN normalerweise bedeutet, dass eine dieser drei Richtlinien geändert wurde, nicht dass der Router aufgehört hat, ein Switch zu sein. Ein Router, der noch seine eigene Verwaltungsseite beantwortet, beweist, dass die LAN-Schnittstelle lebt. Ein Router, der gar nichts beantwortet, hat ein anderes Problem, etwa eine geänderte LAN-Adresse oder einen Client im falschen Subnetz.

Der sinnvolle erste Schritt ist also herauszufinden, welche Schicht kaputt ist, nicht die Schicht zu ändern, die Sie vermuten.

Prüfen Sie drei Ziele, bevor Sie eine Einstellung anfassen

Prüfen Sie von einem kabelgebundenen Client aus drei Ziele getrennt und notieren Sie jedes Ergebnis: die eigene LAN-Adresse des Routers, ein anderes Gerät am selben Switch per IP und etwas, das nur über den Tunnel erreichbar ist. Gehen Sie in dieser Reihenfolge vor, weil jedes Ergebnis eine andere Schicht ausschließt. Verwenden Sie im ersten Durchgang Adressen statt Namen, da ein Namensfehler DNS in eine Konnektivitätsfrage mischt.

Das Muster der Antworten ist die Diagnose. Ein Router, der antwortet, während lokale Geräte es nicht tun, deutet auf lokales Switching oder eine Filterfunktion hin, nicht auf Routing. Lokale Geräte, die antworten, während die Tunnelseite es nicht tut, deuten auf die Tunnelroute oder die entfernte Firewall hin. Wenn alles per Adresse antwortet, aber Namen fehlschlagen, ist das eine Resolver-Frage, und keine Routenbearbeitung wird sie beheben.

Halten Sie die Tabelle neben den Testergebnissen. Sie verwandelt eine vage Beschwerde in eine Zeile, auf die Sie reagieren können.

Die Sicherheitsschicht im Weiterleitungspfad

Consumer-Router liefern zunehmend eine Inspektionsfunktion mit, die weitergeleiteten Verkehr beobachtet, und sie läuft in demselben Pfad, der Pakete vom LAN in den Tunnel trägt. Wenn diese Inspektion den Tunnelverkehr nicht klassifizieren kann, kann die Weiterleitung stocken, während der Tunnel selbst oben bleibt und der Router eine gesunde Verbindung meldet. Nichts im VPN-Protokoll zeigt dies, weil die VPN-Verbindung tatsächlich zustande kam.

Die Diagnose ist ein kontrolliertes Experiment, keine dauerhafte Änderung. Notieren Sie die aktuelle Einstellung, schalten Sie die Funktion für die Dauer eines Tests aus, bringen Sie den Tunnel wieder hoch und prüfen Sie einen einzelnen lokalen Host per Adresse. Weiterleitung, die zurückkommt, ist der Beweis, den Sie brauchten, und der Kompromiss wird dann eine Entscheidung statt einer Vermutung. Wenn sich nichts ändert, aktivieren Sie sie sofort wieder und gehen Sie zur Adressierungsursache über.

Eine bezahlte Sicherheitsfunktion deaktiviert zu lassen, damit ein Tunnel weiter funktioniert, ist ein Kompromiss, den man bewusst eingeht und aufschreibt. Es lohnt sich auch zu fragen, ob der Tunnel auf ein anderes Gerät gehört, denn ein Router, der alles inspizieren muss, und ein Router, der alles weiterleiten muss, sind zwei verschiedene Aufgaben.

Die zweite Ursache: Der LAN-Bereich hat sich verschoben

Firmware-Updates setzen die LAN-Adresse routinemäßig auf den Herstellerstandard zurück, und einige Router haben einen ausdrücklichen Modusschalter, der entscheidet, ob das LAN einen privaten Bereich behält oder einen vom übergeordneten Gerät erbt. Ein Client, der 192.168.8.x erwartet, kann auf 10.64.0.x landen, und dann läuft eine SSH-Sitzung zu einem Host ab, obwohl der Tunnel völlig gesund ist.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Lesen Sie Präfix und Gateway aus dem Lease, bevor Sie die Routerseite öffnen. Die ersten beiden Befehle zeigen, was der Client tatsächlich erhalten hat, und der dritte zeigt, welche Schnittstelle der Client für eine lokale Adresse verwenden würde, und so offenbart sich eine zurückgebliebene Route oder ein veraltetes Subnetz. Vergleichen Sie das dann mit der LAN-Seite und dem Modus, in dem der Router ist.

Wenn der Bereich nicht zurückkehren kann, aktualisieren Sie jedes Objekt, das ihn benennt: DHCP-Reservierungen, jede statische Route in das alte Subnetz und jede Firewallregel, die das vorherige Präfix trägt. Ein Bereich, der mit dem entfernten Subnetz des Tunnels kollidiert, ist die unangenehmere Variante, weil lokale Geräte erreichbar bleiben, während entfernte Ziele stillschweigend ins LAN fehlgeleitet werden.

Neu verbinden und in Paketreihenfolge erneut testen

Verbinden Sie nach einer der beiden Änderungen den Tunnel neu und wiederholen Sie die Prüfungen in Paketreihenfolge: Router, lokaler Host, entfernter Host, dann Namen, dann die Anwendung. Die Anwendung zuerst zu testen verbirgt, welche Schicht noch kaputt ist, und ein Browser-Wiederholungsversuch gegen einen zwischengespeicherten Namen kann wie ein Routingfehler aussehen.

Notieren Sie Firmwareversion, LAN-Präfix und den Zustand der Inspektionsfunktion neben dem VPN-Profil. Alle drei sind Konfiguration, die das nächste Update überschreiben kann, und zwei Zeilen Notizen sparen die Stunde, die Sie gerade verbracht haben.