Migrering af en VPN: licenser, funktioner og politik som én registrering

Sessioner, der stadig virker på den gamle koncentrator, føles som bevis for, at migreringen stort set er færdig. De er én post i opgørelsen, og den mindst interessante. Det, skiftet har brug for, er en registrering, der binder mål-gatewayen, den understøttede klient, den købte rettighed og den håndhævede adgangspolitik sammen i ét artefakt, som nogen ejer. Uden den er migreringen en række antagelser, som hver især ser rimelige ud.

Fire kolonner, ikke én tjekliste

Hvad hardwaren kan bære, hvad kontrakten tillader, og hvad regelsættet giver adgang til, er tre separate spørgsmål, og at blande dem giver en plan, ingen kan revidere. Hold dem i separate kolonner, og lad hver enkelt angive sin kilde. En enhed, der accepterer en forbindelse, beviser, at en enhed kan forbinde, og det forklarer intet om funktionsomfang eller optællingsgrundlag. Tre kolonner, der er uenige, er langt mere nyttige end ét afsnit, der lyder selvsikkert.

Registreringen er færdig, når alle fire kolonner er udfyldt af nogen, der har ret til at udfylde dem. En kolonne underskrevet af den forkerte ejer er et rygte med en dato på.

Platform og rettighed

Registrer den understøttede gateway, klientens styresystemer, autentificeringsvejen og administrationsværktøjerne. Hold ikke en forældet klient i live, blot fordi dens gamle profil stadig åbner, da profilen er et kompatibilitetsløfte, som leverandøren måske ikke længere opfylder. Kontrollér den aktuelle supportudtalelse mod den version, du planlægger at udrulle.

For rettigheden: registrer produktet, licenstypen, løbetiden og optællingsgrundlaget, og afstem det derefter via kontoens ejer. At udlede rettigheder fra en historisk sessionstæller er måden, en organisation opdager en mangel efter skiftet i stedet for før.

Leverandørernes bestillingsvejledninger viser, hvorfor forskellene betyder noget. Ciscos bestillingsvejledning for Secure Client opdeler for eksempel niveauerne Advantage, Premier og VPN Only, hver med sit eget mål og funktionsomfang. Brug den aktuelle aftale i stedet for at oversætte et gammelt mærke mekanisk.

Funktioner og håndhævet politik

List de kapaciteter, udrulningen faktisk har brug for: tilladte tunnelstilstande, enhedsvurdering, autentificeringsintegration og enhver anden modul. Kontrollér support og rettighed for hver enkelt separat, fordi en funktion kan være understøttet og ulicenseret, eller licenseret og ikke understøttet på den valgte version. Kun en række, der siger ja til begge spørgsmål, tæller.

Når målet er en ASA, læses funktionskolonnen på boksen og ikke i en kontrakt, så registrer gatewayen inden skiftedagen. show vpn-sessiondb summary giver opgørelsen over aktive sessioner og de tal, din rettighed måles imod, show vpn-sessiondb detail anyconnect viser, hvilken klienttype og profil hver tilskrevet session faktisk brugte, og show running-config webvpn registrerer den gateway-konfiguration, som disse sessioner afhænger af, og det er den ene del af registreringen, som intet licensdokument kan indeholde.

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

Efter skiftet kører du de samme tre på den nye gateway og sammenligner dem med de registrerede kopier. At sessionstal flytter sig, er forventet; en klienttype eller en webvpn-blok, der optræder på den ene side og ikke på den anden, er fundet, og det hører til i registreringen med en forklaring i stedet for i en ticket-kommentar. Gem de rå optagelser såvel som forskellene, fordi den næste gennemgang vil se, hvad der blev sammenlignet. Hos en anden leverandør er ækvivalenten den platforms egen sessionstabel og profileksport i et format, der ikke vil passe, så sammenlign de spørgsmål, der stilles til den, i stedet for teksten.

Knyt derefter brugere og enheder til målets regler, ressourceadgange og afvisningsadfærd. En licens, der muliggør en funktion, er ikke en konfiguration, der udøver den, og springet mellem de to er der, hvor de fleste migreringsoverraskelser bor.

Skriv afvisningssagerne ned med samme omhu som de tilladte sager. En plan, der kun beviser, at en administrator kan forbinde, har testet den nemmeste vej og ingen af grænserne.

Accepter på begge sider af beslutningen

Før skiftet kører du en godkendt acceptplan på tværs af de tilsigtede klienttyper, autentificeringsmetoderne og ressourceadgangene. Medtag en enhed eller identitet, der skal afvises, og bekræft, hvilken regel der valgte den, og hvad den resulterende session kan nå. Aftal afvisningssagerne, før ændringsvinduet åbner, så ingen stille kan droppe dem under tidspres. En plan uden afvisningssager har kun testet den lykkelige vej og intet andet.

Hold en tilbagerulningsvej og en administrationsrute, der ikke afhænger af det, der migreres. Bevar konfigurationen og identitetsregistreringerne sikkert, og lad forældede kryptografiske indstillinger blive tilbage i stedet for at føre dem videre. Indsæt aldrig licensidentifikatorer eller brugerregistreringer i offentlige noter.

Lad ejeren underskrive rettigheden og politikmappingen sammen. Den færdige registrering besvarer to spørgsmål på én gang: hvad organisationen har licens til at udrulle, og hvilke regler der faktisk lukker dens brugere ind og begrænser dem.