Perėjimas nuo PPP pagrindu veikiančio VPN nekopijuojant jo prielaidų

VPN migracija baigiama tada, kai naudotojai, tikslai, vardų skyrimas ir gedimo elgsena vis dar teisingi, o ne tada, kai naujas klientas rodo žalią piktogramą. Senos PPP pagrindu veikiančios diegimo aplinkos neša prielaidas, kurios niekada nebuvo užrašytos: bendra paslaptis, kuri kartu buvo vienintelė tapatybės patikra, fiksuotas adresų telkinys, kurį ugniasienė laiko leidžiamųjų sąraše, ir DNS priesaga, kurią serveris siunčia. Pakeitus protokolą neinventorinus šių prielaidų gaunamas tunelis, kuris atlieka rankos paspaudimą, ir riba, kurios nėra. Žemiau pateikta tvarka yra ta, kurią naudoju aš, o paskutinis žingsnis yra tas, kurį komandos praleidžia.

1 žingsnis: suinventorinkite, ką suteikia senasis ryšys

Inventorius užrašomas, o ne įsimenamas. Užrašykite palaikomus klientus, autentifikavimo vaidmenis, adresų telkinius, saugomus tinklus, DNS reikalavimus ir paslaugų leidimus, kurių reikia kiekvienai naudotojų grupei.

L2TP/IPsec atveju aiškiai atskirkite du sluoksnius. IPsec partnerio tapatybė autentifikuoja mašinas; PPP autentifikuoja naudotoją, dažniausiai CHAP arba MSCHAPv2.

Būtent šiame atskyrime senos diegimo aplinkos slepia savo prielaidas. Iš anksto bendrinamas raktas, kurį naudoja kiekvienas klientas, autentifikuoja grupę, o ne įrenginį, ir dažnai tai vienintelis dalykas, kuris kada nors buvo pakeistas. Jei PPP paskyra yra tikroji kiekvieno naudotojo kontrolė, pasakykite tai, nes pakaitalas turi atkurti tą kontrolę kažkuo, kas nėra bendra eilutė. Užrašykite ir fiksuotus šaltinio adresus bei vietinio tinklo išimtis, nes tai priklausomybės, kurių niekas nedokumentuoja, kol jos nesugenda.

2 žingsnis: sąmoningai suprojektuokite pakaitalą

Pakaitalo pasirinkimas yra reikalavimų pagal reikalavimą susiejimas: organizacijos palaikomas protokolas ir prižiūrimas klientas, o kiekvienas tapatybės ir prieigos reikalavimas atsiduria realiame mechanizme. Bendra paslaptis automatiškai nelygi kiekvieno įrenginio raktui ar sertifikatui, o kiekvieno naudotojo PPP paskyra nelygi įrenginio sertifikatui.

Adresų diapazonus suderinkite pirmiausia, nes pakaitalo telkinys, persidengiantis su namų ar biuro LAN, sukuria gedimą, neturintį nieko bendra su šifro stiprumu. Patikrinkite telkinį pagal tą patį sąrašą, kurį sudarėte senajai paslaugai, ir pagal tai, ką naujasis klientas laiko numatytuoju. Patvirtinkite saugomų tinklų grįžtamąjį maršrutizavimą ir patvirtinkite, kad naujasis klientas gali siųsti arba dokumentuoti DNS priesagą, kurią siuntė senasis. Šie du punktai sukelia daugiau migracijos bilietų nei pats protokolo pakeitimas.

3 žingsnis: diegkite etapais ir patikrinkite ir leidimą, ir draudimą

Diekite su vienu reprezentatyviu naudotoju ir viena reprezentatyvia programa. Į testą įtraukite privatų DNS skyrimą, nes tunelis, kuris pasiekia adresą, bet negali išspręsti vidinio vardo, yra tik pusiau migruotas. Įtraukite ir laukiamą nepasiekiamumo būseną: kas turi atsitikti, kai tunelis nukrenta, ir ar klientas tai įgyvendina.

Tada išbandykite tikslą, kuris turi likti uždraustas. Plati laikina leidimo taisyklė gali padaryti naują tunelį sveiką, tuo pat metu tyliai pašalindama autorizacijos ribą, kurią taikė senoji paslauga, ir niekas to nepastebi iki audito. Palyginkite leidimo ir draudimo rezultatus vienas šalia kito, iš to paties kliento, toje pačioje sesijoje. Laikykite senąją paslaugą veikiančią, kol abu stulpeliai atitiks projektą.

Prieš perkeldami administratoriaus prieigą, patvirtinkite, kad turite įgaliotą atkūrimo kelią, nepriklausantį nuo tunelio, kurį keičiate.

4 žingsnis: išimkite senąją tapatybę

Tinkamai išimti senąją tapatybę reiškia atšaukti pasenusius naudotojus ir įrenginių kredencialus per juos valdančią paslaugą, tada pašalinti senus profilius ir klausytojus, kai nebelieka priklausomybių. Vietinio failo ištrynimas neatšaukia kopijos kitur, o senas klausytojas, kuris vis dar priima seną bendrą paslaptį, yra nepriežiūrimos durys.

Šiame taške verta sulėtinti. Nebeveikiantis kliento profilis nešiojamajame kompiuteryje nėra atšauktas kredencialas; kredencialas gyvena serveryje ir lieka galiojantis, kol serveris nustoja jį priimti. Ieškokite kitų senos konfigūracijos kopijų — testinių įrenginių, pamiršto telefono, kažkieno pasilikto diegėjo — ir laikykite klausytojo išjungimą tuo momentu, kai senoji paslauga tikrai baigiasi. Iki tol migracija turi dvejas priekines duris.

Priėmimo įrašas yra pirmojo žingsnio inventorius su pridėtu stulpeliu: ką naujasis projektas daro kiekvienai eilutei ir kaip tai patikrinote. Tai paverčia protokolo atnaujinimą paslaugos reikalavimu su įrodymais.

Laikykite rezultatą susietą su tuo, ko reikia paslaugai, o ne su protokolo pavadinimu, nes modernus protokolas su į jį nukopijuotomis senomis prielaidomis yra ta pati rizika su geresniu rėmu. RFC 3193 aprašo, kaip L2TP perduodamas per IPsec, o tai naudingas priminimas, kad du sluoksniai visada buvo atskiri sprendimai. Jei inventoriuje yra eilutė, kurios negalite paaiškinti, sustokite ir išsiaiškinkite, kas nuo jos priklauso. Migracija baigiama, kai sąrašas tampa nuobodus.