Warum eine breite VPN-Route einige öffentliche Websites bricht

Die meisten Seiten laden, zwei oder drei laufen in eine Zeitüberschreitung, und der Browser gibt der Verbindung die Schuld. Die Seiten, die scheitern, haben etwas gemeinsam, was die funktionierenden nicht haben: Ihre aufgelösten Adressen liegen in einem Präfix, das das VPN installiert hat. Eine Route, die weit genug ist, um einen öffentlichen Bereich abzudecken, erfasst Verkehr, den der Tunnel nie tragen sollte, und das Symptom sieht wie ein Website-Problem aus statt wie eine Routing-Entscheidung.

Lösen Sie den scheiternden Namen auf und schauen Sie dann in die Routing-Tabelle statt in den Browser.

Vergleichen Sie die Adresse, nicht den Websitenamen

Suchen Sie die Adresse, die der Client tatsächlich versucht hat, und prüfen Sie dann, welche Route dazu passt. Ein Ziel innerhalb von 45.61.20.10 fällt unter 45.0.0.0/8, wenn dieses Präfix vorhanden ist, obwohl die Website selbst nichts mit dem Tunnel zu tun hat. Die scheiternde Adresse mit den installierten Präfixen zu vergleichen, ist eine Subtraktionsaufgabe, keine Vermutung.

Windows kann beide Hälften direkt beantworten, und eine Abfrage zeigt, welche Schnittstelle und welcher nächste Hop die Auswahl gewonnen haben. Lösen Sie den Namen zweimal auf, wenn die Seite mehrere Adressen zurückgibt. Notieren Sie jede zusammen mit der passenden Route. Verschiedene Adressen können verschiedene Antworten liefern, und nur eine davon ist vielleicht der scheiternde Fall.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Lesen Sie das spezifischste passende Präfix, nicht die erste Zeile, die vertraut aussieht. Eine in der Tabelle vorhandene Route beweist nicht, dass sie die Abfrage gewonnen hat; das tut der längste Treffer. Zwei Präfixe können zu einer Adresse passen, und nur eines empfängt das Paket. Der Verlierer bleibt in der Tabelle und sieht in einer Auflistung genauso echt aus.

Notieren Sie das Präfix, seine Schnittstelle und die aufgelöste Adresse. Diese drei Werte sind die ganze Diagnose.

Finden Sie heraus, wer die Route installiert hat

Routen kommen von vier Stellen: dem nativen VPN-Profil, einer Verwaltungsrichtlinie, einem Verbindungsskript oder einem ganz anderen Client. Den aktiven Eintrag zu löschen kann seine Relevanz bestätigen, aber die nächste Verbindung erstellt ihn aus der gespeicherten Konfiguration neu, also muss die Quelle geändert werden.

Prüfen Sie zuerst die Routenliste des Profils, dann die Verwaltungsrichtlinie, dann jedes Skript, das beim Verbinden läuft. Diese Reihenfolge entspricht der Häufigkeit, mit der sich jeweils eines als verantwortlich erweist. Sie hält die Änderung außerdem auf einer Ebene statt auf dreien.

Lesen Sie das native klassenbasierte Verhalten sorgfältig

Native Windows-Profile haben eine dokumentierte Einstellung, NativeProfile/DisableClassBasedDefaultRoute, die eine automatische Route steuert, die aus der Schnittstellenadresse abgeleitet wird. Eine Profiladresse, die mit 45 beginnt, kann unter diesem Verhalten einen Eintrag 45.0.0.0/8 erzeugen, und so erfasst eine einzelne öffentliche Adresse einen ganzen Klasse-A-Bereich.

Der Eigenschaftsname lädt zur falschen Lesart ein: Auf true gesetzt, deaktiviert er die Ableitung, false aktiviert sie. Er ist auch nicht dasselbe Objekt wie eine Standardroute und steuert keine Drittanbieter-Clients, die ihre eigenen Präfixe installieren.

Wenn die Ableitung die nachgewiesene Ursache ist, korrigieren Sie das Profil über seinen Verwaltungseigentümer und geben Sie die vorgesehenen privaten Präfixe ausdrücklich an. Wenn ein Skript den Eintrag hinzugefügt hat, reparieren Sie das Skript. Eine unerklärte weite Route durch eine andere zu ersetzen, ändert das Symptom, ohne die Frage zu beantworten.

Reparieren Sie die Quelle und prüfen Sie dann beide Pfade erneut

Verbinden Sie sich nach der Änderung erneut und wiederholen Sie die Abfrage für eine scheiternde öffentliche Seite und für eine Ressource, die den Tunnel nutzen muss. Die erste sollte nun auf die physische Schnittstelle auflösen, und die zweite sollte weiterhin das VPN wählen. Bleiben Sie nicht beim ersten Erfolg stehen; eine Korrektur, die auch den privaten Zugriff bricht, hat einen Fehler gegen einen anderen getauscht.

Überprüfen Sie gleichzeitig den Adressplan des Servers. Ein Pool, der öffentlichen Raum überlappt, verursacht diese Art von Problem immer wieder. Ein Bereich, den der Betreiber bewusst gewählt hat, verdient ein anderes Gespräch, keine automatische Umnummerierung.

Die MTU zu erhöhen oder DNS zu leeren wird ein Präfix nicht korrigieren, das diese Adresse weiterhin in den Tunnel leitet. Prüfen Sie zuerst die Auswahl, dann den Pfad.