Warum bleiben PPTP und L2TP/IPsec vor der Benutzernamenabfrage stehen?
Keine Benutzernamenabfrage bedeutet, dass PPP nie gestartet ist, also liegt der Fehler in Transport, Schlüsselaustausch oder Tunnelaufbau. Prüfen Sie die Reihenfolge der Stufen, bevor Sie neu installieren.
Eine fehlende Benutzernamenabfrage ist ein diagnostisches Geschenk: PPP ist noch nicht gestartet, also wurden Konto, Passwort und Domänenrichtlinie noch nicht befragt. Bei einer PPTP- oder L2TP/IPsec-Verbindung fragt der Client erst nach Zugangsdaten, wenn der Tunnel besteht und der Server eine PPP-Sitzung begonnen hat. Alles, was vor diesem Moment scheitern kann, ist Transport, Schlüsselaustausch oder Tunnelaufbau, also eine weit kleinere Fläche als „das VPN ist kaputt“.
Eine fehlende Abfrage verengt den Fehler auf drei Stufen
Notieren Sie die letzte Stufe, die sichtbar gelungen ist, denn jede hat einen anderen Verantwortlichen und eine andere Lösung. An den Kontoeinstellungen zu raten, während Sie zwei Stufen früher festhängen, ist die Art, wie ein Nachmittag verschwindet.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Ein Client, der ohne Abfrage ausläuft, hat nie eine IPsec-Assoziation erhalten, der Fehler liegt also in IKE oder darin, ob Ihre Pakete das Gateway überhaupt erreichen. Einer, der meldet, er prüfe Zugangsdaten, und dann abbricht, kam weiter, als die Meldung vermuten lässt. Eine Abfrage mit anschließender Ablehnung ist PPP-Authentifizierung und gehört in einen Kontoartikel, nicht in diesen.
Stufe eins: das Protokoll, das eine Firewall still verwirft
PPTP braucht TCP 1723 für den Steuerkanal und IP-Protokoll 47 für den Datenpfad, und beide reisen getrennt. Viele Netze leiten 1723 weiter und verwerfen Protokoll 47, was einen Tunnel ergibt, der aushandelt und dann gar nichts trägt. Ein Router mit NAT braucht außerdem eine GRE-fähige Durchleitung, und ein Zugangsweg nur über IPv6 kann PPTP unter keiner Konfiguration tragen.
L2TP über IPsec verbraucht Port 500 für IKE und Port 4500 für NAT-Traversal, verpackt dann den L2TP-Verkehr selbst in 1701, während ESP die geschützte Nutzlast trägt, sobald die Assoziation besteht. Erlauben Sie die beiden Steuerports, aber nicht ESP, und Sie erhalten genau das Symptom aus dem Titel: sichtbarer Fortschritt, dann ein toter Client vor jedem Zugangsdaten-Dialog. Ein Test über einen Handy-Hotspot ist ein billiger Weg, ein Client-Problem von einem Wegproblem zu trennen.
Stufe zwei: ein Schlüssel, der nicht der Schlüssel ist, ein Vorschlag, der nicht angeboten wird
Ein nicht passender vorab geteilter Schlüssel scheitert schnell und still, und die übliche Version ist ein Schlüssel, der auf dem Bildschirm richtig aussieht, aber einen eingefügten Zeilenumbruch oder ein Leerzeichen am Ende trägt. Auf einem Linux-Client ist der Dialog nicht unbedingt die Quelle der Wahrheit: Das L2TP-Plugin von NetworkManager hält Geheimnisse in Dateien unter /etc/ipsec.d/, und eine ältere Datei pro Verbindung, die /etc/ipsec.secrets noch einschließt, wird statt der gerade getippten verwendet. Kopieren Sie diese Datei an einen sicheren Ort, nehmen Sie sie aus dem Include-Pfad, und tippen Sie den Schlüssel dann von Hand neu.
Die andere Hälfte dieser Stufe ist der Vorschlag. Beide Enden müssen sich auf denselben Phase-1-Algorithmensatz einigen — Verschlüsselung, Integrität und Diffie-Hellman-Gruppe — und auf passende ESP-Transformationen für Phase 2, sonst entsteht die Assoziation gar nicht. Ein Gateway, das nur 3DES, SHA1 und MODP1024 anbietet, lehnt einen Client ab, der für stärkere Algorithmen eingerichtet ist, und sein Log nennt die abgelehnte Transformation. Das Log nennt die Unstimmigkeit, wenn Sie es lesen, statt den Dienst erneut neu zu starten. Statt einen Algorithmus-String aus einem Forenbeitrag zu kopieren, fragen Sie das Gateway, welche Transformationen es wirklich aushandeln wird: ike-scan auf seine Adresse gerichtet liefert die Transformationen, die es aushandeln wird. Ist das einzige Angebot Kryptografie, die Ihre Richtlinie nicht mehr zulässt, gehört die Korrektur zum Gateway und nicht in ein Downgrade des Clients.
Unter Windows liegen Schlüssel und Authentifizierungsmethode im VPN-Profil, und eine Unstimmigkeit zeigt sich vor der Zugangsdatenabfrage statt danach. Wo der Empfänger ein Windows Server ist, prüfen Sie, ob die Remotezugriffsrolle installiert ist, ob das Zertifikat zu dem Namen passt, mit dem Clients sich verbinden, und ob kein Portfilter enger ist als die oben genannten Protokolle.
Stufe drei: der Tunnel besteht und PPP startet nie
Wenn IKE abgeschlossen ist und die Abfrage trotzdem nie erscheint, schauen Sie auf den Tunnel-Daemon statt auf die Firewall. L2TP braucht etwas, das auf UDP 1701 lauscht — xl2tpd oder kl2tpd unter Linux, den Remotezugriffsdienst unter Windows — und ein installierter, aber gestoppter Dienst sieht von der Client-Seite aus wie ein verworfenes Paket. Prüfen Sie den Listener, bevor Sie Regeln erneut öffnen, die Sie schon verifiziert haben. Danach muss PPP aushandeln, und der erste LCP-Austausch ist die Stelle, an der ein stiller Fehler meist landet.
Eine Falle in dieser Stufe ist überhaupt kein Netzwerkfehler: Windows erlaubt nur eine Verbindung eines bestimmten VPN-Typs gleichzeitig, ein zweiter Versuch liefert also Fehler 937, „eine andere Verbindung dieses Typs wird verwendet“. Das ist eine lokale Regel, und der Weg daran vorbei ist ein anderes Gerät, ein anderer Tunneltyp oder das Teilen der einen Verbindung, die bereits besteht.
Lesen Sie das Log in Stufenreihenfolge, statt zu raten
Stoppen Sie den Client, starten Sie ihn neu, und lesen Sie die Komponenten in der Reihenfolge, in der sie loggen. Das heißt zuerst der IPsec-Daemon — strongSwan oder Libreswan, und ipsec --version sagt Ihnen, welcher — dann der L2TP-Daemon, dann pppd. Welche Komponente vor dem Fehler zuletzt geschrieben hat, markiert die zu untersuchende Stufe, denn alles, was in der Reihenfolge danach kommt, lief überhaupt nicht.
Verifizieren Sie mit einer frischen Verbindung statt mit einer gespeicherten Sitzung, denn ein Client, der aus dem Cache neu verbindet, kann Teile des Austauschs überspringen und ein veraltetes Ergebnis reproduzieren. Bestätigen Sie Erreichbarkeit, Schlüsselaustausch, Tunnel und PPP einzeln, in dieser Reihenfolge. Dann hört die fehlende Abfrage auf, ein Rätsel zu sein, und wird die zweite Zeile einer Liste, die Sie tatsächlich abarbeiten können. Diese Liste ist auch das, was Sie dem Netzwerkteam geben, das sonst gebeten würde, die Firewall auf einen Fehler zu prüfen, der in einem nicht gestarteten Daemon lebt.