Umstieg von einem PPP-basierten VPN ohne Übernahme seiner Annahmen

Eine VPN-Migration ist erst abgeschlossen, wenn Benutzer, Ziele, Namensauflösung und Fehlerverhalten weiterhin stimmen – nicht wenn der neue Client ein grünes Symbol zeigt. Alte PPP-basierte Umgebungen tragen Annahmen mit sich, die nie aufgeschrieben wurden: ein gemeinsames Geheimnis, das zugleich die einzige Identitätsprüfung war, ein fester Adresspool, den die Firewall in ihrer Positivliste führt, ein DNS-Suffix, das der Server zuschiebt. Den Protokollwechsel ohne Bestandsaufnahme dieser Annahmen durchzuführen erzeugt einen Tunnel, der den Handshake schafft, und eine Grenze, die es nicht gibt. Die folgende Reihenfolge ist die, die ich verwende, und der letzte Schritt ist der, den Teams überspringen.

Schritt 1: Erfassen Sie, was die alte Verbindung leistet

Der Bestand wird geschrieben, nicht erinnert. Halten Sie unterstützte Clients, Authentifizierungsrollen, Adresspools, geschützte Netze, DNS-Anforderungen und die Dienstberechtigungen fest, die jede Benutzergruppe benötigt.

Bei L2TP/IPsec trennen Sie die beiden Schichten ausdrücklich. Die IPsec-Peer-Identität authentifiziert die Maschinen; PPP authentifiziert den Benutzer, üblicherweise per CHAP oder MSCHAPv2.

Genau in dieser Trennung verstecken alte Umgebungen ihre Annahmen. Ein vorab geteilter Schlüssel, den jeder Client teilt, authentifiziert eine Gruppe statt ein Gerät, und er ist oft das Einzige, was jemals rotiert wurde. Wenn das PPP-Konto die eigentliche Steuerung pro Benutzer ist, sagen Sie es, denn die Ablösung muss diese Steuerung mit etwas reproduzieren, das keine gemeinsame Zeichenkette ist. Notieren Sie auch feste Quelladressen und Ausnahmen für das lokale Netz, denn das sind die Abhängigkeiten, die niemand dokumentiert, bis sie brechen.

Schritt 2: Entwerfen Sie die Ablösung bewusst

Die Ablösung auszuwählen ist eine Zuordnung Anforderung für Anforderung: ein Protokoll und ein gepflegter Client, den die Organisation unterstützt, wobei jede Identitäts- und Zugriffsanforderung in einem tatsächlichen Mechanismus landet. Ein gemeinsames Geheimnis entspricht nicht automatisch einem Schlüssel oder Zertifikat pro Gerät, und ein PPP-Konto pro Benutzer entspricht nicht einem Gerätezertifikat.

Stimmen Sie Adressbereiche vor allem anderen ab, denn ein Ersatzpool, der ein Heim- oder Büro-LAN überlappt, erzeugt einen Fehler, der nichts mit Chiffrierstärke zu tun hat. Prüfen Sie den Pool gegen dieselbe Liste, die Sie für den alten Dienst erstellt haben, plus das, was der neue Client standardmäßig annimmt. Bestätigen Sie das Rück-Routing für die geschützten Netze und bestätigen Sie, dass der neue Client das DNS-Suffix zuschieben oder dokumentieren kann, das der alte zugeschoben hat. Diese beiden Punkte verursachen mehr Migrationstickets als der Protokollwechsel selbst.

Schritt 3: Führen Sie es stufenweise ein und prüfen Sie Erlauben wie Verweigern

Führen Sie mit einem repräsentativen Benutzer und einer repräsentativen Anwendung ein. Nehmen Sie die private DNS-Auflösung in den Test auf, denn ein Tunnel, der eine Adresse erreicht, aber keinen internen Namen auflösen kann, ist nur halb migriert. Nehmen Sie auch den erwarteten Nichtverfügbarkeitszustand auf: was geschehen soll, wenn der Tunnel wegfällt, und ob der Client das erzwingt.

Testen Sie dann ein Ziel, das verweigert bleiben soll. Eine breite temporäre Erlaubnisregel kann den neuen Tunnel gesund aussehen lassen, während sie still die Autorisierungsgrenze entfernt, die der alte Dienst durchgesetzt hat, und niemand merkt es bis zum Audit. Vergleichen Sie Erlauben- und Verweigern-Ergebnisse Seite an Seite, vom selben Client, in derselben Sitzung. Lassen Sie den alten Dienst laufen, bis beide Spalten dem Entwurf entsprechen.

Bevor Sie den Administratorzugang verlagern, bestätigen Sie, dass Sie einen autorisierten Wiederherstellungsweg haben, der nicht von dem Tunnel abhängt, den Sie ändern.

Schritt 4: Nehmen Sie die alte Identität außer Betrieb

Die alte Identität ordentlich außer Betrieb zu nehmen heißt, veraltete Benutzer und Geräteanmeldedaten über den Dienst zu widerrufen, dem sie gehören, und dann alte Profile und Listener zu entfernen, sobald keine Abhängigkeit mehr besteht. Das Löschen einer lokalen Datei widerruft keine Kopie anderswo, und ein alter Listener, der das alte gemeinsame Geheimnis noch akzeptiert, ist eine unüberwachte Tür.

An diesem Punkt lohnt es sich, langsamer zu werden. Ein stillgelegtes Clientprofil auf einem Laptop ist kein widerrufenes Anmeldedatum; das Anmeldedatum lebt auf dem Server und bleibt gültig, bis der Server aufhört, es zu akzeptieren. Suchen Sie nach weiteren Kopien der alten Konfiguration – Testgeräte, ein vergessenes Telefon, ein Installationsprogramm, das jemand aufgehoben hat – und behandeln Sie das Herunterfahren des Listeners als den Moment, in dem der alte Dienst tatsächlich endet. Bis dahin hat die Migration zwei Vordertüren.

Der Abnahmebericht ist der Bestand aus Schritt eins mit einer zusätzlichen Spalte: was der neue Entwurf für jede Zeile leistet und wie Sie es geprüft haben. Das macht aus einem Protokoll-Upgrade eine Dienstanforderung mit Belegen.

Binden Sie das Ergebnis an das, was der Dienst braucht, statt an den Protokollnamen, denn ein modernes Protokoll mit hineinkopierten alten Annahmen ist dasselbe Risiko mit besserem Rahmen. RFC 3193 beschreibt, wie L2TP über IPsec transportiert wird, was eine nützliche Erinnerung ist, dass die beiden Schichten immer getrennte Entscheidungen waren. Wenn der Bestand eine Zeile hat, die Sie nicht erklären können, halten Sie an und finden Sie heraus, was davon abhängt. Die Migration ist fertig, wenn die Liste langweilig ist.