VPN blockiert lokales LAN unter Windows: Route oder Client-Richtlinie?

Ein Drucker, ein NAS oder eine Entwicklungsmaschine auf dem eigenen Schreibtisch antwortet nicht mehr in dem Moment, in dem sich das Arbeits-VPN verbindet. Manchmal behebt ein Routenbefehl das in Sekunden; manchmal ist dieselbe Route korrekt und die Pakete verschwinden trotzdem, was bedeutet, dass Sie ein anderes Problem mit ähnlichem Symptom vor sich haben. Die Entscheidung läuft auf drei Fragen hinaus, und sie in der falschen Reihenfolge zu stellen, ist der Grund, warum Menschen einen ganzen Abend damit verbringen, Routen zu löschen und wieder hinzuzufügen.

Drei Fragen vor jedem Befehl

Erstens: Gibt es einen Eintrag für das lokale Präfix, und zeigt er auf den physischen Adapter? Zweitens: Erhält der Client beim Verbinden eine Freigabe oder Ablehnung für das lokale Netzwerk vom Gateway? Drittens: Brauchen Sie nur ausgehenden Zugriff auf das LAN, oder muss auch etwas im Internet einen Dienst erreichen, der auf Ihrem Rechner läuft?

Die erste Frage trennt einen Routingfehler von einem Filterfehler. Die zweite sagt, ob eine Routenkorrektur überhaupt wirken darf. Die dritte ändert die Reparatur: Eine Route behebt ausgehenden Verkehr, während ein unerreichbarer eingehender Dienst meist ein Listener-Binding- und Rückwegproblem ist, das eine Route verschlimmert.

Frage eins: Route, Filter oder Name

Lesen Sie die Tabelle, bevor Sie etwas hinzufügen. Der Schnittstellenindex ist wichtig, denn jeder Routenbefehl unten ist daran verankert:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Ein direkt angeschlossenes Subnetz behält normalerweise eine On-Link-Route, auch während der Tunnel aktiv ist, sodass ein Eintrag existieren kann und der Verkehr trotzdem scheitert. Diese Kombination ist die Signatur eines Filters, der nach dem Routing läuft, und das ist der Fall, in dem eine zweite, spezifischere Route überhaupt nichts ändert.

Testen Sie Adresse und Name getrennt. Wenn ping 192.168.1.50 antwortet und net view 192.168.1.50 nicht, war die Routing-Tabelle nie das Problem: Der Tunnel hat den Resolver geändert, und der lokale Name wird nicht mehr aufgelöst. Dafür eine Route hinzuzufügen, ist verschwendete Arbeit.

Frage zwei: Erlaubt das Gateway den Zugriff auf das lokale LAN?

Ein kommerzieller Client installiert mehr als Routen. Er erhält beim Verbinden eine Richtlinie, und diese Richtlinie kann eine ausdrückliche Freigabe für das lokale Netzwerk enthalten. In Cisco-IPsec-Bereitstellungen trägt die Gruppenrichtlinie die Split-Tunneling-Einstellung und ein separates Flag für den Zugriff auf das lokale LAN; das Kontrollkästchen im Client ist eine Anfrage, die das Gateway ablehnen kann. In AnyConnect steuert das Profil die Split-Einschluss- und -Ausschlusslisten und dieselbe Freigabe. Unter Windows RRAS sind die Entsprechungen die Option für das Standardgateway im Profil plus die statischen Routen, die der Server zuweist.

Ist das Flag aus, ist das dokumentierte Verhalten, dass der Client den Verkehr zum direkt angeschlossenen Subnetz blockiert, obwohl eine gültige, spezifischere Route existiert. Deshalb können auch Routen, die dem Client nicht gehören, Sekunden nach dem Hinzufügen verschwinden: Der Client baut den Zustand neu auf, den er aufbauen sollte, und kämpft nicht gegen Sie.

