Eine an einen Schnittstellenindex gebundene VPN-Route bricht beim Neuverbinden

Die Route funktionierte wochenlang und begann dann, Datenverkehr ins Nichts zu schicken, während das Ziel unverändert blieb und nichts bearbeitet wurde. Geändert hat sich die Nummer: Eine Route, die gegen einen bestimmten Schnittstellenindex angelegt wurde, verweist auf einen Adapter, den es nach einem Neuverbinden nicht mehr gibt, und das Zielpräfix zeigt weiter auf eine Infrastruktur, die ersetzt wurde. Dauerhaftigkeit zu diesem Befehl hinzuzufügen hilft nicht, denn das Problem war nie, ob die Route einen Neustart übersteht. Die Lösung besteht darin, die Absicht an die Verbindung zu binden, die Adapterwechsel konstruktionsbedingt übersteht.

Prüfen Sie, worauf die Route tatsächlich zeigt

Lesen Sie zuerst den Routeneintrag und die Adapter nebeneinander. Eine Route mit einem nächsten Hop auf der VPN-Schnittstelle und einem Index, der zu keinem aktuellen Adapter passt, ist die Signatur dieses Fehlers; dasselbe Präfix auf einem anderen Index ist entweder ein Überbleibsel oder die Route, die Sie tatsächlich wollen. Lesen Sie beide Listen, bevor Sie eine davon ändern, denn der interessante Vergleich ist der zwischen der Nummer in der Route und den Nummern, die derzeit existieren. Erscheint der Index der Route in der Adapterliste, ist der Index nicht Ihr Problem, und die Suche verschiebt sich auf Metriken, Richtlinie oder die Gegenseite. Erscheint er nicht, muss nichts weiter diagnostiziert werden: Die Route hängt an einer Infrastruktur, die es nicht mehr gibt.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

Die Spalte Store unterscheidet einen Eintrag, der Neustarts übersteht, von einem, der mit dem Adapter verschwindet, und dieser Unterschied entscheidet, ob der Fehler morgen wieder auftritt. Ein Eintrag im persistenten Speicher, der auf einen verschwundenen Index zeigt, ist der schlimmste Fall, denn er übersteht Neustarts, ohne jemals zu irgendetwas zu passen.

Binden Sie das Präfix an das Profil, nicht an den Adapter

Ein natives Windows-VPN kann seine eigene Routenliste mitführen, sodass die Verbindung den richtigen Adapter wiederverwendet, wann immer sie hochkommt. Die Route folgt dann dem Profil statt einer Nummer, die Sie einmal beobachtet haben, und kein Skript muss nach jedem Wählversuch einen Index raten. Das Hinzufügen eines Präfixes lässt sich auch über das passende Entfernungs-Cmdlet rückgängig machen, was die Änderung nachvollziehbar hält. Das Präfix wird mit der Verbindung gespeichert statt in einem Startskript, sodass ein auf einen anderen Benutzer kopiertes Profil die Absicht mitbringt.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

Die Referenz zu Add-VpnConnectionRoute dokumentiert die Zuordnung zur Verbindung, und der Umfang des Telefonbuchs ist wichtig: Ein Profil pro Benutzer und ein Profil für alle Benutzer sind verschiedene Objekte. Dieser Mechanismus gehört zum eigenen VPN-Client von Windows, daher kann ein Herstelleradapter, der von seinem eigenen Dienst verwaltet wird, seine Routen aus einer ganz anderen Richtlinienquelle beziehen.

Räumen Sie alte Routen auf, bevor Sie die neue hinzufügen

Zwei Routen mit demselben Präfix und verschiedenen Eigentümern sind schlimmer als eine falsche Route, denn der Gewinner hängt von Metriken ab, die niemand notiert hat. Prüfen Sie, was für das Präfix bereits existiert, einschließlich Einträgen im persistenten Speicher, und entfernen Sie nur, was zum gescheiterten Versuch gehört. Ein Überbleibsel aus einem früheren Entwurf ist hier üblich, da die scheiternde Route meist etwas ersetzt hat, das funktionierte. Notieren Sie vor dem Entfernen, welche Einträge zu welcher Verbindung gehören, und halten Sie die Liste im Änderungsnachweis fest.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Gleichen Sie Präfix, nächsten Hop, Speicher und Eigentümer gemeinsam ab, statt alles zu löschen, was ähnlich aussieht. Eine andere Verbindung kann legitimerweise von einem Teil dieses Bereichs abhängen, und ein pauschales Löschen macht aus einer sauberen Reparatur einen Supportfall.

Verbinden Sie sich in einer anderen Reihenfolge neu

Reproduzieren Sie die Bedingung, statt zu hoffen, der erste Versuch sei repräsentativ gewesen. Trennen Sie die Verbindung, verbinden Sie sich neu und bestätigen Sie den gewählten Pfad zur selben entfernten Ressource, während der Tunnel steht; bei mehreren VPNs bringen Sie diese in einer anderen Reihenfolge hoch und beobachten, ob sich der gewählte Pfad ändert. Die Reihenfolge ist die Variable, die die meisten überspringen, und sie ist es, die eine an die falsche Verbindung gehängte Route aufdeckt.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

Das gewünschte Ergebnis ist nicht, dass ein Adapter seine Nummer einmal behält. Es ist, dass die Route mit welcher Nummer auch immer die Verbindung erhält jedes Mal erscheint und verschwindet, wenn die Verbindung schließt. Zweimal neu zu verbinden ist der billigste Weg, diese Ergebnisse auseinanderzuhalten.

Wissen Sie, was die Route nicht kann

Eine Profilroute liefert einen Pfad und sonst nichts. Sie öffnet keine entfernte Firewall, erzeugt keine Rückroute auf der Gegenseite und löst nicht zwei Standorte mit demselben Adressbereich auf; jedes davon ist eine eigene Konfiguration mit eigenem Eigentümer. Den Pfad zu bestätigen ist daher der Anfang des Abnahmetests und nicht der ganze Test.

Halten Sie die Präfixliste beim Profil und notieren Sie, unter welchem Umfang es hinzugefügt wurde, damit die nächste Person den beabsichtigten Entwurf lesen kann, statt ihn aus einer Routentabelle zu erraten. Routen, die nur in jemandes Erinnerung existieren, sind die, die nach dem nächsten Neuverbinden falsch neu aufgebaut werden. Ein einzeiliger Kommentar in den Bereitstellungsnotizen kostet weniger als ein Nachmittag des erneuten Entdeckens.