Flytting bort frå ein PPP-basert VPN utan å kopiere føresetnadene

Ei VPN-migrering er ferdig når brukarane, destinasjonane, namneoppslaget og åtferda ved feil framleis er riktige, ikkje når den nye klienten viser eit grønt ikon. Gamle PPP-baserte installasjonar ber føresetnader som aldri vart skrivne ned: ein delt hemmelegheit som òg var den einaste identitetskontrollen, ein fast adressepulje som brannmuren har på tillatne-lista, og eit DNS-suffiks som tenaren skyv ut. Å byte protokoll utan å kartleggje desse føresetnadene gjev ein tunnel som fullfører handtrykket, og ei grense som ikkje finst. Rekkjefølgja nedanfor er den eg brukar, og det siste trinnet er det teama hoppar over.

Trinn 1: kartlegg kva den gamle sambindinga gjev

Kartlegginga vert skriven, ikkje hugsa. Registrer dei støtta klientane, autentiseringsrollene, adressepuljene, dei verna netta, DNS-krava og tenestetillatingane kvar brukargruppe treng.

For L2TP/IPsec må du skilje dei to laga eksplisitt. Identiteten til IPsec-partnaren autentiserer maskinane; PPP autentiserer brukaren, vanlegvis med CHAP eller MSCHAPv2.

Det er i denne delinga gamle installasjonar gøymer føresetnadene sine. Ein førehandsdelt nøkkel som alle klientar deler, autentiserer ei gruppe og ikkje eit apparat, og han er ofte det einaste som nokon gong har vorte rotert. Viss PPP-kontoen er den reelle kontrollen per brukar, seie det, fordi erstatninga må attskape den kontrollen med noko som ikkje er ein delt streng. Noter òg faste kjeldadresser og unntak for lokalnettet, for det er avhengnadene ingen dokumenterer før dei bryt.

Trinn 2: design erstatninga medvite

Å velje erstatninga er ei krav-for-krav-tildeling: ein protokoll og ein vedlikehalden klient organisasjonen støttar, der kvart identitets- og tilgangskrav landar i ein faktisk mekanisme. Ei delt hemmelegheit er ikkje automatisk det same som ein nøkkel eller eit sertifikat per eining, og ein PPP-konto per brukar er ikkje det same som eit einingssertifikat.

Samordne adresseområde før alt anna, fordi ein erstatningspulje som overlappar eit heime- eller kontor-LAN skapar ein feil som ikkje har noko med chifferstyrke å gjere. Kontroller puljen mot den same lista du laga for den gamle tenesta, pluss det den nye klienten tek som standard. Stadfest returrutaren for dei verna netta, og stadfest at den nye klienten kan skyve ut eller dokumentere DNS-suffikset den gamle skauv ut. Desse to punkta gjev fleire migreringssaker enn sjølve protokollbytet.

Trinn 3: innfør trinnvis og verifiser både tillate og avvise

Innfør med ein representativ brukar og ein representativ applikasjon. Ta med privat DNS-oppslag i testen, fordi ein tunnel som når ei adresse men ikkje kan slå opp eit internt namn berre er halvt migrert. Ta òg med den venta utilgjengelege tilstanden: kva som skal skje når tunnelen fell, og om klienten handhevar det.

Test deretter ein destinasjon som skal halde fram med å vere avvist. Ein brei mellombels tillatingsregel kan få den nye tunnelen til å sjå sunn ut medan han stille fjernar autorisasjonsgrensa den gamle tenesta handheva, og ingen merkar det før ein revisjon. Samanlikn tillate- og avvise-resultat side om side, frå same klient, i same økt. Hald den gamle tenesta i drift til begge kolonnane stemmer med designet.

Før du flyttar administrator tilgang, må du stadfeste at du har ein autorisert gjenopprettingsveg som ikkje er avhengig av tunnelen du endrar.

Trinn 4: avvikle den gamle identiteten

Korrekt avvikling av den gamle identiteten tyder å tilbakekalle utdaterte brukarar og einingar sine legitimasjonar gjennom tenesta som eig dei, og deretter fjerne gamle profilar og lyttarar når ingen avhengnad står att. Sletting av ei lokal fil tilbakekallar ikkje ein kopi ein annan stad, og ein gammal lyttar som framleis godtek den gamle delte hemmelegheita er ei dør utan overvaking.

Det punktet er verdt å bremse for. Ein avvikla klientprofil på ein berbar PC er ikkje ein tilbakekalla legitimasjon; legitimasjonen lever på tenaren og held fram med å gjelde til tenaren sluttar å godta han. Sjå etter andre kopiar av den gamle konfigurasjonen — testeingar, ein gløymd telefon, eit installasjonsprogram nokon har teke vare på — og handsam nedstenginga av lyttaren som augneblinken den gamle tenesta faktisk sluttar. Inntil då har migreringa to framdører.

Akseptprotokollen er kartlegginga frå trinn éin med ein kolonne lagt til: kva det nye designet gjer for kvar rad, og korleis du verifiserte det. Det gjer ein protokolloppgradering til eit tenestekrav med prov.

Hald resultatet bunde til det tenesta treng og ikkje til protokollnamnet, fordi ein moderne protokoll med dei gamle føresetnadene kopierte inn er den same risikoen med eit betre rammeverk. RFC 3193 skildrar korleis L2TP vert bore over IPsec, noko som er ei nyttig påminning om at dei to laga alltid var separate avgjerder. Viss kartlegginga har ei rad du ikkje kan forklare, stopp og finn ut kva som er avhengig av henne. Migreringa er ferdig når lista er keisam.