Selitev z VPN na osnovi PPP brez kopiranja njenih predpostavk

Selitev VPN je končana, ko so uporabniki, cilji, razreševanje imen in vedenje ob napaki še vedno pravilni, ne ko novi odjemalec pokaže zeleno ikono. Stare namestitve na osnovi PPP nosijo predpostavke, ki nikoli niso bile zapisane: skupna skrivnost, ki je bila tudi edino preverjanje identitete, fiksni nabor naslovov, ki ga požarni zid drži na seznamu dovoljenih, in pripona DNS, ki jo pošilja strežnik. Zamenjava protokola brez popisa teh predpostavk ustvari tunel, ki opravi handshake, in mejo, ki ne obstaja. Spodnji vrstni red je tisti, ki ga uporabljam jaz, zadnji korak pa je tisti, ki ga ekipe preskočijo.

Korak 1: popišite, kaj zagotavlja stara povezava

Popis se zapiše, ne zapomni. Zapišite podprte odjemalce, vloge preverjanja pristnosti, nabore naslovov, zaščitena omrežja, zahteve DNS in dovoljenja za storitve, ki jih potrebuje vsaka skupina uporabnikov.

Pri L2TP/IPsec oba sloja izrecno ločite. Identiteta partnerja IPsec preverja stroje; PPP preverja uporabnika, običajno s CHAP ali MSCHAPv2.

Prav v tej ločitvi stare namestitve skrivajo svoje predpostavke. Skupni vnaprej dogovorjeni ključ, ki ga deli vsak odjemalec, preverja skupino in ne naprave, in pogosto je to edina stvar, ki je bila kdaj zamenjana. Če je račun PPP resnični nadzor na uporabnika, povejte to, ker mora zamenjava ta nadzor ponoviti z nečim, kar ni skupni niz. Zapišite tudi fiksne izvorne naslove in izjeme za lokalno omrežje, ker so to odvisnosti, ki jih nihče ne dokumentira, dokler se ne zlomijo.

Korak 2: zamenjavo zasnujte namerno

Izbira zamenjave je preslikava zahteve po zahtevi: protokol in vzdrževani odjemalec, ki ju organizacija podpira, pri čemer vsaka zahteva po identiteti in dostopu pristane v resničnem mehanizmu. Skupna skrivnost ni samodejno enaka ključu ali potrdilu na napravo, račun PPP na uporabnika pa ni enak potrdilu naprave.

Naslovna območja uskladite pred vsem drugim, ker nadomestni nabor, ki se prekriva z domačim ali pisarniškim omrežjem LAN, ustvari napako, ki nima nič skupnega z močjo šifre. Nabor preverite proti istemu seznamu, ki ste ga sestavili za staro storitev, plus proti temu, kar novi odjemalec privzeto predvideva. Potrdite povratno usmerjanje za zaščitena omrežja in potrdite, da lahko novi odjemalec pošlje ali dokumentira pripono DNS, ki jo je pošiljal stari. Ti dve postavki povzročita več selitvenih zahtevkov kot sama sprememba protokola.

Korak 3: uvajajte postopoma in preverite dovoljenje in zavrnitev

Uvedite z enim reprezentativnim uporabnikom in eno reprezentativno aplikacijo. V test vključite zasebno razreševanje DNS, ker je tunel, ki doseže naslov, a ne more razrešiti notranjega imena, le napol preseljen. Vključite tudi pričakovano stanje nedostopnosti: kaj se mora zgoditi, ko tunel pade, in ali odjemalec to uveljavi.

Nato preizkusite cilj, ki mora ostati zavrnjen. Široko začasno pravilo dovoljenja lahko naredi novi tunel videti zdrav, medtem ko tiho odstrani mejo pooblastila, ki jo je uveljavljala stara storitev, in nihče tega ne opazi do revizije. Primerjajte rezultate dovoljenja in zavrnitve drug ob drugem, z istega odjemalca, v isti seji. Ohranjajte staro storitev v delovanju, dokler se oba stolpca ne ujemata z zasnovo.

Preden premaknete skrbniški dostop, potrdite, da imate pooblaščeno pot obnovitve, ki ni odvisna od tunela, ki ga spreminjate.

Korak 4: umaknite staro identiteto

Pravilen umik stare identitete pomeni preklic zastarelih uporabnikov in poverilnic naprav prek storitve, ki jih ima v lasti, nato pa odstranitev starih profilov in poslušalcev, ko ne ostane nobena odvisnost. Brisanje lokalne datoteke ne prekliče kopije drugje, stari poslušalec, ki še vedno sprejema staro skupno skrivnost, pa so vrata brez nadzora.

Na tej točki se je vredno ustaviti. Umaknjen profil odjemalca na prenosniku ni preklicana poverilnica; poverilnica živi na strežniku in ostane veljavna, dokler je strežnik ne preneha sprejemati. Poiščite druge kopije stare konfiguracije — testne naprave, pozabljen telefon, namestitveni program, ki ga je nekdo shranil — in izklop poslušalca obravnavajte kot trenutek, ko se stara storitev resnično konča. Do takrat ima selitev dvoje prednjih vrat.

Zapis o prevzemu je popis iz prvega koraka z dodanim stolpcem: kaj nova zasnova naredi za vsako vrstico in kako ste to preverili. To spremeni nadgradnjo protokola v zahtevo za storitev z dokazi.

Rezultat držite vezan na to, kar storitev potrebuje, ne na ime protokola, ker je sodoben protokol s prepisanimi starimi predpostavkami isto tveganje z boljšim okvirom. RFC 3193 opisuje, kako se L2TP prenaša prek IPsec, kar je koristen opomnik, da sta bila ta dva sloja vedno ločeni odločitvi. Če ima popis vrstico, ki je ne znate razložiti, se ustavite in odkrijte, od česa je odvisna. Selitev je končana, ko je seznam dolgočasen.