Windows-VPN-Fehlercodes: Welche Stufe gescheitert ist und was zu protokollieren ist

Öffnen Sie nach einem Fehler den Windows-VPN-Dialog, und er liefert Ihnen eine Nummer und einen Satz, wobei der Satz meist die weniger nützliche Hälfte ist. Die Nummer benennt die Stufe der Verbindung, die gescheitert ist, und die Stufe bestimmt, welches Log, welche Einstellung und welches Team Sie als Nächstes ansehen sollten. Die Stufen der Reihe nach durchzugehen dauert etwa zehn Minuten und verhindert die bekannte Abfolge aus Adapter-Neuinstallation, Protokollwechsel und Stack-Reset, um ein Konto zu reparieren, dem nie erlaubt wurde, sich einzuwählen.

Die Nummer als Stufe lesen

Eine native Verbindung durchläuft vier Meilensteine. Sie erreicht den Server und baut eine Strecke auf, sie handelt Sicherheit aus, sie authentifiziert den Benutzer, und sie wendet Adressierung und Routing an. Ein Fehler in jedem dieser Schritte hinterlässt andere Belege, und ein Code, der zu einer Stufe gehört, sagt nichts Nützliches über die anderen.

Der Fehler, den es zu vermeiden gilt, besteht darin, den Code als Schweregrad zu behandeln. Ein Streckenfehler und ein Autorisierungsfehler lesen sich beide als "Verbindung nicht möglich", und mehr haben sie nicht gemeinsam. Der Schweregrad sagt, wie dringend etwas ist; die Stufe sagt, was Sie öffnen sollen.

Stufe eins: die Strecke und der Einwahlversuch

829 bedeutet, dass die zugrunde liegende Strecke abgebrochen ist. Der Code sagt nicht, ob der entfernte Peer aufgehört hat zu antworten, ob eine Middlebox die Sitzung beendet hat oder ob eine Richtlinie auf dem Client sie geschlossen hat. Ein Einwahlabschluss-Code wie 703 liegt noch früher: Der Versuch kam nie so weit, eine Strecke zu haben, was meist auf das Profil, den Dienststatus oder eine lokale Richtlinie deutet.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

Die Ereignisabfrage ist der Teil, den Leute überspringen. Ein clientseitiger Eintrag mit Zeitstempel und Schnittstellennamen ist mehr wert als der Dialog, weil er sagt, ob der Versuch die Maschine überhaupt verlassen hat. Kein Eintrag und keine Antwort des Listeners ist ein Erreichbarkeitsproblem, und keine Client-Bearbeitung ändert daran etwas.

Wenn dasselbe Profil in einem anderen Netz funktioniert, hören Sie hier auf. Der Code beschreibt eine Pfadbedingung und keinen Konfigurationsfehler, und der nächste nützliche Vergleich sind die beiden Mitschnitte statt einer weiteren Neuinstallation.

Stufe zwei: PPP und die Miniport-Bindung

720 liegt zwischen der Strecke und dem Benutzer. Der Tunnel kam hoch, und dann konnte die PPP-Schicht weder eine Adresse noch ein Steuerprotokoll aushandeln, was oft ein Bindungsproblem auf dem Client ist und kein abgelehnter Anmeldedatensatz. Diese Unterscheidung ist der ganze Wert des Codes: Er sagt, dass die Anmeldedaten nie erreicht wurden, das Konto also nicht der Verdächtige ist.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Diese beiden Ausgaben zu lesen ist aufschlussreicher als irgendetwas zurückzusetzen. Ein Miniport, der vorhanden, aber nicht gestartet ist, oder eine Protokollbindung, die von anderer Software deaktiviert wurde, erzeugt genau das Scheitern dieser Stufe. Beides lässt sich beheben, ohne den Rest des Stapels anzufassen. Ein vollständiger Reset dagegen entfernt Adressierung und Filterzustand, die mit dem Fehler nichts zu tun hatten.

Stufe drei: Identität und Autorisierung

691 bedeutet, dass die Anmeldedaten abgelehnt wurden. 649 bedeutet, dass das Konto nicht einwählen darf, und 812 bedeutet, dass eine Fernzugriffsrichtlinie die Verbindung abgelehnt hat. Das sind Entscheidungen, keine Transportfehler, und der Client kann sie nur melden.

Die Belege liegen auf der anderen Seite. Fragen Sie den Gateway-Betreiber nach dem Versuch zu jenem Zeitstempel und nach der passenden Richtlinie; fragen Sie den Verzeichnisverantwortlichen, ob das Konto die Einwahlberechtigung hat und ob es in der von der Richtlinie geforderten Gruppe ist. Der Tunneltyp oder eine Neuinstallation des Clients kann eine Entscheidung über eine Identität nicht ändern.

Eine nützliche Gewohnheit auf dieser Stufe ist, die genaue Kontozeichenfolge ins Ticket zu schreiben, einschließlich eines eventuellen Domänenpräfixes. Überraschend viele 691-Fälle sind gespeicherte Anmeldedaten für die falsche Domäne, und das zeigt sich in der Kontozeichenfolge und nicht in den Protokolleinstellungen.

Stufe vier: verbunden, und nichts funktioniert

Eine Verbindung kann zustande kommen und trotzdem nutzlos sein. Sie hält eine Adresse, der Client meldet Erfolg, und jede Anfrage der Anwendung läuft in eine Zeitüberschreitung. Nichts im Dialog spiegelt das wider, und es gibt keinen Code zum Nachschlagen. An diesem Punkt ist der Dialog erledigt, und die nützlichen Belege liegen woanders.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Fehlt die Route, hat der Server sie nicht geschoben oder der Client sie verworfen. Existiert die Route und schlägt der Name fehl, ist die Auflösung das Problem. Funktionieren beide und die Anwendung scheitert weiterhin, sind Sie über den Tunnel hinaus und in der eigenen Konfiguration der Anwendung.

Halten Sie die Änderungen auf eine Schicht pro Test. Jede Bearbeitung vor dem nächsten Versuch wird Teil des Kontexts des nächsten Codes, und ein Code, der Ihre letzte Änderung beschreibt, ist schlimmer als gar kein Code.

Ein Versuch, eine Änderung, ein Protokoll

Welche Stufe auch immer, der Eintrag sollte den Code, die Meldung, den Profilnamen, den Zeitstempel und das Netz enthalten, in dem Sie waren. Fünf Felder, und jedes davon liegt bereits vor Ihnen im Dialog oder im Client-Log. Dieser Satz ist klein genug, um ihn in ein Ticket zu kleben, und konkret genug, dass jemand anders ihn nachvollziehen kann.

Legen Sie dann diesen Zeitstempel neben den Eintrag auf der anderen Seite. Die Tabelle oben auf dieser Seite sagt, welche Stufe zu welcher Abweichung gehört. Ohne den zweiten Eintrag engt der Code nur die Suche ein; mit ihm ist die Stufe entschieden. Der Vergleich ist es, der aus einer Nummer eine Diagnose macht statt einer Vermutung.

Diese Gewohnheit deckt fast jeden nativen Windows-VPN-Fehler ab, und keiner der Zweige verlangt eine Neuinstallation. Der Dialog hat Ihnen immer gesagt, welchen Sie haben; die Arbeit besteht darin, sich zu weigern, alle als dasselbe Problem zu behandeln.