VPN-Migration: Lizenzen, Funktionen und Richtlinie als ein Datensatz

Sitzungen, die am alten Konzentrator noch funktionieren, wirken wie ein Beweis, dass die Migration weitgehend erledigt ist. Sie sind ein Inventarposten, und der am wenigsten interessante. Was der Wechsel braucht, ist ein Datensatz, der Ziel-Gateway, unterstützten Client, erworbene Berechtigung und durchgesetzte Zulassungsrichtlinie in einem Artefakt zusammenführt, das jemand verantwortet. Ohne ihn ist die Migration eine Reihe von Annahmen, die einzeln betrachtet jeweils vernünftig aussehen.

Vier Spalten, keine Checkliste

Was die Hardware tragen kann, was der Vertrag erlaubt und was das Regelwerk zulässt, sind drei getrennte Fragen, und ihre Vermischung ergibt einen Plan, den niemand prüfen kann. Halten Sie sie in getrennten Spalten und lassen Sie jede ihre Quelle nennen. Ein Gerät, das eine Verbindung annimmt, beweist, dass sich ein Gerät verbinden kann, und es erklärt nichts über Funktionsumfang oder Zählbasis. Drei Spalten, die sich widersprechen, sind weit nützlicher als ein Absatz, der selbstsicher klingt.

Der Datensatz ist fertig, wenn alle vier Spalten von jemandem gefüllt sind, der dazu berechtigt ist. Eine Spalte, die der falsche Eigentümer unterschreibt, ist ein Gerücht mit Datum.

Plattform und Berechtigung

Halten Sie das unterstützte Gateway, die Betriebssysteme des Clients, den Authentifizierungspfad und die Managementwerkzeuge fest. Halten Sie einen veralteten Client nicht am Leben, nur weil sein altes Profil noch aufgeht, denn dieses Profil ist eine Kompatibilitätsaussage, die der Hersteller möglicherweise nicht mehr einhält. Prüfen Sie die aktuelle Support-Erklärung gegen die Version, die Sie einführen wollen.

Zur Berechtigung gehören Produkt, Lizenztyp, Laufzeit und Zählbasis, und all das ist über den Kontoinhaber abzugleichen. Rechte aus einem historischen Sitzungszähler abzuleiten, ist der Weg, auf dem eine Organisation einen Fehlbetrag nach dem Wechsel entdeckt statt davor.

Bestellleitfäden der Hersteller zeigen, warum die Unterscheidungen zählen. Der Bestellleitfaden für Secure Client von Cisco etwa trennt die Stufen Advantage, Premier und VPN Only, jede mit eigenem Maßstab und Funktionsumfang. Nutzen Sie die aktuelle Vereinbarung, statt ein altes Etikett mechanisch zu übersetzen.

Funktionen und durchgesetzte Richtlinie

Listen Sie die Fähigkeiten auf, die der Betrieb tatsächlich braucht: zulässige Tunnelmodi, Gerätebewertung, Authentifizierungsintegration und jedes weitere Modul. Prüfen Sie Support und Berechtigung für jede einzeln, denn eine Funktion kann unterstützt und unlizenziert sein oder lizenziert und in der gewählten Version nicht unterstützt. Nur eine Zeile, die beide Fragen mit Ja beantwortet, zählt.

Ist das Ziel eine ASA, wird die Funktionsspalte vom Gerät abgelesen und nicht aus einem Vertrag, also erfassen Sie das Gateway vor dem Stichtag. show vpn-sessiondb summary liefert das Inventar der laufenden Sitzungen und die Zahlen, an denen Ihre Berechtigung gemessen wird, show vpn-sessiondb detail anyconnect zeigt, welchen Clienttyp und welches Profil jede zugeordnete Sitzung tatsächlich genutzt hat, und show running-config webvpn erfasst die Gateway-Konfiguration, von der diese Sitzungen abhängen, und das ist der eine Teil des Datensatzes, den kein Lizenzdokument enthalten kann.

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

Führen Sie nach dem Wechsel dieselben drei auf dem neuen Gateway aus und vergleichen Sie sie mit den erfassten Kopien. Dass sich Sitzungszahlen bewegen, ist zu erwarten; ein Clienttyp oder ein webvpn-Block, der auf einer Seite auftaucht und auf der anderen nicht, ist der Befund, und er gehört mit Erklärung in den Datensatz statt in einen Ticket-Kommentar. Bewahren Sie die Rohaufnahmen ebenso auf wie die Unterschiede, denn der nächste Prüfer will sehen, was verglichen wurde. Bei einem anderen Hersteller ist das Gegenstück die eigene Sitzungstabelle und der Profil-Export jener Plattform, in einem Format, das nicht passen wird, also vergleichen Sie die gestellten Fragen statt den Text.

Ordnen Sie dann Nutzer und Geräte den Regeln des Ziels, den Ressourcenberechtigungen und dem Ablehnungsverhalten zu. Eine Lizenz, die eine Funktion ermöglicht, ist keine Konfiguration, die sie ausübt, und in der Lücke dazwischen wohnen die meisten Migrationsüberraschungen.

Schreiben Sie die Ablehnungsfälle mit derselben Sorgfalt auf wie die zulässigen. Ein Plan, der nur beweist, dass ein Administrator sich verbinden kann, hat den einfachsten Weg geprüft und keine der Grenzen.

Akzeptanz auf beiden Seiten der Entscheidung

Führen Sie vor dem Wechsel einen freigegebenen Abnahmeplan über die vorgesehenen Clienttypen, die Authentifizierungsmethoden und die Ressourcen aus. Nehmen Sie ein Gerät oder eine Identität auf, die abgelehnt werden muss, und bestätigen Sie, welche Regel es ausgewählt hat und was die resultierende Sitzung erreichen darf. Einigen Sie sich auf die Ablehnungsfälle, bevor das Änderungsfenster öffnet, damit niemand sie unter Zeitdruck still fallenlassen kann. Ein Plan ohne Ablehnungsfall hat den glücklichen Pfad geprüft und sonst nichts.

Halten Sie einen Rückweg und einen Managementweg bereit, der nicht von dem abhängt, was migriert wird. Bewahren Sie Konfiguration und Identitätsdatensätze sicher auf und lassen Sie veraltete kryptografische Einstellungen zurück, statt sie mitzuschleppen. Kleben Sie niemals Lizenzkennungen oder Nutzerdatensätze in öffentliche Notizen.

Lassen Sie den Eigentümer Berechtigung und Richtlinienzuordnung gemeinsam unterzeichnen. Der fertige Datensatz beantwortet zwei Fragen zugleich: was die Organisation einführen darf und welche Regeln ihre Nutzer tatsächlich zulassen und einschränken.