Migreer weg van ’n PPP-gebaseerde VPN sonder om sy aannames oor te neem

’n VPN-migrasie is eers klaar wanneer die gebruikers, bestemmings, naamresolusie en foutgedrag almal nog korrek is, nie wanneer die nuwe kliënt ’n groen ikoon wys nie. Ou PPP-gebaseerde ontplooiings dra aannames wat nooit neergeskryf is nie: ’n gedeelde geheim wat as die enigste identiteitstoets gedien het, ’n vaste adrespoel wat die firewall op sy lys het, ’n DNS-agtervoegsel wat die bediener stuur. Om die protokol te vervang sonder om daardie aannames te inventariseer, lewer ’n tonnel wat die handdruk voltooi en ’n grens wat nie bestaan nie. Die deurloop hieronder is die volgorde wat ek gebruik, en die laaste stap is die een wat spanne oorslaan.

Stap 1: inventariseer wat die ou verbinding bied

Die inventaris word geskryf, nie onthou nie. Teken die ondersteunde kliënte, die verifikasierolle, die adrespoele, die beskermde netwerke, die DNS-vereistes en die dienstoestemmings aan wat elke gebruikersgroep nodig het.

Vir L2TP/IPsec moet jy die twee lae uitdruklik skei. Die identiteit van die IPsec-eweknie verifieer die masjiene; PPP verifieer die gebruiker, gewoonlik met CHAP of MSCHAPv2.

Daardie skeiding is waar ou ontplooiings hulle aannames wegsteek. ’n Gedeelde voorafgedeelde sleutel wat elke kliënt deel, verifieer ’n groep eerder as ’n toestel, en dit is dikwels die enigste ding wat ooit geroteer is. As die PPP-rekening die werklike beheer per gebruiker is, sê so, want die vervanging moet daardie beheer reproduseer met iets wat nie ’n gedeelde string is nie. Let ook op vaste bronadresse en plaaslike-netwerk-uitsonderings, want dit is die afhanklikhede wat niemand dokumenteer voordat dit breek nie.

Stap 2: ontwerp die vervanging doelbewus

Om die vervanging te kies is ’n vereiste-vir-vereiste-kartering: ’n protokol en ’n onderhoude kliënt wat die organisasie ondersteun, met elke identiteits- en toegangsvereiste wat in ’n werklike meganisme beland. ’n Gedeelde geheim is nie outomaties gelyk aan ’n sleutel of sertifikaat per toestel nie, en ’n PPP-rekening per gebruiker is nie gelyk aan ’n toestelsertifikaat nie.

Koördineer adresreekse voor enigiets anders, want ’n vervangingspoel wat ’n tuis- of kantoor-LAN oorvleuel, skep ’n fout wat niks met syfersterkte te doen het nie. Kontroleer die poel teen dieselfde lys wat jy vir die ou diens gebou het, plus wat die nuwe kliënt by verstek aanneem. Bevestig die terugroetering vir die beskermde netwerke, en bevestig dat die nuwe kliënt die DNS-agtervoegsel kan stuur of dokumenteer wat die ou een gestuur het. Daardie twee items veroorsaak meer migrasiekaartjies as die protokolverandering self.

Stap 3: ontplooi in fases en verifieer beide toestaan en weier

Ontplooi met een verteenwoordigende gebruiker en een verteenwoordigende toepassing. Sluit private DNS-resolusie in die toets in, want ’n tonnel wat ’n adres bereik maar nie ’n interne naam kan oplos nie, is net half gemigreer. Sluit ook die verwagte onbeskikbare toestand in: wat moet gebeur wanneer die tonnel val, en of die kliënt dit afdwing.

Toets dan ’n bestemming wat geweier moet bly. ’n Breë tydelike toestaan-reël kan die nuwe tonnel gesond laat lyk terwyl dit stilweg die magtigingsgrens verwyder wat die ou diens afgedwing het, en niemand merk dit tot ’n oudit nie. Vergelyk toestaan- en weier-uitslae langs mekaar, vanaf dieselfde kliënt, in dieselfde sessie. Hou die ou diens aan die gang totdat albei kolomme by die ontwerp pas.

Voordat jy administratiewe toegang skuif, bevestig dat jy ’n gemagtigde herstelpad het wat nie van die tonnel afhang wat jy verander nie.

Stap 4: onttrek die ou identiteit

Om die ou identiteit behoorlik te onttrek, beteken om verouderde gebruikers en toestelgeloofsbriewe deur die diens wat hulle besit te herroep, en dan ou profiele en luisteraars te verwyder sodra geen afhanklikheid oorbly nie. Die verwydering van ’n plaaslike lêer herroep nie ’n kopie elders nie, en ’n ou luisteraar wat steeds die ou gedeelde geheim aanvaar, is ’n deur sonder toesig.

Daardie punt is werd om vir stadiger te gaan. ’n Ontslae kliëntprofiel op ’n skootrekenaar is nie ’n herroepte geloofsbrief nie; die geloofsbrief woon op die bediener en bly geldig totdat die bediener ophou om dit te aanvaar. Soek ander kopieë van die ou konfigurasie — toestelle vir toetsing, ’n vergete selfoon, ’n installeerder wat iemand gehou het — en beskou die afskakeling van die luisteraar as die oomblik waarop die ou diens werklik eindig. Tot dan het die migrasie twee voordeure.

Die aanvaardingsrekord is die inventaris van stap een met ’n kolom bygevoeg: wat die nuwe ontwerp vir elke ry doen, en hoe jy dit geverifieer het. Dit verander ’n protokolopgradering in ’n diensvereiste met bewyse.

Hou die uitkoms gekoppel aan wat die diens nodig het eerder as aan die protokolnaam, want ’n moderne protokol met die ou aannames daarin oorgedra, is dieselfde risiko met ’n beter raamwerk. RFC 3193 beskryf hoe L2TP oor IPsec gedra word, wat ’n nuttige herinnering is dat die twee lae altyd afsonderlike besluite was. As die inventaris ’n ry het wat jy nie kan verduidelik nie, stop en vind uit wat daarvan afhang. Die migrasie is klaar wanneer die lys vervelig is.