Das Client-Protokoll zeichnet die Entscheidung beim Verbinden auf, und es zu lesen ist schneller als jedes Experiment am Rechner. Sagt das Protokoll, dass der lokale Zugriff blockiert ist, hören Sie auf: Keine Befehlszeilenkorrektur überlebt das, und es bleiben nur eine Richtlinienänderung, der Zugriff auf die Ressource durch den Tunnel oder das Einsperren des Clients in eine virtuelle Maschine und das Belassen des Hosts im lokalen Netzwerk.

Frage drei: Welche Richtung brauchen Sie?

Ausgehender Verkehr zu einem nahen Gerät ist eine Routingfrage. Richten Sie das LAN-Präfix mit einer Metrik auf das lokale Gateway, die niedrig genug ist, um die Standardroute des Tunnels zu schlagen:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Die zweite Form bindet ein einzelnes Gerät fest, was Sie wollen, wenn eine Adresse die ganze Anforderung ist. Das netsh-Äquivalent zeichnet dieselbe Entscheidung über den Schnittstellennamen statt über den Index auf:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Routenbefehle scheitern mit Der Parameter ist falsch, wenn Adresse und Maske nicht zusammenpassen, zum Beispiel eine Hostadresse mit einer /24-Maske. Verwenden Sie die Netzwerkadresse für eine Subnetzroute und eine Hostmaske für einen einzelnen Host.

Eingehend ist anders. Ein VNC- oder SSH-Server auf derselben Maschine wird unerreichbar, wenn Antworten auf eine eingehende Verbindung über das VPN-Gateway hinausgehen und nie zurückkehren. Prüfen Sie, worauf der Dienst lauscht, bevor Sie Routen anfassen:

netstat -ano | findstr :5900

Ein Listener, der an eine bestimmte Adresse gebunden ist, antwortet nicht auf der anderen Schnittstelle. Ihn an alle Schnittstellen zu binden, ist eine bewusste Entscheidung, getroffen zusammen mit einer Firewallregel, die auf das von Ihnen vertraute Netzwerk beschränkt ist. Erst danach stellt die Routenreparatur den Rückweg wieder her.

Wenden Sie die kleinste passende Änderung an

Der andere übliche Schritt ist, „Standardgateway im Remote-Netzwerk verwenden“ in den erweiterten IPv4-Eigenschaften zu deaktivieren. Das hält den Internetverkehr lokal, tut aber zwei Dinge gleichzeitig: Das VPN ist nicht mehr der Standardweg, und der Client erhält keine Routen mehr für das Remote-Netzwerk, einschließlich Multicast. Deaktivieren Sie es, und das entfernte LAN verschwindet, es sei denn, der Server schiebt die spezifischen entfernten Präfixe, die jeder Client braucht.

Diese Asymmetrie entscheidet die Reihenfolge der Arbeit. Wenn die Gegenseite vollständig erreichbar bleiben muss, schieben Sie entfernte Subnetze vom Server und lassen Sie den lokalen Standard in Ruhe. Wenn Sie den Server nicht ändern können, fügen Sie eine dauerhafte Route zum entfernten Präfix über die Adresse hinzu, die der Tunnel zugewiesen hat, und prüfen Sie mit route print, dass das Präfix auf die VPN-Schnittstelle zeigt, während der Standard weiterhin auf das physische Gateway zeigt.

Bestätigen Sie dann, dass die Reparatur eine erneute Verbindung übersteht, denn nicht dauerhafte Routen sterben mit dem Adapter, und ein Skript, das nach jeder Verbindung läuft, ist der ehrliche Ort dafür. Testen Sie ein lokales Gerät und eine entfernte Ressource in derselben Sitzung, trennen Sie die Verbindung, verbinden Sie erneut und testen Sie wieder. Wenn das lokale Gerät weiterhin scheitert, während die Route richtig aussieht, gehen Sie zu Frage zwei zurück: Der Client filtert, und die Antwort ist eine Richtlinienänderung statt einer zweiten konkurrierenden Route.