Flytting bort fra en PPP-basert VPN uten å kopiere forutsetningene

En VPN-migrering er ferdig når brukerne, destinasjonene, navneoppslaget og oppførselen ved feil fortsatt er riktige, ikke når den nye klienten viser et grønt ikon. Gamle PPP-baserte installasjoner bærer forutsetninger som aldri ble skrevet ned: en delt hemmelighet som også var den eneste identitetskontrollen, en fast adressepulje som brannmuren har på tillatt-listen, og et DNS-suffiks som serveren skyver ut. Å bytte protokoll uten å kartlegge disse forutsetningene gir en tunnel som fullfører håndtrykket, og en grense som ikke finnes. Rekkefølgen nedenfor er den jeg bruker, og det siste trinnet er det teamene hopper over.

Trinn 1: kartlegg hva den gamle forbindelsen gir

Kartleggingen skrives, ikke huskes. Registrer de støttede klientene, autentiseringsrollene, adressepuljene, de beskyttede nettene, DNS-kravene og tjenestetillatelsene hver brukergruppe trenger.

For L2TP/IPsec må du skille de to lagene eksplisitt. IPsec-peerens identitet autentiserer maskinene; PPP autentiserer brukeren, vanligvis med CHAP eller MSCHAPv2.

Det er i denne delingen gamle installasjoner skjuler forutsetningene sine. En forhåndsdelt nøkkel som alle klienter deler, autentiserer en gruppe og ikke en enhet, og den er ofte det eneste som noen gang har blitt rotert. Hvis PPP-kontoen er den reelle kontrollen per bruker, si det, fordi erstatningen må gjenskape den kontrollen med noe som ikke er en delt streng. Noter også faste kildeadresser og unntak for lokalnettet, for det er avhengighetene ingen dokumenterer før de bryter.

Trinn 2: design erstatningen bevisst

Å velge erstatningen er en krav-for-krav-tilordning: en protokoll og en vedlikeholdt klient organisasjonen støtter, der hvert identitets- og tilgangskrav lander i en faktisk mekanisme. En delt hemmelighet er ikke automatisk det samme som en nøkkel eller et sertifikat per enhet, og en PPP-konto per bruker er ikke det samme som et enhetssertifikat.

Samordne adresseområder før alt annet, fordi en erstatningspulje som overlapper et hjemme- eller kontor-LAN skaper en feil som ikke har noe med chiffrestyrke å gjøre. Kontroller puljen mot den samme listen du laget for den gamle tjenesten, pluss det den nye klienten antar som standard. Bekreft returrutingen for de beskyttede nettene, og bekreft at den nye klienten kan skyve ut eller dokumentere DNS-suffikset den gamle skjøv ut. Disse to punktene gir flere migreringssaker enn selve protokollbyttet.

Trinn 3: innfør trinnvis og verifiser både tillat og avvis

Innfør med én representativ bruker og én representativ applikasjon. Ta med privat DNS-oppslag i testen, fordi en tunnel som når en adresse men ikke kan slå opp et internt navn bare er halvt migrert. Ta også med den forventede utilgjengelige tilstanden: hva som skal skje når tunnelen faller, og om klienten håndhever det.

Test deretter en destinasjon som skal forbli avvist. En bred midlertidig tillatelsesregel kan få den nye tunnelen til å se sunn ut mens den stille fjerner autorisasjonsgrensen den gamle tjenesten håndhevet, og ingen merker det før en revisjon. Sammenlign tillat- og avvis-resultater side om side, fra samme klient, i samme økt. Hold den gamle tjenesten i drift til begge kolonnene stemmer med designet.

Før du flytter administrator tilgang, må du bekrefte at du har en autorisert gjenopprettingsvei som ikke avhenger av tunnelen du endrer.

Trinn 4: avvikle den gamle identiteten

Korrekt avvikling av den gamle identiteten betyr å tilbakekalle utdaterte brukere og enhetslegitimasjoner gjennom tjenesten som eier dem, og deretter fjerne gamle profiler og lyttere når ingen avhengighet gjenstår. Sletting av en lokal fil tilbakekaller ikke en kopi et annet sted, og en gammel lytter som fortsatt godtar den gamle delte hemmeligheten er en dør uten overvåking.

Det punktet er verdt å bremse for. En avviklet klientprofil på en bærbar PC er ikke en tilbakekalt legitimasjon; legitimasjonen lever på serveren og forblir gyldig til serveren slutter å godta den. Se etter andre kopier av den gamle konfigurasjonen — testenheter, en glemt telefon, et installasjonsprogram noen har tatt vare på — og behandle nedstengingen av lytteren som øyeblikket den gamle tjenesten faktisk avsluttes. Inntil da har migreringen to fordører.

Akseptprotokollen er kartleggingen fra trinn én med en kolonne lagt til: hva det nye designet gjør for hver rad, og hvordan du verifiserte det. Det gjør en protokolloppgradering til et tjenestekrav med bevis.

Hold resultatet bundet til det tjenesten trenger og ikke til protokollnavnet, fordi en moderne protokoll med de gamle forutsetningene kopiert inn er den samme risikoen med bedre rammeverk. RFC 3193 beskriver hvordan L2TP bæres over IPsec, noe som er en nyttig påminnelse om at de to lagene alltid var separate beslutninger. Hvis kartleggingen har en rad du ikke kan forklare, stopp og finn ut hva som avhenger av den. Migreringen er ferdig når listen er kjedelig.