Warum PPP CHAP allein eine MPPE-Anforderung nicht erfüllen kann

Ein PPTP-Profil, das auf Verschlüsselung besteht, scheitert meist an derselben Stelle: PPP einigt sich auf einen Authentifizierungsaustausch, der nie das Schlüsselmaterial erzeugt, das MPPE braucht. Der Tunnel wirkt halb lebendig, das Passwort wird akzeptiert, und die Verbindung bricht ab, bevor Verkehr ihn überquert. Zum CHAP-Auswahlfeld zu greifen, bis irgendetwas verbindet, verbirgt den eigentlichen Defekt, und der ist ein Vertrag zwischen der Authentifizierungsmethode und der Schutzrichtlinie. Die folgenden Prüfungen sind so geordnet, dass jede eine billigere Ursache ausschließt als die nächste.

In einer PPTP-Verbindung laufen zwei Verhandlungen

PPTP trägt eine normale PPP-Sitzung in einem GRE-Tunnel, und beide verhandeln getrennt. Die äußere Schicht entscheidet, wie Pakete gekapselt werden und welcher Steuerkanal existiert; die innere PPP-Sitzung entscheidet, wer der Peer ist und welcher Schutz obenauf liegt. Eine Passwortabfrage beweist daher nur etwas über die innere Schicht, und ein abgeschlossener äußerer Handshake beweist nichts über eine von beiden. Profile scheitern hier, weil Leute den Tunnel debuggen, während die Uneinigkeit in PPP sitzt.

Einfaches CHAP ist der Challenge-Response-Austausch aus RFC 1994, aufgebaut auf einem gemeinsamen Geheimnis und nichts sonst. MS-CHAPv2 ist ein anderer Austausch mit anderen Nachrichten und einer anderen Ausgabe, standardisiert in RFC 2759. Das gemeinsame Wort in den beiden Namen ist das Einzige, was sie auf der Leitung gemeinsam haben. Keiner der Namen sagt, was der Austausch erzeugt, und genau das ist der einzige Teil, der zählt.

Deshalb ist eine schlicht CHAP genannte Option in einem alten Profil mehrdeutig. Wenn der Server MS-CHAPv2 will und der Client einfaches CHAP anbietet, kann die Verbindungskontrolle trotzdem abschließen und ein Passwort trotzdem akzeptiert werden. Der Fehler kommt später, wenn der Server Schutzschlüssel aus einem Austausch ableiten will, der keine erzeugt hat.

Passen Sie die verlangte Methode zu den Schlüsseln, die sie erzeugen kann

MPPE-Schlüssel sind keine Eigenschaft von PPP im Allgemeinen. Für die Microsoft-CHAP-Familie ist die Ableitung in RFC 3079 festgelegt, und sie nimmt als Eingabe die Ausgabe eines MS-CHAP-Austauschs statt eines gemeinsamen Geheimnisses. EAP-Methoden erreichen denselben Punkt auf einem anderen Weg, wobei der Authentifizierungsserver die Schlüssel als Attribute MS-MPPE-Recv-Key und MS-MPPE-Send-Key zurückgibt. Einfaches CHAP erscheint auf keinem der beiden Wege, und das ist der ganze Grund für die Fehlpaarung.

Eine Konfiguration, die MPPE verlangt und zugleich jede Methode ablehnt, die Schlüssel liefern kann, ist in sich widersprüchlich. pppd löst diesen Widerspruch, indem es die Verbindung ablehnt, nicht indem es Schlüssel erfindet, sodass das sichtbare Ergebnis eine Sitzung ist, die sich authentifiziert und dann in der Netzwerkphase endet. Ein erneuter Versuch des Clients ändert daran nichts, solange der Server die einzigen Methoden ablehnt, die etwas ableiten.

Die daraus folgende Regel ist kurz: Verlangt das Profil MPPE, muss die Methode eine MS-CHAP-Variante oder eine EAP-Methode sein, deren Schlüssel der Server zurückgibt. Nur MS-CHAPv2 abzulehnen erzwingt das nicht, denn MS-CHAPv1 leitet ebenfalls Schlüssel ab und bleibt verfügbar, solange es nicht separat abgelehnt wird; beide abzulehnen lässt einfaches CHAP und PAP übrig, die nichts ableiten und die Anforderung unerfüllbar machen. Benennen Sie die akzeptierte Methode ausdrücklich, statt die aufzulisten, die Sie nicht mögen. Die Verschlüsselungsanforderung fallen zu lassen, damit ein Client verbindet, ist ein Downgrade, keine Reparatur.

Lesen Sie die Optionen des Servers, bevor Sie einen Client bearbeiten

