Warum dein Windows-VPN den lokalen Drucker tötet und wie du das stoppst

Verbinde das VPN, und der Drucker verschwindet, die NAS-Freigabe öffnet sich nicht mehr, und eine Remote-Desktop-Sitzung zum Rechner neben dir läuft in eine Zeitüberschreitung. Nichts ist kaputt. Der Client hat eine Standardroute hinzugefügt und besitzt nun jedes Ziel, das der Laptop benennen kann, auch die drei Meter entfernten. Das ist der ganze Mechanismus, und ihn einen VPN-Fehler zu nennen, macht aus einer Einzeiler-Korrektur einen Supportfall.

Lies zuerst die Routing-Tabelle

Bevor du etwas änderst, erfasse die IPv4-Tabelle mit route print -4 und behalte die Ausgabe. Verbinde dich, erfasse erneut und vergleiche die Zeilen 0.0.0.0: Die aktive Standardroute nennt eine Schnittstelle, und wenn diese Schnittstelle der Tunnel ist, gehen lokales Drucken und Surfen zuerst ins Büro.

Die Schnittstellennummer in der zweiten Spalte ist das, worauf eine permanente Route später verweisen muss, also notiere sie, solange der Tunnel steht. Sie ist auch der Wert, der sich ändert, wenn der Adapter neu erstellt wird, weshalb an sie gebundene Routen ihre Nützlichkeit still überleben können.

Entferne die Standardroute, drei Wege

Bei einem integrierten Windows-Profil ist die Steuerung ein Kontrollkästchen. Öffne die Eigenschaften der Verbindung, IPv4, dann Erweitert, und entferne Use default gateway on remote network; die neuere Einstellungen-App versteckt denselben Dialog eine Ebene tiefer. Aus einer erhöhten Eingabeaufforderung ist dieselbe Änderung ein Cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Ein OpenVPN-Profil funktioniert anders, weshalb sein Verhalten Leute verwirrt, die ein Kontrollkästchen erwarten. Seine redirect-gateway def1-Direktive ersetzt die Standardroute überhaupt nicht; sie installiert zwei Halbbereichsrouten, 0.0.0.0/1 und 128.0.0.0/1, die zusammen die Standardroute gewinnen, ohne sie zu löschen. Weil die ursprüngliche Standardroute überlebt, schickt ein Präfix, das auf net_gateway zeigt, nur dieses Präfix an den lokalen Router zurück. Dieses Detail erklärt, warum die Lösung für ein def1-Profil eine Präfixroute ist und kein Kontrollkästchen, das niemand findet.

Füge nur zurück, was zur Arbeit gehört

Ohne die Standardroute trägt der Tunnel nichts, also müssen die Arbeitspräfixe ausdrücklich benannt werden. Das Cmdlet, das ein Präfix an die Verbindung bindet, ist sicherer als eine permanente Route, weil es nur installiert wird, solange diese Verbindung steht, und nicht von einer Schnittstellennummer abhängt:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

Der ältere Ansatz funktioniert noch und steht noch in jeder Checkliste: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, mit dem eigenen Schnittstellenindex und der Gateway-Adresse des Tunnels. Er überlebt Neustarts, was der Sinn und auch die Gefahr ist, denn der Index kann beim nächsten Start zu etwas anderem gehören.

Metriken entscheiden den Rest. Wenn sowohl der physische als auch der Tunnel-Adapter eine Route für dasselbe Präfix beanspruchen, gewinnt die niedrigere Metrik, und die Metrik des Tunnels zu erhöhen ist eine legitime clientseitige Steuerung und kein Hack.

Wenn der Server für dich entscheidet

Ein Client, der dein Kontrollkästchen ignoriert, folgt meist einer Richtlinie. Cisco-Profile tragen eine Einstellung Allow Local LAN Access, und ein Headend kann eine Tunnel-all-Richtlinie pushen, die überschreibt, was der Client bevorzugen würde; in einem Pflicht-Tunnel gibt es keinen lokalen Schalter zum Umlegen. Lies das Client-Log nach gepushten Routen und Richtlinienzeilen, statt denselben Dialog erneut zu prüfen.

Dann sieh dir die Namensauflösung an, die ein vom Routing getrennter Schalter ist. Ein Split-Tunnel kann weiterhin einen internen Resolver und ein Suchsuffix erhalten, also ist ein lokales Gerät über die Adresse erreichbar und über den Namen unauffindbar, bis auch die DNS-Seite repariert ist.

Überschneidungen sind ein anderes Problem

Wenn das Heim-LAN und das Büro-LAN ein Präfix wie 192.168.0.0/24 teilen, kann keine Route sie auseinanderhalten. Jedes Paket für diesen Bereich hat ein einziges Nachschlageergebnis, und die Lösung ist, eine Seite neu zu nummerieren oder das Büro über eine übersetzte Adresse aus dem Pool zu erreichen. Mehr spezifische Routen hinzuzufügen verschiebt nur, welche Hälfte des Netzwerks bricht.

Schließe mit einer Prüfung statt fünf ab: verbinde dich und führe dann tracert gegen einen internen und einen öffentlichen Host aus. Der erste Hop sollte sich unterscheiden, und wenn er es nicht tut, ist die Trennung nicht vorhanden, egal was der Client meldet. Verbinde dich dann einmal neu und wiederhole es, denn gepushte Routen kehren mit jeder Sitzung zurück.