Prelazak s VPN-a zasnovanog na PPP-u bez kopiranja njegovih pretpostavki

Migracija VPN-a gotova je kada su korisnici, odredišta, razrješavanje imena i ponašanje pri kvaru još uvijek ispravni, a ne kada novi klijent pokaže zelenu ikonu. Stara PPP okruženja nose pretpostavke koje nikada nisu zapisane: zajednička tajna koja je ujedno bila jedina provjera identiteta, fiksni adresni pool koji firewall drži na popisu dopuštenih, DNS sufiks koji poslužitelj gura. Zamjena protokola bez popisa tih pretpostavki daje tunel koji obavi handshake i granicu koja ne postoji. Postupak u nastavku je redoslijed koji ja koristim, a posljednji je korak onaj koji timovi preskaču.

Korak 1: popišite što stara veza pruža

Popis se zapisuje, a ne pamti. Zabilježite podržane klijente, uloge autentikacije, adresne poolove, zaštićene mreže, DNS zahtjeve i dopuštenja za usluge koja treba svaka skupina korisnika.

Za L2TP/IPsec izričito razdvojite dva sloja. Identitet IPsec partnera autentificira strojeve; PPP autentificira korisnika, obično s CHAP ili MSCHAPv2.

Upravo u tom razdvajanju stara okruženja skrivaju svoje pretpostavke. Zajednički unaprijed podijeljeni ključ koji dijeli svaki klijent autentificira skupinu, a ne uređaj, i često je jedino što je ikada rotirano. Ako je PPP račun stvarna kontrola po korisniku, recite to, jer zamjena mora reproducirati tu kontrolu nečim što nije zajednički niz znakova. Zabilježite i fiksne izvorne adrese te iznimke za lokalnu mrežu, jer to su ovisnosti koje nitko ne dokumentira dok se ne slome.

Korak 2: namjerno osmislite zamjenu

Odabir zamjene je preslikavanje zahtjeva po zahtjev: protokol i održavani klijent koje organizacija podupire, pri čemu svaki zahtjev za identitet i pristup završava u stvarnom mehanizmu. Zajednička tajna nije automatski jednaka ključu ili certifikatu po uređaju, a PPP račun po korisniku nije jednak certifikatu uređaja.

Uskladite adresne raspone prije svega ostaloga, jer zamjenski pool koji se preklapa s kućnim ili uredskim LAN-om stvara kvar koji nema veze s jačinom šifre. Provjerite pool prema istom popisu koji ste sastavili za staru uslugu, plus onome što novi klijent pretpostavlja po defaultu. Potvrdite povratno usmjeravanje za zaštićene mreže i potvrdite da novi klijent može gurati ili dokumentirati DNS sufiks koji je stari gurao. Te dvije stavke stvaraju više migracijskih zahtjeva od same promjene protokola.

Korak 3: uvedite postupno i provjerite i dopuštanje i odbijanje

Uvedite s jednim reprezentativnim korisnikom i jednom reprezentativnom aplikacijom. U test uključite privatno DNS razrješavanje, jer tunel koji dosegne adresu ali ne može razriješiti interno ime samo je napola migriran. Uključite i očekivano nedostupno stanje: što se treba dogoditi kad tunel padne i provodi li klijent to.

Zatim testirajte odredište koje treba ostati odbijeno. Široko privremeno pravilo dopuštanja može novi tunel učiniti naizgled zdravim dok tiho uklanja granicu ovlaštenja koju je stara usluga provodila, i nitko to ne primijeti do revizije. Usporedite rezultate dopuštanja i odbijanja jedan uz drugi, s istog klijenta, u istoj sesiji. Držite staru uslugu u pogonu dok se oba stupca ne poklope s nacrtom.

Prije nego premjestite administratorski pristup, potvrdite da imate ovlašten put oporavka koji ne ovisi o tunelu koji mijenjate.

Korak 4: povucite stari identitet

Ispravno povlačenje starog identiteta znači opozvati zastarjele korisnike i vjerodajnice uređaja kroz uslugu koja ih posjeduje, a zatim ukloniti stare profile i osluškivače kad više ne ostane ovisnosti. Brisanje lokalne datoteke ne opoziva kopiju drugdje, a stari osluškivač koji još prihvaća staru zajedničku tajnu su nenadzirana vrata.

Ta točka zaslužuje da usporimo. Deaktiviran klijentski profil na prijenosnom računalu nije opozvana vjerodajnica; vjerodajnica živi na poslužitelju i ostaje valjana dok je poslužitelj ne prestane prihvaćati. Provjerite postoje li druge kopije stare konfiguracije — testni uređaji, zaboravljen telefon, instalacijski program koji je netko sačuvao — i tretirajte gašenje osluškivača kao trenutak kada stara usluga uistinu prestaje. Do tada migracija ima dvoja prednja vrata.

Zapis o prihvaćanju je popis iz prvog koraka s dodanim stupcem: što novi nacrt čini za svaki redak i kako ste to provjerili. To pretvara nadogradnju protokola u zahtjev za uslugom s dokazima.

Držite ishod vezan uz ono što usluga treba, a ne uz naziv protokola, jer moderan protokol s prepisanim starim pretpostavkama isti je rizik s boljim okvirom. RFC 3193 opisuje kako se L2TP prenosi preko IPsec-a, što je koristan podsjetnik da su ta dva sloja oduvijek bila odvojene odluke. Ako popis ima redak koji ne možete objasniti, zaustavite se i otkrijte što o njemu ovisi. Migracija je gotova kad popis postane dosadan.