PPTP-Split-Tunneling funktioniert nicht: Reparieren Sie zuerst den GRE-Pfad

Beobachten Sie, wie eine PPTP-Verbindung hochkommt, und man glaubt leicht, der schwierige Teil sei erledigt: Der Client authentifiziert sich, ein ppp0-Adapter oder WAN-Miniport erscheint, und das Statusfenster wird grün. Dann läuft die erste Anfrage an einen internen Host in eine Zeitüberschreitung, und das Profil wird beschuldigt. In der Praxis sind zwei unabhängige Schichten zu klären: der äußere Transport, der TCP 1723 und GRE trägt, und die innere Richtlinie, die entscheidet, welche Ziele die PPP-Schnittstelle nutzen. Ein grüner Status beweist nur, dass die erste Schicht ausgehandelt wurde; über die zweite sagt er nichts.

Verfolgen Sie den Client vom Profil bis zum Kontroll-Socket

Öffnen Sie das Client-Log und finden Sie die Stelle, an der er den Server kontaktiert. PPTP öffnet zuerst eine TCP-Verbindung zu Port 1723 und handelt die Tunnelparameter über diesen Kanal aus. Scheitert dieser Schritt, ist alles Weitere belanglos, und die Fehlermeldung nennt meist die Serveradresse oder eine Zeitüberschreitung.

Bestätigen Sie die Kontrollverbindung auf der Leitung, bevor Sie eine Route anfassen. Auf dem Client oder einem Mirror-Port erfassen Sie TCP 1723 für einen Verbindungsversuch:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Ein abgeschlossener Handshake und eine aufgebaute Sitzung bedeuten, dass der äußere Kontrollkanal funktioniert. Ein SYN, das nie ein SYN-ACK bekommt, deutet auf eine Firewall, eine falsche Serveradresse oder einen Anbieter hin, der den Port filtert. Ein Handshake mit sofortigem Reset bedeutet oft, dass der Server die Anmeldedaten oder den Tunneltyp abgelehnt hat.

GRE ist ein zweites Protokoll, kein Port

PPTP trägt die PPP-Nutzlast in erweitertem GRE, IP-Protokoll 47, das keine Portnummer hat, die ein Router verfolgen könnte. Deshalb kann eine Regel, die TCP 1723 erlaubt, den Tunnel trotzdem ohne Datenpfad lassen. Stateful-NAT-Geräte müssen die Call-ID in GRE verstehen, um Antworten zurückzubilden, und viele tun das nicht. Die PPTP-Spezifikation hält Kontrollkanal und GRE-Nutzlast als getrennte Teile, und Ihr Testplan muss das auch tun.

Achten Sie in derselben Aufzeichnung auf Protokoll 47 und vergleichen Sie dann, was hinausgeht, mit dem, was zurückkommt:

sudo tcpdump -ni any 'proto gre' -c 20

Pakete, die ohne Antworten hinausgehen, während TCP 1723 gesund bleibt, sind die klassische Signatur eines blockierten GRE. PPTP-Passthrough auf einem Consumer-Router ist eine Funktion genau dieser Firmware, ein funktionierendes Hotelnetz beweist also nichts über das nächste. Bietet der Router kein Passthrough und können Sie ihn nicht ändern, ist die Protokollwahl das Problem, nicht die Routentabelle.

Beweisen Sie, dass der Tunnel ein Paket bewegt

Sobald GRE fließt, weist die PPP-Aushandlung der Client-Schnittstelle eine Adresse zu. Lesen Sie die Zuweisung, statt sie anzunehmen:

ip -4 addr show ppp0

Pingen Sie die Peer-Adresse, die als Ziel der Punkt-zu-Punkt-Verbindung angezeigt wird. Eine Antwort an dieser Stelle beweist, dass der gekapselte Pfad durchgängig funktioniert und dass der Server innerhalb des Tunnels antwortet. Antwortet der Peer, interne Hosts aber nicht, ist der äußere Transport in Ordnung, und der Fehler ist nach innen gewandert.

Tun Sie dies, bevor Sie eine Split-Route hinzufügen. Eine Routenänderung bei defektem Transport erzeugt eine zweite Variable und verdeckt die erste.

Schreiben Sie die Split-Richtlinie, DNS eingeschlossen

Split-Routing ist eine Liste von Entscheidungen, kein Kontrollkästchen. Jedes private Präfix, das den Tunnel passieren muss, braucht eine Route über die PPP-Schnittstelle, und jedes Präfix, das lokal bleiben muss, muss darin fehlen. Eine Route zu einem Anwendungssubnetz ohne passende Route zu dessen privatem Resolver ist ein häufiger Weg, einen Ausfall zu erzeugen, der wie eine kaputte App aussieht.

Prüfen Sie die Entscheidung, die der Kernel für je eine Adresse pro Kategorie trifft:

ip route get 10.20.5.10
ip route get 203.0.113.25

Die erste sollte ppp0 nennen, die zweite das gewöhnliche Gateway. Nennen beide dieselbe Schnittstelle, ist die Richtlinie überhaupt nicht gesplittet. Fügen Sie die eigene Adresse des DNS-Servers zur Tunnel-Liste hinzu, sonst verlässt die Namensauflösung für interne Hosts den lokalen Resolver und liefert nichts Brauchbares.

Eine wiederholbare Prüfung in fünf Schritten

Führen Sie die Schichten der Reihe nach aus und halten Sie bei der ersten an, die scheitert: Kontrollkanal, GRE-Sichtbarkeit, PPP-Peer-Antwort, Split-Route für eine interne Adresse und eine Anwendungsanfrage über den Tunnel. Jeder Schritt hat seinen eigenen Befehl, sodass ein Fehler zuordenbar statt mysteriös ist.

Eine kompakte Version für einen Linux-Client sieht so aus:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Unter Windows gilt dieselbe Reihenfolge mit route print und dem im Client angezeigten Adapterstatus. PPTP ist ein Altprotokoll, und wenn der Server SSTP oder IKEv2 anbietet, ist ein Wechsel meist eine bessere Zeitnutzung als das Tuning eines Pfads, der davon abhängt, dass Protokoll 47 jeden Hop passiert. Prüfen Sie Zertifikat und Authentifizierungsvertrag des Ersatzes, statt ein altes Profil in eine neue Version zu kopieren.