Migrering av en VPN: lisenser, funksjoner og policy som én registrering

Økter som fortsatt virker på den gamle konsentratoren føles som bevis på at migreringen stort sett er ferdig. De er én inventarpost, og den minst interessante. Det overgangen trenger, er en registrering som binder mål-gatewayen, den støttede klienten, den kjøpte rettigheten og den håndhevede adgangspolicyen sammen i én artefakt som noen eier. Uten den er migreringen en rekke antakelser som hver for seg ser rimelige ut.

Fire kolonner, ikke én sjekkliste

Hva maskinvaren kan bære, hva kontrakten tillater og hva regelverket gir adgang til, er tre separate spørsmål, og å blande dem gir en plan ingen kan revidere. Hold dem i separate kolonner og la hver enkelt oppgi kilden sin. En enhet som godtar en tilkobling, beviser at en enhet kan koble til, og det forklarer ingenting om funksjonsomfang eller tellemetode. Tre kolonner som er uenige er langt mer nyttige enn ett avsnitt som høres selvsikkert ut.

Registreringen er ferdig når alle fire kolonnene er fylt ut av noen som har rett til å fylle dem. En kolonne signert av feil eier er et rykte med en dato på.

Plattform og rettighet

Registrer den støttede gatewayen, klientens operativsystemer, autentiseringsveien og administrasjonsverktøyene. Ikke hold en utdatert klient i live bare fordi den gamle profilen fortsatt åpnes, siden profilen er en kompatibilitetspåstand som leverandøren kanskje ikke oppfyller lenger. Sjekk gjeldende støtteerklæring mot versjonen du planlegger å rulle ut.

For rettigheten: registrer produktet, lisenstypen, løpetiden og tellemetoden, og avstem det deretter gjennom kontoens eier. Å utlede rettigheter fra en historisk øktteller er måten en organisasjon oppdager en mangel etter overgangen i stedet for før.

Leverandørenes bestillingsveiledninger viser hvorfor forskjellene betyr noe. Ciscos bestillingsveiledning for Secure Client deler for eksempel nivåene Advantage, Premier og VPN Only, hver med sitt eget mål og funksjonsomfang. Bruk gjeldende avtale i stedet for å oversette en gammel etikett mekanisk.

Funksjoner og håndhevet policy

List opp kapasitetene utrullingen faktisk trenger: tillatte tunnelmoduser, enhetsvurdering, autentiseringsintegrasjon og enhver annen modul. Sjekk støtte og rettighet for hver enkelt separat, fordi en funksjon kan være støttet og ulisensiert, eller lisensiert og ikke støttet på den valgte versjonen. Bare en rad som svarer ja på begge spørsmålene teller.

Når målet er en ASA, leses funksjonskolonnen fra boksen og ikke fra en kontrakt, så fang gatewayen før overgangsdagen. show vpn-sessiondb summary gir oversikten over aktive økter og tallene rettigheten din måles mot, show vpn-sessiondb detail anyconnect viser hvilken klienttype og profil hver tilordnede økt faktisk brukte, og show running-config webvpn fanger gateway-konfigurasjonen disse øktene er avhengige av, og det er den ene delen av registreringen som ingen lisensdokument kan inneholde.

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

Etter overgangen kjører du de samme tre på den nye gatewayen og sammenligner dem med de fangede kopiene. At økttallene flytter seg, er forventet; en klienttype eller en webvpn-blokk som dukker opp på den ene siden og ikke den andre, er funnet, og det hører hjemme i registreringen med en forklaring i stedet for i en saks-kommentar. Lagre råopptakene så vel som forskjellene, fordi neste gjennomgang vil se hva som ble sammenlignet. Hos en annen leverandør er ekvivalenten den plattformens egen økttabell og profileksport, i et format som ikke vil stemme, så sammenlign spørsmålene som stilles til den i stedet for teksten.

Deretter kartlegg brukere og enheter mot målets regler, ressursrettigheter og avvisningsatferd. En lisens som muliggjør en funksjon, er ikke en konfigurasjon som utøver den, og gapet mellom de to er der de fleste migreringsoverraskelser bor.

Skriv ned avvisningssakene med samme omhu som de tillatte sakene. En plan som bare beviser at en administrator kan koble til, har testet den enkleste veien og ingen av grensene.

Godta på begge sider av beslutningen

Før overgangen kjører du en godkjent akseptplan på tvers av de tiltenkte klienttypene, autentiseringsmetodene og ressursene. Ta med en enhet eller identitet som må avvises, og bekreft hvilken regel som valgte den og hva den resulterende økten kan nå. Bli enige om avvisningssakene før endringsvinduet åpner, slik at ingen stille kan droppe dem under tidspress. En plan uten avvisningssak har testet den lykkelige veien og ingenting annet.

Hold en tilbakerullingsvei og en administrasjonsrute som ikke avhenger av det som migreres. Bevar konfigurasjonen og identitetsregistreringene sikkert, og la utdaterte kryptografiske innstillinger bli igjen i stedet for å føre dem videre. Lim aldri inn lisensidentifikatorer eller brukerregistreringer i offentlige notater.

La eieren signere rettigheten og policykartleggingen sammen. Den ferdige registreringen besvarer to spørsmål samtidig: hva organisasjonen har lisens til å rulle ut, og hvilke regler som faktisk slipper brukerne inn og begrenser dem.