VPN-Migration von IOS zu ASA: die Vereinbarung übersetzen, nicht die Befehle

Eine IOS-Konfiguration, die als Referenz für eine ASA-Migration eintrifft, beschreibt eine Vereinbarung, die in die Syntax einer Plattform verpackt ist. Peer-Adressen, Identitäten und geschützte Bereiche sind die Vereinbarung. Schlüsselring, Profil und Kryptomap-Kette sind die Art, wie IOS sie ausdrückt, während die ASA dieselbe Absicht über Tunnelgruppen und deren Attribute ausdrückt. Den zweiten Teil zu kopieren funktioniert nie, und nur den ersten zu kopieren lässt die Arbeit halbfertig zurück.

Arbeiten Sie die fünf Schritte unten der Reihe nach durch und halten Sie überall dort an, wo die beiden Plattformen unterschiedliche Dinge statt unterschiedlicher Wörter beschreiben.

Schritt 1: Trennen Sie die Vereinbarung von der Syntax

Schreiben Sie die Übergabe als Anforderungen, auf die sich beide Administratoren einigen. Vier Zeilen decken fast alles ab: wo der Peer ist und welche Seite beginnt, wie jede Seite ihre Identität nachweist, welcher Schutz akzeptabel ist und welche Anwendungen den Tunnel überstehen müssen. Keine dieser Zeilen nennt einen Befehl.

Bewahren Sie den Originaltext als Beleg und nicht als Anweisung auf. Eine Zeile, die es auf der einen Plattform gibt und auf der anderen nicht, ist ein Syntaxunterschied, bis Sie geprüft haben, ob dieselbe Anforderung anders erfüllt werden kann.

Schritt 2: Benennen Sie die Objekte auf jeder Plattform

Unter IOS XE speist ein IKEv2-Schlüsselring ein IKEv2-Profil, und dieses Profil wird über eine Kryptomap oder ein IPsec-Profil angehängt. Auf der ASA enthält eine Tunnelgruppe das Verbindungsprofil und seine IPsec-Attribute, und die Kryptomap verweist darauf, wie die Anleitung zum Verbindungsprofil es beschreibt. Das sind unterschiedliche Objektgraphen mit unterschiedlicher Vererbung, weshalb eine Zeile-für-Zeile-Zuordnung eine Konfiguration ergibt, die sich parsen lässt und nicht verbindet.

Bauen Sie die Zielobjekte aus den Anforderungszeilen und nicht aus den Quellzeilen auf. Sind die Zeilen vollständig, ist die Zielkonfiguration eine Designentscheidung. Sind sie es nicht, liefert keine noch so große Befehlsübersetzung die fehlende Absicht.

Schritt 3: Übertragen Sie Identität, nicht nur Adressen

Identität ist der Teil, der leise bricht. Ein Peer, der sich per Adresse authentifiziert, verhält sich anders als einer, der sich per Zertifikatssubjekt oder FQDN authentifiziert, und die beiden Plattformen halten diese Erwartung an unterschiedlichen Stellen fest. Bewahren Sie die beabsichtigte Identität und Vertrauenskette, anstatt ein gemeinsames Geheimnis zu ersetzen, weil es einfacher zu testen ist.

Halten Sie das vorab geteilte Geheimnis aus Vergleichsnotizen und Tickets heraus. Notieren Sie, wem es gehört und wie es über einen genehmigten Kanal wandert, und denken Sie daran, dass ein Platzhalter aus einem Dokumentationsbeispiel nicht die Anmeldedaten des Kunden ist.

Schritt 4: Vereinbaren Sie den Schutz vor der Umschaltung

Übertragen Sie keine alten kryptografischen Einstellungen, nur weil sie im gelieferten Text stehen. Vereinbaren Sie eine Schnittmenge von Suiten, die beide eingesetzten Peers derzeit unterstützen, und bestätigen Sie sie mit dem anderen Administrator vor dem Änderungsfenster. Weicht diese Schnittmenge von dem ab, was der bestehende Peer erwartet, ist das eine koordinierte Änderung und keine lokale Anpassung.

Schreiben Sie die vereinbarte Menge auf. Zwei Administratoren mit unterschiedlichen Erinnerungen an ein Telefonat sind der Grund, warum eine Umschaltung eine Phase-zwei-Fehlanpassung erzeugt.

Schritt 5: Prüfen Sie den Dienst, nicht die Syntax

Prüfen Sie zuerst die effektiven Objekte des Ziels, dann die akzeptierte Assoziation, dann einen echten Anwendungsfluss und dessen Antwort. Einen Befehl fehlerfrei einzugeben belegt die Syntax und sonst nichts. Ein Tunnel, der hochkommt und keinen Verkehr trägt, bedeutet meist, dass geschützte Bereiche oder die Rückroute mit der anderen Seite nicht übereinstimmen, was ein Problem der Anforderungszeile und nicht des Befehls ist. Vergleichen Sie die geschützten Bereiche auf beiden Seiten, bevor Sie die Kryptomap erneut anfassen.

Halten Sie fest, was Sie geprüft haben, mit welchen Adressen und von welcher Seite. Diese Aufzeichnung macht aus einer vagen Behauptung, das VPN sei oben, etwas, das der andere Administrator unabhängig kontrollieren kann.

Was zurückzugeben ist

Senden Sie die Anforderungsmatrix, eine Zusammenfassung der Zielkonfiguration und die Prüfergebnisse. Geben Sie ausdrücklich an, welche Quelleinstellungen Sie nicht übernommen haben und warum. Diese Liste ist nützlicher als die übersetzte Konfiguration, denn dort beginnt die nächste Meinungsverschiedenheit.

Bewahren Sie auch den Quelltext beim Ticket auf. Er dokumentiert, was gefordert war, während die Matrix dokumentiert, was vereinbart wurde.