PPTP verbindet und hängt dann hinter Linux NAT: der GRE-Helfer

Jemand leitet 1723 weiter, der Client erreicht den Server, die Authentifizierung beginnt, und dann bleibt alles ohne Fehler stehen. Der naheliegende Schluss ist ein falsches Passwort, also wird das Passwort dreimal neu eingetippt. Die Weiterleitung war in Ordnung, und die Zugangsdaten waren in Ordnung. Kaputt ist ein zweites Protokoll, das die Weiterleitung nie abdeckte, und eine Kernel-Voreinstellung, die stillschweigend aufhörte, dabei zu helfen.

Die Weiterleitung war nie das Problem

Eine Portweiterleitungsregel beschreibt TCP- oder UDP-Verkehr. Sie kann keine Nutzlast beschreiben, die mitten in einer Sitzung auf ein anderes IP-Protokoll umschaltet, und PPTP tut genau das.

Deshalb sieht die Verbindung gesund aus, bis zu dem Moment, in dem sie hängt. Der Teil, den eine Portregel steuern kann, war erfolgreich, und der Teil, den sie nicht steuern kann, ist der Teil, der versagt hat.

TCP für die Steuerung, GRE für die Daten

Der Ruf wird über TCP 1723 ausgehandelt. Sobald er steht, wandert die Nutzlast in GRE, IP-Protokoll 47, das überhaupt keine Portnummern trägt. Eine Regel, die auf Ports abzielt, hat nichts zum Abgleichen.

Was GRE trägt, ist eine Rufkennung in seinem Header, und ein NAT-Übersetzer muss dieses Feld in beiden Richtungen konsistent umschreiben, sonst hören die beiden Hälften der Sitzung auf, übereinzustimmen. Eine Richtung umgeschrieben und die andere nicht ergibt eine Sitzung, die sich authentifiziert und dann jedes Datenpaket verwirft. Genau das ist die Form des Symptoms: Erfolg, dann Stille.

Nacktes GRE ohne PPTP braucht kein solches Umschreiben, weshalb ein einfacher GRE-Tunnel durch einen Router funktionieren kann, der für einen PPTP-Client auf demselben Pfad versagt.

Vier Module und ein sysctl, das sie abschaltete

Zwei Module übernehmen das Framing, nf_conntrack_proto_gre und nf_nat_proto_gre. Zwei weitere übernehmen die Rufkennung, nf_conntrack_pptp und nf_nat_pptp. Das Laden des letzten zieht die übrigen über Abhängigkeiten mit, eine Modulliste sollte also alle vier zeigen.

Ältere Anleitungen verwenden ein ip_-Präfix aus der 2.6-Ära. Diese Befehle können so aussehen, als liefen sie, während sie nichts laden, prüfen Sie also die geladene Liste statt des Exit-Status.

Geladen zu sein reicht nicht mehr. Seit Linux 4.7 ist der sysctl net.netfilter.nf_conntrack_helper standardmäßig 0, was die automatische Helfer-Zuweisung für neue Flows abschaltet. Ein Router kann jedes Modul haben und trotzdem nichts übersetzen. Prüfen Sie den effektiven Wert, bevor Sie die Modulliste erneut ansehen.

Schalten Sie die automatische Zuweisung global wieder ein, oder hängen Sie den Helfer an die Flows, die ihn brauchen, und lassen Sie alles andere in Ruhe:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

Die zweite Option ist die vorzuziehende. Sie beschränkt das Verhalten auf PPTP-Verkehr, statt die automatische Zuweisung routerweit wieder zu aktivieren.

Ein Protokoll öffnen, das keine Ports hat

Eine Firewall-Regel, die 1723 erlaubt, sagt nichts über Protokoll 47. Erlauben Sie unter firewalld das Protokoll in der Zone, die zum Client zeigt. Akzeptieren Sie unter einfachem iptables das Protokoll gre in der INPUT-Kette.

Dann zeichnen Sie auf beiden Seiten auf. Pakete, die den Client verlassen, ohne dass Antworten ankommen, bedeuten, dass der Rückweg gefiltert wird, und das ist ein anderer Fehler als abgelehnte Zugangsdaten.

Nach dem Verbinden die Größengrenze

GRE fügt einen Header ein, und PPP darin fügt mehr hinzu, sodass eine funktionierende Verbindung eine MTU deutlich unter 1500 meldet. Kleine Antworten laden, große bleiben hängen, was wie ein zweites, unabhängiges Problem aussieht, das in dem Moment auftaucht, in dem das erste gelöst ist.

Lesen Sie die MTU am PPP-Adapter des Clients und gleichen Sie sie mit der eigenen Berechnung des Routers ab statt die Zahlen zu senken, bis irgendetwas funktioniert. Pakete in voller Größe, die hinausgehen, ohne dass etwas zurückkommt, deuten auf diese Grenze und nicht auf die Übersetzung.

Den Pfad zu reparieren bringt den Nutzer zum Laufen, und es macht PPTP nicht zu einer guten Wahl. MS-CHAPv2 und RC4 sind längst veraltet, behandeln Sie das Laden der Module also als vorübergehende Korrektur und planen Sie den Wechsel zu einem gepflegten Protokoll.