Flytning væk fra en PPP-baseret VPN uden at kopiere dens antagelser

En VPN-migrering er færdig, når brugerne, destinationerne, navneopslag og fejlopførsel stadig alle er korrekte, ikke når den nye klient viser et grønt ikon. Gamle PPP-baserede udrulninger bærer antagelser, der aldrig blev skrevet ned: en delt hemmelighed, der også var den eneste identitetskontrol, en fast adressepulje, som firewallen har på tilladelseslisten, et DNS-suffiks, som serveren sender. At udskifte protokollen uden at kortlægge disse antagelser giver en tunnel, der gennemfører håndtrykket, og en grænse, der ikke findes. Gennemgangen nedenfor er den rækkefølge, jeg bruger, og det sidste trin er det, som teams springer over.

Trin 1: kortlæg, hvad den gamle forbindelse leverer

Kortlægningen skrives ned i stedet for at huskes. Registrer de understøttede klienter, autentificeringsrollerne, adressepuljerne, de beskyttede netværk, DNS-kravene og de service tilladelser, som hver brugergruppe har brug for.

For L2TP/IPsec skal du eksplicit adskille de to lag. IPsec-peerens identitet autentificerer maskinerne; PPP autentificerer brugeren, normalt med CHAP eller MSCHAPv2.

Det er i denne adskillelse, at gamle udrulninger skjuler deres antagelser. En forud delt nøgle, som alle klienter deler, autentificerer en gruppe frem for en enhed, og den er ofte det eneste, der nogensinde er roteret. Hvis PPP-kontoen er den reelle kontrol pr. bruger, så sig det, fordi erstatningen skal genskabe den kontrol med noget, der ikke er en delt streng. Notér også faste kildeadresser og undtagelser for det lokale netværk, for det er de afhængigheder, som ingen dokumenterer, før de bryder.

Trin 2: design erstatningen bevidst

At vælge erstatningen er en krav-for-krav-mapping: en protokol og en vedligeholdt klient, som organisationen understøtter, hvor hvert identitets- og adgangskrav lander i en faktisk mekanisme. En delt hemmelighed er ikke automatisk lig med en nøgle eller et certifikat pr. enhed, og en PPP-konto pr. bruger er ikke lig med et enhedscertifikat.

Koordinér adresseområder før alt andet, fordi en erstatningspulje, der overlapper et hjemme- eller kontor-LAN, skaber en fejl, der intet har med cifferstyrke at gøre. Kontrollér puljen mod den samme liste, du byggede til den gamle tjeneste, plus det, den nye klient antager som standard. Bekræft returroutingen for de beskyttede netværk, og bekræft at den nye klient kan sende eller dokumentere det DNS-suffiks, den gamle sendte. De to punkter giver flere migreringssager end selve protokolskiftet.

Trin 3: udrul i etaper, og verificér både tillad og afvis

Udrul med én repræsentativ bruger og én repræsentativ applikation. Medtag privat DNS-opslag i testen, fordi en tunnel, der når en adresse, men ikke kan slå et internt navn op, kun er halvt migreret. Medtag også den forventede utilgængelige tilstand: hvad der skal ske, når tunnelen falder, og om klienten håndhæver det.

Test derefter en destination, der skal forblive afvist. En bred midlertidig tilladelsesregel kan få den nye tunnel til at se sund ud, mens den stille fjerner den autorisationsgrænse, den gamle tjeneste håndhævede, og ingen opdager det før en revision. Sammenlign tillad- og afvis-resultater side om side, fra samme klient, i samme session. Hold den gamle tjeneste kørende, indtil begge kolonner matcher designet.

Før du flytter administratoradgang, skal du bekræfte, at du har en autoriseret gendannelsesvej, der ikke afhænger af den tunnel, du ændrer.

Trin 4: udfas den gamle identitet

Korrekt udfasning af den gamle identitet betyder at tilbagekalde forældede brugere og enhedsoplysninger gennem den tjeneste, der ejer dem, og derefter fjerne gamle profiler og lyttere, når ingen afhængighed er tilbage. Sletning af en lokal fil tilbagekalder ikke en kopi et andet sted, og en gammel lytter, der stadig accepterer den gamle delte hemmelighed, er en dør uden overvågning.

Det punkt er værd at sætte tempoet ned for. En afviklet klientprofil på en bærbar computer er ikke en tilbagekaldt adgangsoplysning; oplysningen lever på serveren og forbliver gyldig, indtil serveren holder op med at acceptere den. Se efter andre kopier af den gamle konfiguration — testenheder, en glemt telefon, et installationsprogram, som nogen har gemt — og betragt nedlukningen af lytteren som det øjeblik, hvor den gamle tjeneste faktisk slutter. Indtil da har migreringen to fordøre.

Acceptregistreringen er kortlægningen fra trin et med en kolonne tilføjet: hvad det nye design gør for hver række, og hvordan du verificerede det. Det gør en protokolopgradering til et servicekrav med evidens.

Hold resultatet knyttet til, hvad tjenesten har brug for, frem for protokollens navn, fordi en moderne protokol med de gamle antagelser kopieret ind i den er den samme risiko med en bedre indramning. RFC 3193 beskriver, hvordan L2TP bæres over IPsec, hvilket er en nyttig påmindelse om, at de to lag altid var separate beslutninger. Hvis kortlægningen har en række, du ikke kan forklare, så stop og find ud af, hvad der afhænger af den. Migreringen er færdig, når listen er kedelig.