Windows-VPN: gespeichertes Profil gegen den Zustand des aktiven Interfaces

Ein Windows-VPN erscheint an zwei Stellen, die unterschiedliche Fragen beantworten, und ihre Verwechslung erzeugt eine selbstsichere falsche Diagnose. Das gespeicherte Profil sagt, was jemand konfiguriert hat; das aktive Interface sagt, was der Stack gerade angewendet hat. Wenn eine Verbindung aufgebaut wird und der Verkehr trotzdem den falschen Weg nimmt, müssen beide Ansichten gelesen werden, in genau dieser Reihenfolge. Keine von beiden allein sagt Ihnen, ob das Paket der Anwendung durch den Tunnel verlassen hat.

Zwei Ansichten desselben Tunnels

Die Profilansicht ist Konfiguration: Serveradresse, Tunneltyp, Authentifizierungsmethode, Einstellungen für den geteilten Tunnel. Sie kann korrekt sein, während die Verbindung sie ignoriert, und sie kann veraltet sein, während die Verbindung einwandfrei funktioniert, weil ein Client, der sich neu verbindet, das von Ihnen Bearbeitete möglicherweise nicht erneut liest. Die Interfaceansicht ist angewendeter Zustand: welche Adapter existieren, welche Adressfamilien sie tragen, ihre Metriken und ihr Verbindungszustand. Sie ändert sich, wenn Tunnel kommen und gehen, was sie zum richtigen Ort für eine Frage zum laufenden Routing und zum falschen Ort für eine Konfigurationsfrage macht.

Beide zusammen zu lesen ist die ganze Methode, und nur eine davon zu lesen ist der Weg, auf dem Menschen einen gesunden Adapter löschen. Die folgenden Befehle erzeugen beide Ansichten, ohne etwas zu ändern.

Lesen Sie beide Ansichten, ohne etwas zu ändern

Beginnen Sie mit den gespeicherten Profilen, denn das ist die billigste Tatsache, die sich bestätigen lässt. Notieren Sie den Tunneltyp und den Wert für den geteilten Tunnel, da beide entscheiden, welche Ziele überhaupt in den Tunnel gelangen sollen. Ist das Profil falsch, korrigieren Sie es über seine unterstützte Konfigurationsfläche, denn nichts in der Interfaceliste repariert ein Profil, das auf ein falsches Gateway zeigt.

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

Die Interfaceansicht hat eine andere Form: Ein Tunnel kann zwei Zeilen belegen, wenn er beide Adressfamilien trägt. Lesen Sie den Index als Identität und den Alias als eine Bezeichnung, die jemand gewählt hat, und erwarten Sie, dass sich der Alias zwischen Clientversionen ändert.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

Anwesenheit ist kein Beweis für Nutzung, denn ein Interface kann existieren, verbunden sein und trotzdem nicht dasjenige sein, das die Route zu Ihrem Ziel auswählt. Behalten Sie das im Kopf, bevor Sie einen unbekannten Adapter für den Fehler halten. Diese beiden Fehler sehen von außen identisch aus: ein korrektes Profil mit einer Route, die es nie nutzt, und ein falsches Profil mit einer Route, die es nutzt. Sie haben völlig unterschiedliche Korrekturen, und deshalb gibt es den nächsten Abschnitt.

Folgen Sie der Route zum Ziel

Fragen Sie den Stack, welchen Weg er für die Adresse nehmen würde, die die Anwendung tatsächlich kontaktiert. Das ist die Frage, die die Interfaceliste allein nicht beantworten kann.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

Der erste Befehl meldet zwei lesenswerte Felder: den Interfacealias der ausgewählten Quelle und den nächsten Hop für dieses Ziel. Der Index 37 im zweiten Befehl ist das, was die erste Ausgabe ausgegeben hat, keine zu kopierende Konstante, und die Adresse 10.60.20.10 ist illustrativ. Wenn die gewählte Quelle zum physischen Adapter gehört, während das Ziel innerhalb des Tunnels liegen sollte, haben Sie das Auswahlproblem gefunden, denn das VPN-Interface kann vollkommen gesund und einfach nicht bevorzugt sein. Eine Metrik ist nur ein Teil dieser Entscheidung, da Routenspezifität, Richtlinie und Interfacezustand alle mitwirken.

Vergleichen Sie drei Zustände unter gleichen Bedingungen

Halten Sie die Interfaceliste und die gewählte Route vor dem Verbinden, während der Verbindung und nach dem Trennen fest, jedes Mal mit demselben Ziel und denselben Befehlen. Dieser Vergleich trennt ein aktuelles Tunnelinterface von einem alten versteckten Adapter, den eine Deinstallation hinterlassen hat, und von einem zweiten Client, der ebenfalls läuft. Er sagt Ihnen auch, ob das Tunnelinterface sauber verschwindet, denn ein Adapter, der nach dem Trennen bestehen bleibt, ist ein anderes Problem als einer, der nie erschienen ist. Ohne die drei Momentaufnahmen sieht jeder unbekannte Alias wie der Schuldige aus.

Bewahren Sie die drei Ausgaben beim Ticket auf, denn zwei Befehlsausgaben schlagen einen Absatz Beschreibung. Ein Kollege kann sie vergleichen, ohne Ihre Sitzung überhaupt zu wiederholen.

Löschen Sie nicht, was Sie nicht identifiziert haben

Unbekannte Adapter gehören meist zu etwas: einem verwalteten Client, einem virtuellen Switch, einem Containernetzwerk oder einem Sicherheitsagenten. Einen zu löschen kann eine funktionierende Komponente entfernen und das ursprüngliche Symptom genau dort lassen, wo es war. Ist die Route veraltet, finden Sie den Eigentümer der Route und beheben Sie sie dort; ist das Profil falsch, bearbeiten Sie das Profil. Die Dokumentation zu Get-NetIPInterface listet die oben verwendeten Felder auf, einschließlich der Metrik- und Zustandsspalten, die den Vergleich aussagekräftig machen.

Benennen Sie das Objekt, finden Sie seinen Eigentümer und handeln Sie dann an diesem Eigentümer. Alles andere ist das Umbenennen des Problems statt seines Lesens.