Die Verbindung authentifiziert sich, der Client meldet verbunden, und eine Sekunde später schließt das Protokoll mit LCP vom Peer beendet. Diese Zeile stammt aus der PPP-Aushandlung im GRE-Tunnel, der Transport funktionierte also bereits, und beide Seiten waren sich über die Verbindungsoptionen uneinig. Passwörter und Serveradressen sind hier meist unschuldig. Die Verschlüsselungsrichtlinie ist das Erste, was verglichen werden sollte, und unter Linux ist die pppd-Peer-Datei die erste Anlaufstelle.

Was der LCP-Fehler über die PPP-Phase aussagt

PPTP verpackt PPP in GRE: Die TCP-1723-Kontrollverbindung baut den Anruf auf, GRE trägt die Nutzlast, und dann handelt LCP Optionen wie das Authentifizierungsprotokoll, Kompression und MPPE aus. Der Peer beendet LCP, wenn eine erforderliche Option auf seiner Seite nicht akzeptabel ist. Ein Protokoll, in dem der CHAP- oder MSCHAPv2-Austausch abgeschlossen wird und LCP unmittelbar danach endet, ist eine Richtlinienablehnung, kein Erreichbarkeitsfehler. Erreicht der Tunnel gar keine Aushandlung, prüfen Sie pppd und dessen Plugin, bevor Sie die LCP-Zeile lesen.

Zwei Voraussetzungen werden leicht übersehen. Die pppd-Binärdatei muss vorhanden sein, und das in der Peer-Datei genannte PPTP-Plugin muss installiert sein; ein fehlendes Paket beendet den Anruf, bevor irgendeine Option besprochen wird.

Aktivieren Sie MPPE auf der Seite, die es verlangt

Die eigentliche Entscheidung ist, welche Seite die Verschlüsselungsrichtlinie besitzt. Ein Client kann MPPE anbieten, verlangen oder ablehnen, und der Server trifft dieselbe Wahl. Wenn beide es verlangen, kommt die Verbindung zustande; wenn eine Seite es verlangt und die andere ablehnt, endet LCP.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Laden Sie das Modul mit modprobe ppp_mppe vor dem Wählen, denn ohne es schlägt require-mppe-128 fehl. Unter Windows ist die entsprechende Einstellung die Registerkarte Sicherheit des VPN-Eintrags, wo dem Client gesagt werden muss, dass er Verschlüsselung verlangen soll, statt alles zu akzeptieren, was der Server anbietet. Wenn der Server LCP weiterhin beendet, fragen Sie dessen Betreiber, ob MPPE verpflichtend, optional oder deaktiviert ist, denn ein Client kann keinen Schutz aushandeln, den der Server ablehnt. Verschlüsselung abzuschalten, damit die Meldung verschwindet, ist die falsche Richtung: Sie entfernt den einzigen Schutz, den dieses Protokoll hat.

Speichern Sie die funktionierende Peer-Datei, bevor Sie sie bearbeiten. Eine falsch getippte require-mppe-Zeile erzeugt denselben allgemeinen LCP-Fehler und schickt Sie an den Anfang zurück.

Lesen Sie pppd’s eigenes Protokoll statt des Applets

Desktop-Applets zeigen die Trennung und verbergen den Grund, also lesen Sie den Bericht des Daemons über einen Versuch. Auf systemd-Systemen landet die Meldung im Journal; ältere Setups schreiben in die traditionellen Protokolldateien.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Durchsuchen Sie ein Fenster um einen einzelnen Anruf statt eines ganzen Tages voller Wiederverbindungen, damit die abgelehnte Option leicht zu erkennen ist. pppd nennt normalerweise die Option und die Antwort des Peers, was Ihnen sagt, ob Sie Ihren eigenen Vorschlag ändern oder die Serverseite bitten sollten, ihre Anforderung zu lockern. Halten Sie Versuche mit Zeitstempeln fest, denn zwei Protokolle zu vergleichen ist nur nützlich, wenn Sie wissen, welche Zeilen zu welchem Anruf gehören. Taucht gar kein LCP-Austausch auf, sitzt der Fehler früher in der Kette, und MPPE ist nicht der Verdächtige.

Die Korrektur über Wiederverbindungen erhalten: Hook-Namen und MTU

Sobald die Verbindung steht, entscheiden zwei Details, ob sie eine Wiederverbindung übersteht. Hooks liegen in /etc/ppp/ip-up.d und /etc/network/if-up.d, und beide Verzeichnisse werden von run-parts verarbeitet, dessen Dateinamenfilter alles mit einem Punkt ablehnt. Ein Skript namens set-pptp.sh wird daher übersprungen, während set-pptp ausgeführt wird. Prüfen Sie den Namen, bevor Sie den Inhalt des Skripts debuggen, und setzen Sie dann die kleinere MTU aus diesem Hook heraus, damit jede neue ppp-Schnittstelle sie ohne manuellen Befehl erbt.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Um eine Sitzung absichtlich zu beenden, zielen Sie auf die von pppd protokollierte pid, statt Prozessnamen per Muster zu treffen, denn alles abzuschießen, was ppp enthält, reißt auch unabhängige Verbindungen nieder. PPTP ist veraltet und MS-CHAPv2 ist schwach, also behandeln Sie diese Prüfungen als Wartung für eine Verbindung, die weiterlaufen muss, nicht als Grund, PPTP irgendwo neu einzusetzen.

Ähnliche Artikel