GRE-Schreibfehler bei pptpd sind kein Passwortproblem

GRE-Schreibfehler im Protokoll, und der erste Instinkt ist, das Passwort des Benutzers zurückzusetzen. Dieser Instinkt ist fast immer falsch. Diese Meldungen beschreiben den Datenpfad, nicht die Anmeldedatenprüfung: Der Client hat sich möglicherweise erfolgreich authentifiziert und ist dann in der Phase steckengeblieben, in der er sich im Netz registriert. Zwei verschiedene Meldungen deuten auf zwei verschiedene Fehler hin, und keiner wird durch ein neues Passwort behoben.

Zwei Meldungen, zwei verschiedene Fehler

Ein Lesefehler bedeutet, dass die GRE-Pakete den Daemon nie erreichen oder auf dem Weg hinein verworfen werden. Die Steuerverbindung kann vollkommen gesund aussehen, während nichts den Datenpfad überquert. Die Authentifizierung ist das Einzige, was nachweislich funktioniert hat.

Ein Schreibfehler bedeutet meist, dass die Sitzung etwas ausgehandelt hat, das der Kernel oder der Client nicht nutzen kann. Der Steuerkanal wurde abgeschlossen, und die dabei vereinbarten Optionen passen nicht zu dem, was die Endpunkte tatsächlich können. Das ist eine Konfigurationsunstimmigkeit, kein Authentifizierungsereignis.

Lesen Sie, welche der beiden erscheint, bevor Sie etwas ändern. Sie führen Sie in verschiedene Schichten, und sie als ein Symptom zu behandeln ist der Grund, warum derselbe Server zweimal aus unzusammenhängenden Gründen gepatcht wird. Die Protokollzeile ist die einzige kostenlose Diagnose, die Sie bekommen.

Protokoll 47 ist nicht Port 47

PPTP nutzt TCP 1723 zum Aufbau des Rufs und GRE zum Transport der Nutzlast. GRE ist IP-Protokoll 47, keine Portnummer, daher erlaubt eine Firewallregel, die Port 47 öffnet, nichts Nützliches.

Ein Router auf dem Weg braucht eine PPTP-Passthrough-Funktion oder eine ausdrückliche GRE-Freigabe. Ohne sie wird der TCP-Handshake abgeschlossen, und der Tunnel überträgt nie ein Paket, was genau den obigen Lesefehler erzeugt. Port-47-Regeln in einer Firewall sind der am häufigsten verschwendete Nachmittag in diesem Protokoll.

Beobachten Sie beide Richtungen gleichzeitig auf dem Server, statt zu raten, welche Seite den Verkehr verwirft: tcpdump -ni any port 1723 or proto gre.

Wenn 1723 den Rufaufbau zeigt, während GRE stumm bleibt, liegt die Sperre oberhalb des Hosts. Wenn GRE ankommt und der Daemon weiterhin scheitert, ist das Problem lokal, und die Optionen sind die nächste Stelle.

Erlauben Sie GRE dort, wo der Host tatsächlich weiterleitet

Eine Forward-Regel für GRE einzufügen ist ein vernünftiger Test auf einem Host, der Tunnelverkehr weiterleitet, und keine Richtlinie. Eine Testregel, die alles eines Protokolls akzeptiert, ist eine Diagnose, kein Entwurf. Lassen Sie sie lange genug stehen, um etwas zu lernen, und ersetzen Sie sie dann durch eine eingegrenzte Regel.

Fügen Sie eine Input-Regel für Pakete hinzu, die an den Server selbst adressiert sind, weil die Forward-Kette sie nicht sieht. Beobachten Sie dann die Regelzähler vor und nach einem Verbindungsversuch, was Ihnen sagt, ob die Pakete überhaupt ankommen.

Machen Sie die Regel über den Firewalldienst der Distribution dauerhaft, statt sie nach jedem Neustart erneut auszuführen. Auf einem nftables-Host passen Sie ip protocol gre sowohl in der Input- als auch in der Forward-Kette an.

Stellen Sie sicher, dass das Modul ppp_generic ebenfalls geladen ist, und prüfen Sie, ob die Verbindungsverfolgung die Rückrichtung verwirft. Beides erzeugt Fehler, die wie ein Firewallproblem aussehen und keines sind. Ein fehlendes Kernelmodul sieht genau wie ein blockiertes Protokoll aus, bis Sie nachsehen.

Passen Sie die Optionen an den Client an, den Sie tatsächlich haben

Die Korrektur aus dem anderen Bericht steht in /etc/ppp/pptpd-options, wo das Rezept PAP, CHAP und MSCHAP ablehnt, die passenden require-Zeilen auskommentiert und zustandsbehaftetes MPPE behält. Dieses Rezept wurde für eine Clientmischung geschrieben, und blindes Kopieren bricht den Normalfall. Lesen Sie die Ablehnungszeilen als Aussage darüber, welche Clients der Autor hatte, nicht als Empfehlung.

Ein Windows-Client braucht normalerweise MS-CHAPv2 mit MPPE-128. Behalten Sie diese Anforderungen und entfernen Sie nur die Optionen, die der Client wirklich nicht aushandeln kann.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Verschlüsselung abzuschalten, damit eine Verbindung zustande kommt, ist eine Herabstufung, keine Reparatur. Testen Sie eine solche Variante an einer Laborstrecke und stellen Sie die Verschlüsselung wieder her, bevor der Dienst echten Clients begegnet. Die Verbindung, die unsicher funktioniert, ist schlechter als die, die ehrlich scheitert.

Lesen Sie die Fehlernummer des Clients

Der numerische Code des Clients grenzt die Phase schneller ein als das Serverprotokoll. Lesen Sie ihn, bevor Sie irgendetwas anderes lesen. 691 bedeutet, dass die Anmeldedaten abgelehnt wurden, 721 bedeutet, dass der Server nie geantwortet hat, und 619 bedeutet, dass die Verbindung abbrach. Zwei Minuten mit der Nummer sparen eine Stunde mit der Konfiguration.

Vergleichen Sie diesen Code mit dem Serverprotokoll, bevor Sie etwas bearbeiten, und testen Sie nach jeder Änderung erneut mit demselben Client. Sonst versteckt sich ein zweiter Fehler hinter dem ersten, und die Korrektur wirkt unwirksam.

Wenn die Anmeldung gelingt und kein Verkehr fließt, bleibt GRE der Verdächtige. Das ist der Moment, zum Mitschnitt zurückzukehren statt zum Anmeldedatenspeicher.