Welche Schicht des L2TP-Profils tatsächlich ausgefallen ist

Arbeiten Sie den Stapel abwärts ab, statt quer über die Einstellungsseite: IPsec-Aushandlung, dann L2TP-Steuerung, dann PPP-Authentifizierung, dann Adress- und DNS-Zuweisung. Jede Schicht hat ihre eigene Fehlersignatur und ihre eigene wahrscheinliche Ursache. Ein Profil, das bei der Benutzerauthentifizierung scheitert, hat bereits drei Prüfungen überstanden, die ein früher abgelaufenes Profil nie erreicht hat. Diese Reihenfolge gilt es zuerst festzustellen.

Derselbe Protokollname verbirgt vier verschiedene Gespräche.

Benennen Sie die Schicht, bevor Sie Einstellungen ändern

Scheitert die IPsec-Einrichtung, deutet das auf das gemeinsame Geheimnis, die Algorithmen oder die Peer-Identität hin. Scheitert danach die L2TP-Steuerung, liegt die Tunnelschicht selbst nahe, was ein engeres Problem ist. PPP-Authentifizierungsfehler benennen das Konto oder die Authentifizierungsmethode. Ein Adress- oder DNS-Fehler nach der Authentifizierung bedeutet, dass der Transport funktioniert hat und der Konfigurationsaustausch nicht.

Notieren Sie die Client-Version, die Betriebssystemversion und die dokumentierte Einrichtung des Betreibers. Ohne diese drei ist jede Änderung eine Vermutung, die versehentlich etwas anderes reparieren könnte.

Vergleichen Sie das Profil mit dem aktuellen Client

Ein gespeichertes Profil kann ein gemeinsames Geheimnis, eine Authentifizierungsoption oder einen Endpunkt enthalten, den der aktuelle Client nicht mehr akzeptiert. Manche Plattformen haben die L2TP/IPsec-Unterstützung ganz eingestellt oder entfernt, und ein aktualisierter Client kann altes IKE-Verhalten aufgeben, ohne dass sich am Server etwas ändert. Vergleichen Sie Ihre gespeicherten Werte mit den aktuellen dokumentierten Anforderungen des Betreibers, nicht mit dem, was vor einem Jahr funktionierte. Die Lücke zwischen diesen beiden Dokumenten ist meist der Ort, an dem die Antwort liegt.

Ein zwischengespeichertes Geheimnis oder ein umbenanntes Konto erfordert meist nicht mehr als eine gewöhnliche Profilaktualisierung, und beides lohnt sich zu prüfen, bevor Sie irgendetwas umgestalten. Das sind die billigen Reparaturen, und sie sollten ausgeschlossen werden, bevor irgendetwas Architektonisches angegangen wird.

Alte Optionen kehren nicht zurück, indem man sie aktiviert

Das Abschalten der Validierung behebt kein Problem der Vertrauenskette, und das Aktivieren eines Algorithmus nur, weil ein Forenthread ihn erwähnt, beweist nichts darüber, was der Server akzeptiert. Schwache IKE-Vorschläge werden aus gutem Grund aus Clients entfernt, und einen davon wieder zu aktivieren erzeugt eine Verbindung, die schlechter ist als die ausgefallene. Ein schwächerer Tunnel ist keine Reparatur, sondern ein neues Problem mit demselben Symptom. Die richtige Frage ist, was der Betreiber jetzt unterstützt.

Eine Reparatur nach dem Motto „alles aktivieren“ ändert weit mehr als den eigentlichen Fehler und lässt Sie nicht sagen, was ihn behoben hat.

Legen Sie die Migration als Projekt an

Wenn die Bereitstellung den erforderlichen Client nicht mehr unterstützt, planen Sie gemeinsam mit dem Betreiber einen Ersatz, statt eine undokumentierte Ausnahme zu bewahren. Übertragen Sie die Zugangsanforderung, die Identitäten, DNS-Einträge und Routen, denn ein neuer Handshake allein stellt keine dieser Berechtigungen wieder her. Das sind die Teile, auf denen eine funktionierende Verbindung stillschweigend beruhte. Bewahren Sie das alte Profil sicher auf, bis die Wiederherstellung bestätigt ist, und ziehen Sie dann die veralteten Zugangsdaten dort zurück, wo sie tatsächlich verwaltet werden. Sie stehen zu lassen ist der Weg, auf dem ein alter Pfad noch lange nutzbar bleibt, nachdem alle glauben, er sei geschlossen.

Eine Migration ist auch der Moment, festzuhalten, wofür das Profil da war. Sonst erbt die nächste Person eine funktionierende Verbindung ohne jede Erklärung.

Prüfen Sie die Schicht, die Client-Version und die aktuellen Anforderungen des Betreibers. Entscheiden Sie dann, ob dies eine Reparatur oder ein Ersatz ist.