Die meisten dieser Fehlpaarungen sind auf dem Server in zwei Dateien sichtbar, und sie zu lesen kostet weniger als ein Client-Neuaufbau. Auf einem Linux-PPTP-Endpunkt liegen die relevanten Einstellungen in der pppd-Optionsdatei, die pptpd durchreicht. Führen Sie das auf dem Server aus, nicht von einem Client-Statusbildschirm. Beginnen Sie mit den Zeilen, die einen Schutzmodus verlangen, ablehnen oder benennen:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Lesen Sie die Ausgabe als Vertrag statt als Liste von Schaltern. Eine Zeile, die MPPE verlangt und zugleich beide MS-CHAP-Varianten ablehnt, kann kein Client erfüllen, und eine fehlende Anforderung für eine MS-CHAP-Methode lässt die Tür für Austausche offen, die keine Schlüssel liefern. Prüfen Sie dann, wer überhaupt authentifizieren darf, was die Secrets-Datei entscheidet:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Notieren Sie drei Werte, bevor Sie irgendetwas ändern: das äußere Protokoll, die vom Server verlangte Authentifizierungsmethode und ob der Schutz verpflichtend oder optional ist. Diese drei bestimmen jede spätere Entscheidung, und sie aus einem Client-Dialog zu raten, ist der Weg, auf dem ein Profil halb konfiguriert endet. Halten Sie die Datei geöffnet, während Sie arbeiten, denn der nächste Abschnitt braucht dieselben drei Werte.

Lokalisieren Sie den Fehler anhand der PPP-Phase

PPP meldet Fehler in Phasen, und die Phase sagt, welche Klausel des Vertrags gebrochen ist. Eine Verbindung, die die Verbindungskontrolle nie verlässt, hat ein Kapselungs- oder Verhandlungsproblem, während eine, die sich authentifiziert und dann stirbt, meist ein Richtlinien- oder Schlüsselproblem hat. Eine Verbindung, die oben bleibt und nichts trägt, ist zum Routing übergegangen, was eine andere Untersuchung ist.

Das Journal hält die Phasenzeilen fest, und sie sind nützlicher als ein höherer Debug-Level. Fragen Sie die PPP-Prozesse und die Schutzmeldungen ab, und lesen Sie dann das Authentifizierungsergebnis vor allem anderen. Die letzten Zeilen nennen meist die Klausel, die abgelehnt hat:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

Suchen Sie in dieser Ausgabe zuerst das Authentifizierungsergebnis und dann eine Beschwerde, dass Schutz verlangt, aber nicht ausgehandelt wurde. Die zweite Meldung ist die Signatur des obigen Widerspruchs, und kein noch so häufiges Wiederholen beseitigt sie, solange der Server die einzige Methode ablehnt, die Schlüssel erzeugen kann. Zwei Fallen sind erwähnenswert: den Debug-Level zu erhöhen, ohne die Phasenzeilen zu lesen, erzeugt Rauschen, und Challenge-Material oder Passwörter mitzuschneiden verwandelt eine Konfigurationsaufgabe in ein Zugangsdatenleck. Notieren Sie diese Phase, bevor Sie eine Option ändern.

Planen Sie den Ausstieg, bevor der alte Endpunkt abgeschaltet wird

MPPE ist ein historischer Mechanismus zum Schutz von Verbindungen, und seine Anwesenheit macht PPTP nicht zu einer vernünftigen Wahl für eine neue Bereitstellung. Die aktuelle Microsoft-Empfehlung rät bereits von PPTP und von L2TP/IPsec mit vorab geteiltem Schlüssel für neue Fernzugriffs-Rollouts ab. Einen Alt-Endpunkt am Leben zu halten, ist eine Entscheidung über einen bestehenden Dienst, keine Vorlage für den nächsten.

Wenn der Endpunkt bleiben muss, schreiben Sie den Vertrag auf: äußeres Protokoll, verlangte Authentifizierungsmethode, verpflichtender Schutz und die Client-Version, die ihn aushandelt. Wenn er gehen kann, wählen Sie die Gateway-Identität des Ersatzes, seine Client-Authentifizierung und den Ort für die Zugangsdaten, bevor Sie das alte Profil anfassen. Planen Sie dann Routen, DNS und die Ressourcen, auf die jeder Benutzer zugreifen darf. Validieren Sie den vorgesehenen Client gegen die Anforderungen des Eigentümers statt gegen eine funktionierende Verbindung.

Eine bewusste Ablehnung sollte eine Ablehnung bleiben, denn auf einen ungeschützten Modus zurückzufallen, damit ein Test besteht, verwandelt einen Richtlinienfehler in eine Bloßstellung. Der fertige Zustand ist ein unterstützter, dokumentierter Vertrag, nicht die kleinste Änderungsmenge, die eine alte Verbindung gelingen lässt. Lassen Sie das Alt-Profil an Ort und Stelle, ungenutzt und dokumentiert, bis der Ersatz dieselben Prüfungen besteht.