MSCHAPv2 ist kein VPN-Protokoll: Fragen Sie zuerst nach dem Tunnel
Ein Passwort und das Wort MSCHAPv2 ergeben noch keine Verbindung. Fragen Sie, welcher Tunnel den Austausch trägt, und passen Sie dann das Clientprofil darauf an.
Benutzernamen und Passwörter reisen in einem Träger, und MSCHAPv2 benennt nur die Methode, die reist. Fragen Sie, welcher Tunnel ihn trägt, bevor Sie ein Clientprofil wählen, denn dieselbe Kontokette erscheint in Konstellationen, die keine Zeile Code teilen. Jedes Profil, das man Ihnen aushändigt, kodiert beide Entscheidungen, selbst wenn das Anleitungsblatt nur eine davon abdruckt. Die Reihenfolge unten ist das, was ein Betreiber ohne Raten beantworten kann und was Sie ohne Paketmitschnitt prüfen können.
Authentifizierung fährt in einem Tunnel
Ein VPN trifft zwei Entscheidungen, die wie eine aussehen: wie die Gegenstellen einen geschützten Kanal aufbauen und wie eine Person darin Identität nachweist. Die zweite steht auf dem Anleitungsblatt, weil sie der Mensch eintippt. Die erste entscheidet, ob überhaupt ein Client funktioniert, und genau die wird übersprungen. Bitten Sie den Betreiber, zuerst den Träger und dann die Methode zu nennen, in dieser Reihenfolge. Zwei Verbindungen können denselben Kontonamen und dasselbe Passwort verlangen, ohne unterhalb des Anmeldefelds irgendeine Implementierung zu teilen.
Deshalb können Einstellungen, die vom funktionierenden Telefon eines Kollegen kopiert wurden, bei Ihnen scheitern, selbst wenn der Server beide Anmeldedaten akzeptiert. Die Anmeldedaten waren nie der Unterschied; das Profil darum herum war es. beide Seiten recht haben und nichts sich verbindet ist meist genau diese Verwechslung, und sie klärt sich, sobald der Träger benannt ist.
Drei Stellen, an denen dieselbe Methode auftaucht
In PPP wartet der Authentifizierungsschritt, bis eine Strecke besteht, und RFC 2759 definiert MS-CHAPv2 als diesen Schritt, deshalb taucht die Methode in L2TP und in älteren PPTP-Installationen auf. Der Tunnel endet zuerst, und die PPP-Aushandlung findet darin statt, sodass eine gescheiterte PPP-Phase den Tunnel im Serverprotokoll als aufgebaut erscheinen lassen kann. Lesen Sie diese beiden Phasen getrennt, bevor Sie schließen, die Anmeldedaten seien abgelehnt worden. Ein für L2TP konfigurierter Client kann also völlig korrekt und trotzdem der falsche Client für ein Gateway sein, das nur IKEv2 spricht.
IKEv2 legt EAP-MSCHAPv2 stattdessen in den Schlüsselaustausch, sodass dieselben Anmeldedaten zu einem anderen Zeitpunkt scheitern und als Authentifizierungsfehler statt als Sitzungsfehler auftauchen. Das Plattformprofil IKEv2 von Android ist das Alltagsbeispiel, und es verlangt ein Serverzertifikat oder einen Bezeichner statt PPP-Optionen. Der Kontoname ist in beiden Konstellationen identisch, er kann Ihnen also nicht sagen, welche Sie haben. Das entscheidet nur die Liste der unterstützten Protokolle beim Betreiber.
Ein TLS-basiertes VPN fügt eine dritte Konstellation hinzu, mit eigenen Feldern für Benutzername und Passwort und ohne MS-CHAPv2 irgendwo im Austausch. Ein Passwortfeld zu sehen ist daher kein Beweis für das Protokoll dahinter, denn das Formular ist gebaut, um vertraut zu wirken. Bestätigen Sie das Protokoll aus der Serverdokumentation und nicht aus der Form des Clientfensters.
Die Antworten, die Sie wirklich brauchen
Schicken Sie die Anfrage als Liste, denn eine Liste lässt sich schlecht halb beantworten. Fragen Sie nach dem Tunnelprotokoll, der Methode darin und dem Client, den der Betreiber auf Ihrer Plattform unterstützt. Fragen Sie dann nach Identität und Vertrauenseinstellungen des Gateways, dem Kontoformat und dem, was nach dem Aufbau der Verbindung erreichbar sein soll.
Die ersten drei entscheiden, ob Sie überhaupt ein funktionierendes Profil bekommen. Die letzten drei entscheiden, ob dieses Profil leistet, was die Aufgabe braucht. Halten Sie die Antwort am Ticket, denn die nächste Person wird dieselben sechs Fragen stellen. Wo eine Antwort fehlt, behandeln Sie die Lücke als eine Entscheidung, die der Betreiber noch nicht getroffen hat, und nicht als etwas, das Sie ableiten können.
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
Lockern Sie die Gateway-Prüfung nicht
Der Server weist auch dem Client gegenüber seine Identität nach, und diese Hälfte des Austauschs ist keine Zierde. Die Zertifikatsprüfung abzuschalten, damit ein störrisches Profil sich verbindet, akzeptiert jeden Endpunkt, der antwortet, auch einen, den niemand erreichen wollte. Es verbirgt außerdem eine echte Abweichung, statt sie zu beheben, was den Fehler auf einen späteren und weniger offensichtlichen Moment verschiebt. Ein Profil, das die Prüfung abgeschaltet braucht, ist ein Profil, das auf etwas zeigt, das es nicht prüfen kann.
Die Abweichung ist meist ein Name, denn ein auf einen Hostnamen ausgestelltes Zertifikat scheitert, wenn das Profil eine Adresse wählt. Wählen Sie den Namen, statt die Prüfung abzuschalten. Eine private Zertifizierungsstelle scheitert, wenn das Gerät die Wurzel nie erhalten hat, und die Lösung ist, diese Wurzel über den genehmigten Weg zu verteilen. Verwaltete Umgebungen erwarten, dass der Betreiber Identität und Vertrauensanker liefert und das Profil auf beides verweist. Fehlt das Feld, bitten Sie um das Artefakt, statt auf die Prüfung zu verzichten.
Passen Sie das Profil an und belegen Sie dann jede Stufe
Sobald der Träger bekannt ist, folgen Sie dem dokumentierten Verfahren dieses Clients und tragen nur die Felder ein, die es verlangt. Zusätzliche Felder, die ausgefüllt werden, weil es sie gibt, sind weiterhin falsche Werte, und sie scheitern später als die erforderlichen. Speichern Sie das Profil nach der ersten erfolgreichen Verbindung unverändert, damit sich eine spätere Änderung mit etwas vergleichen lässt, das nachweislich funktioniert.
Prüfen Sie dann stufenweise: der Tunnel steht, der Benutzer authentifiziert sich, die zugewiesene Adresse und die Routen erscheinen, und ein erlaubter Dienst antwortet. Jede Stufe hinterlässt ihre eigene Protokollzeile auf dem Server, und sie in Reihenfolge zu lesen macht aus einer vagen Beschwerde einen konkreten Befund. Unterstützt die Plattform die beschriebene Konstellation nicht mehr, ist das ein Migrationsgespräch und kein Grund, jede Altoption auf dem Gerät zu aktivieren. Träger, Methode und Profil sind drei getrennte Antworten, und eine Verbindung, die funktioniert, hat alle drei im Einklang.