PPTP-Fehler 800 gegen 812 und Abbrüche nach einer Minute

Fehler 800, Fehler 812 und ein PPTP-Tunnel, der nach einer Minute stirbt, sind drei getrennte Störungen. Ordnen Sie jedes Symptom der Schicht zu, die tatsächlich versagt hat.

Drei Fehlermeldungen von einem PPTP-Client beschreiben meist drei verschiedene Störungen. Fehler 800 bedeutet, dass der Tunnel nie zustande kam, Fehler 812 bedeutet, dass der Server die Authentifizierungsmethode abgelehnt hat, und ein Abbruch nach einer Minute ist ein Keepalive-Timer, der entscheidet, dass ein gesunder Peer verschwunden ist. Jede Stufe scheitert aus ihrem eigenen Grund, also braucht jede ihre eigene Prüfung.

Fehler 800 bedeutet, dass der Tunnel nie zustande kam

Windows meldet Fehler 800, wenn es den Tunnel überhaupt nicht aufbauen kann, und der Text über einen nicht erreichbaren Server oder ungeeignete Sicherheitsparameter ist eine Zusammenfassung und keine Diagnose. PPTP braucht zwei getrennte Dinge vom Netzwerk, bevor irgendein Anmeldedatum geprüft wird. TCP 1723 trägt den Steuerkanal, und IP-Protokoll 47, GRE, trägt die gekapselte Nutzlast.

Testen Sie diesen äußeren Pfad von außerhalb Ihres eigenen LAN, denn eine Verbindung, die im Büro funktioniert, beweist nichts über den Rand:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Antwortet 1723 und bleibt die Aufzeichnung leer, während der Client eine Verbindung versucht, lässt der Pfad Protokoll 47 fallen. Ein Router mit weitergeleitetem 1723, aber abgeschaltetem PPTP-Passthrough erzeugt genau dieses Muster: Der TCP-Handshake wird abgeschlossen, dann verschwinden die GRE-Pakete, sodass der Fehler wie ein Anmeldedatenproblem aussieht, obwohl kein Login versucht wurde.

Richten Sie die Weiterleitung auf die aktuelle LAN-Adresse des Servers, aktivieren Sie PPTP-Passthrough, wo der Router es anbietet, und wiederholen Sie den Versuch vom selben äußeren Punkt. Wenn GRE vorgelagert gefiltert wird und Sie das nicht ändern können, hat SSTP über TCP 443 oder L2TP/IPsec über UDP 500 und 4500 bessere Chancen als jede Änderung, die Sie auf der Windows-Seite vornehmen können.

Fehler 812 ist die Ablehnung Ihrer Authentifizierungsmethode durch den Server

Fehler 812 kommt zurück, nachdem der Tunnel steht, deshalb fühlt er sich wie ein Passwortproblem an. Der Server weist die für die Verbindung ausgehandelte Authentifizierungsmethode zurück, nicht unbedingt das Passwort selbst. Öffnen Sie auf dem Client den VPN-Eintrag, gehen Sie zur Registerkarte Sicherheit, setzen Sie den Typ auf Point-to-Point Tunneling Protocol, wählen Sie die explizite Protokollliste und setzen Sie ein Häkchen bei Microsoft CHAP Version 2.

Sie können die aktuelle Einstellung lesen, ohne sich durch den Dialog zu klicken:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Ein Server, der MS-CHAP v2 verlangt, weist einen Client ab, der auf PAP oder auf einem automatischen Typ belassen wurde, der etwas Schwächeres aushandelt, und der Fehler kommt, bevor irgendein Benutzerpasswort bewertet wird. Das Kontenformat ist die andere Hälfte derselben Ablehnung. In einem Fall sandte Windows eine Microsoft-Kontoidentität der Form MicrosoftAccount\[email protected], während der Server ein lokales oder Domänenkonto wollte. Das Eingeben von SERVERNAME\username sagte Windows, welchen Kontospeicher es abfragen soll, und beseitigte den Fehler. Geben Sie den Namen von Hand ein, statt gespeicherte Anmeldedaten ein früheres Format wiederholen zu lassen.

Abbrüche nach einer Minute sind eine Keepalive-Entscheidung

Wenn der Tunnel sich verbindet, etwas Datenverkehr durchlässt und sich dann trennt, schauen Sie sich das LCP-Echo-Verhalten des Servers an, bevor Sie den Client anfassen. Der Daemon bittet den Peer regelmäßig zu bestätigen, dass er noch da ist. Kommen im konfigurierten Budget zu wenige Antworten an, wird die Sitzung abgebaut, obwohl der Benutzer noch eine funktionierende Verbindung hat.

Auf einem Linux-pptpd-Server stehen diese Werte in /etc/ppp/options.pptpd, und die übliche Reparatur ist, das Budget zu erweitern statt das Intervall zu verkürzen:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Dreißig Fehlschläge bei einem Intervall von fünf Sekunden verzeihen eine kurze Stockung, statt den Peer für verschwunden zu erklären. Zählt man auf eins oder zwei herunter, wird gewöhnliches Jitter auf einem übersetzten Pfad etwa jede Minute zur Trennung. Ist Ihr Server Windows RRAS statt pptpd, sehen Sie sich stattdessen das PPP-Sitzungs-Timeout und die Richtlinie zum Trennen bei Leerlauf an. Die liegen woanders, und eine pppd-Datei zu bearbeiten, die es nicht gibt, ändert nichts.

Überlappende Subnetze brechen den Datenpfad

Ein PPTP-Tunnel kann sauber authentifizieren und dennoch nichts erreichen, wenn beide Standorte denselben privaten Bereich verwenden, zum Beispiel 192.168.1.0/24 im Büro und zu Hause. Der Client kann nicht sagen, welchen Host eine gegebene Adresse meint, und manche Stacks weigern sich, die Route überhaupt zu installieren, statt eine auszuwählen.

Behandeln Sie das als Entwurfsfehler und nummerieren Sie eine Seite neu, oder geben Sie dem Client einen bewusst übersetzten Zugriffsbereich. Das Debuggen des PPTP-Clients kann einen Adressraum nicht reparieren, der zweimal existiert, und das Symptom wird weiter wie ein zufälliger Abbruch aussehen.

Beginnen Sie mit der Stufe, die versagt hat: GRE für 800, die Methode und Kontenzeichenfolge für 812, Echo-Einstellungen für einen Tunnel, der nach Zeitplan stirbt.

Ähnliche Artikel