Migreerimine PPP-põhisest VPN-ist ilma selle eeldusi kopeerimata

VPN-i migratsioon on lõppenud siis, kui kasutajad, sihtkohad, nimeotsing ja tõrke käitumine on endiselt õiged, mitte siis, kui uus klient näitab rohelist ikooni. Vanad PPP-põhised juurutused kannavad eeldusi, mida kunagi kirja ei pandud: jagatud saladus, mis oli ühtlasi ainus identiteedikontroll, kindel aadressikogum, mille tulemüür on lubatud loendisse lisanud, DNS-järelliide, mille server saadab. Protokolli asendamine ilma nende eelduste loetlemiseta annab tunnelid, mis teeb käepigistuse, ja piiri, mida ei ole olemas. Alljärgnev järjekord on see, mida mina kasutan, ja viimane samm on see, mille meeskonnad vahele jätavad.

Samm 1: loetlege, mida vana ühendus pakub

Loend kirjutatakse, mitte ei jäeta meelde. Kirja pange toetatud kliendid, autentimisrollid, aadressikogumid, kaitstud võrgud, DNS-i nõuded ja teenuseload, mida iga kasutajagrupp vajab.

L2TP/IPsec puhul eraldage kaks kihti selgesõnaliselt. IPsec-partneri identiteet autendib masinad; PPP autendib kasutaja, tavaliselt CHAP-i või MSCHAPv2-ga.

Just selles eralduses peidavad vanad juurutused oma eeldusi. Iga kliendi jagatav eeljagatud võti autendib gruppi, mitte seadet, ja sageli on see ainus asi, mida kunagi on roteeritud. Kui PPP-konto on tegelik kasutajapõhine kontroll, öelge seda, sest asendus peab selle kontrolli taasesitama millegi muuga kui jagatud string. Pange kirja ka fikseeritud lähteaadressid ja kohaliku võrgu erandid, sest need on sõltuvused, mida keegi ei dokumenteeri enne, kui need katki lähevad.

Samm 2: kavandage asendus teadlikult

Asenduse valimine on nõudmistepõhine kaardistamine: protokoll ja hooldatud klient, mida organisatsioon toetab, kusjuures iga identiteedi- ja juurdepääsunõue maandub tegelikus mehhanismis. Jagatud saladus ei ole automaatselt samaväärne seadmepõhise võtme või sertifikaadiga ning kasutajapõhine PPP-konto ei ole samaväärne seadmesertifikaadiga.

Kooskõlastage aadressivahemikud enne kõike muud, sest asenduskogum, mis kattub kodu- või kontorivõrguga, tekitab tõrke, millel pole šifri tugevusega mingit seost. Kontrollige kogumit sama loendi vastu, mille koostasite vana teenuse jaoks, pluss see, mida uus klient vaikimisi eeldab. Kinnitage kaitstud võrkude tagasiteed ning kinnitage, et uus klient suudab saata või dokumenteerida DNS-järelliite, mida vana saatis. Need kaks punkti tekitavad rohkem migratsioonipileteid kui protokolli vahetus ise.

Samm 3: juurutage etappide kaupa ja kontrollige nii lubamist kui keelamist

Juurutage ühe esindava kasutaja ja ühe esindava rakendusega. Kaasake testi privaatne DNS-otsing, sest tunnel, mis jõuab aadressini, kuid ei suuda sisemist nime lahendada, on vaid pooleldi migreeritud. Kaasake ka oodatav mittekättesaadav olek: mis peaks juhtuma, kui tunnel katkeb, ja kas klient seda jõustab.

Seejärel testige sihtkohta, mis peaks jääma keelatuks. Lai ajutine lubamisreegel võib jätta uue tunneli terve mulje, samal ajal kui see vaikselt eemaldab autoriseerimispiiri, mida vana teenus jõustas, ja keegi ei märka seda enne auditit. Võrrelge lubamise ja keelamise tulemusi kõrvuti, samast kliendist, samas sessioonis. Hoidke vana teenust töös, kuni mõlemad veerud vastavad kavandile.

Enne administraatori juurdepääsu liigutamist kinnitage, et teil on volitatud taastetee, mis ei sõltu tunnelist, mida muudate.

Samm 4: võtke vana identiteet välja

Vana identiteedi korrektne väljavõtmine tähendab aegunud kasutajate ja seadme volituste tühistamist teenuse kaudu, millele need kuuluvad, ning seejärel vanade profiilide ja kuulajate eemaldamist, kui sõltuvusi enam ei jää. Kohaliku faili kustutamine ei tühista koopiat mujal ning vana kuulaja, mis ikka veel võtab vastu vana jagatud saladust, on jälgimata uks.

Sellel hetkel tasub aeglustada. Sülearvutis dekomisjonitud kliendiprofiil ei ole tühistatud volitus; volitus elab serveris ja jääb kehtima seni, kuni server lõpetab selle vastuvõtmise. Otsige vana konfiguratsiooni teisi koopiaid — testseadmed, unustatud telefon, kellegi alles hoitud paigaldaja — ja käsitlege kuulaja sulgemist hetkena, mil vana teenus tegelikult lõpeb. Seni on migratsioonil kaks esiust.

Vastuvõtukirje on esimese sammu loend, millele on lisatud veerg: mida uus kavand iga rea jaoks teeb ja kuidas te seda kontrollisite. See muudab protokolli uuendamise tõenditega teenusenõudeks.

Hoidke tulemus seotud sellega, mida teenus vajab, mitte protokolli nimega, sest kaasaegne protokoll, millesse on vanad eeldused kopeeritud, on sama risk parema raamistikuga. RFC 3193 kirjeldab, kuidas L2TP-d IPsec-i kohal kantakse, mis on kasulik meeldetuletus, et need kaks kihti olid alati eraldi otsused. Kui loendis on rida, mida te ei suuda seletada, peatuge ja tehke kindlaks, mis sellest sõltub. Migratsioon on valmis, kui nimekiri on igav.