Migrera en VPN: licenser, funktioner och policy som en post

Sessioner som fortfarande fungerar på den gamla koncentratorn känns som bevis för att migreringen nästan är klar. De är en enda inventariepost, och den minst intressanta. Det bytet behöver är en post som binder samman mål-gatewayen, den stödda klienten, den köpta rättigheten och den tillämpade åtkomstpolicyn i en enda artefakt som någon äger. Utan den är migreringen en rad antaganden som var för sig verkar rimliga.

Fyra kolumner, inte en checklista

Vad hårdvaran kan bära, vad avtalet tillåter och vad regelverket medger är tre separata frågor, och att blanda dem ger en plan som ingen kan granska. Håll dem i separata kolumner och låt varje kolumn ange sin källa. En enhet som tar emot en anslutning bevisar att en enhet kan ansluta, och det förklarar ingenting om funktionsomfång eller beräkningsgrund. Tre kolumner som är oense är mycket mer användbara än ett stycke som låter självsäkert.

Posten är klar när alla fyra kolumner fylls i av någon som har rätt att fylla i dem. En kolumn som undertecknats av fel ägare är ett rykte med ett datum på.

Plattform och rättighet

Registrera den stödda gatewayen, klientens operativsystem, autentiseringsvägen och administrationsverktygen. Håll inte en föråldrad klient vid liv bara för att dess gamla profil fortfarande öppnas, eftersom profilen är ett kompatibilitetspåstående som leverantören kanske inte längre uppfyller. Jämför den aktuella supportdeklarationen med den version du planerar att driftsätta.

För rättigheten: registrera produkten, licenstypen, löptiden och beräkningsgrunden och stäm sedan av det via kontots ägare. Att härleda rättigheter från en historisk sessionsräknare är hur en organisation upptäcker en brist efter bytet i stället för före.

Leverantörernas beställningsguider visar varför distinktionerna spelar roll. Ciscos beställningsguide för Secure Client delar till exempel upp nivåerna Advantage, Premier och VPN Only, var och en med sitt eget mått och funktionsomfång. Använd det aktuella avtalet i stället för att översätta en gammal etikett mekaniskt.

Funktioner och tillämpad policy

Lista de förmågor som driftsättningen faktiskt behöver: tillåtna tunnel-lägen, enhetsbedömning, autentiseringsintegration och varje annan modul. Kontrollera stöd och rättighet för var och en separat, eftersom en funktion kan vara stödd och olicensierad, eller licensierad och inte stödd i den valda versionen. Bara en rad som svarar ja på båda frågorna räknas.

När målet är en ASA läses funktionskolumnen från enheten och inte från ett avtal, så fånga gatewayen före bytesdagen. show vpn-sessiondb summary ger inventariet över aktiva sessioner och de tal som din rättighet mäts mot, show vpn-sessiondb detail anyconnect visar vilken klienttyp och profil varje tillskriven session faktiskt använde, och show running-config webvpn fångar den gatewaykonfiguration som dessa sessioner är beroende av, och det är den enda delen av posten som inget licensdokument kan innehålla.

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

Efter bytet kör du samma tre på den nya gatewayen och jämför dem med de fångade kopiorna. Att sessionstalen rör sig är väntat; en klienttyp eller ett webvpn-block som dyker upp på ena sidan och inte på den andra är fyndet, och det hör hemma i posten med en förklaring i stället för i en ärendekommentar. Spara både råfångsterna och skillnaderna, eftersom nästa granskare vill se vad som jämfördes. Hos en annan leverantör är motsvarigheten den plattformens egen sessionstabell och profilexport, i ett format som inte kommer att stämma, så jämför frågorna som ställs till den i stället för texten.

Koppla sedan användare och enheter till målets regler, resursbehörigheter och avvisningsbeteende. En licens som möjliggör en funktion är inte en konfiguration som utövar den, och gapet mellan de två är där de flesta migreringsöverraskningar bor.

Skriv ned avvisningsfallen med samma omsorg som de tillåtna fallen. En plan som bara bevisar att en administratör kan ansluta har testat den enklaste vägen och ingen av gränserna.

Acceptera på båda sidor av beslutet

Före bytet kör du en godkänd acceptansplan över de avsedda klienttyperna, autentiseringsmetoderna och resurserna. Ta med en enhet eller identitet som måste avvisas, och bekräfta vilken regel som valde den och vad den resulterande sessionen kan nå. Kom överens om avvisningsfallen innan ändringsfönstret öppnas, så att ingen tyst kan hoppa över dem under tidspress. En plan utan avvisningsfall har testat den lyckliga vägen och ingenting annat.

Håll en återställningsväg och en administrationsväg som inte beror på det som migreras. Bevara konfigurationen och identitetsposterna säkert, och lämna föråldrade kryptografiska inställningar bakom dig i stället för att föra dem vidare. Klistra aldrig in licensidentifierare eller användarposter i offentliga anteckningar.

Låt ägaren signera rättigheten och policykopplingen tillsammans. Den färdiga posten besvarar två frågor samtidigt: vad organisationen har licens att driftsätta, och vilka regler som faktiskt släpper in och begränsar dess användare.