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

Migracija VPN-a je završena 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 postrojenja nose pretpostavke koje nikada nisu zapisane: zajednička tajna koja je služila kao jedina provjera identiteta, fiksni adresni pool koji firewall stavlja na listu dozvoljenih, DNS sufiks koji server gura. Zamjena protokola bez popisa tih pretpostavki daje tunel koji obavi handshake i granicu koja ne postoji. Postupak ispod je redoslijed koji ja koristim, a posljednji korak je onaj koji timovi preskaču.

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

Popis se zapisuje, a ne pamti. Zabilježite podržane klijente, uloge autentifikacije, adresne poolove, zaštićene mreže, DNS zahtjeve i dozvole za usluge koje svaka grupa korisnika treba.

Za L2TP/IPsec eksplicitno razdvojite dva sloja. Identitet IPsec partnera autentifikuje mašine; PPP autentifikuje korisnika, obično uz CHAP ili MSCHAPv2.

Upravo u tom razdvajanju stara postrojenja skrivaju svoje pretpostavke. Zajednički unaprijed podijeljeni ključ koji koristi svaki klijent autentifikuje grupu, a ne uređaj, i često je jedina stvar koja je ikada rotirana. Ako je PPP nalog stvarna kontrola po korisniku, recite to, jer zamjena mora reproducirati tu kontrolu nečim što nije zajednički string. Zabilježite i fiksne izvorne adrese i izuzetke za lokalnu mrežu, jer to su zavisnosti koje niko ne dokumentuje dok se ne pokvare.

Korak 2: namjerno projektujte zamjenu

Odabir zamjene je mapiranje zahtjeva po zahtjev: protokol i održavani klijent koje organizacija podržava, 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 nalog po korisniku nije jednak certifikatu uređaja.

Uskladite adresne raspone prije svega ostalog, jer zamjenski pool koji se preklapa s kućnim ili uredskim LAN-om stvara kvar koji nema veze sa snagom šifre. Provjerite pool prema istoj listi koju ste napravili za staru uslugu, plus ono što novi klijent podrazumijeva. Potvrdite povratno rutiranje za zaštićene mreže i potvrdite da novi klijent može gurati ili dokumentovati DNS sufiks koji je stari gurao. Te dvije stavke uzrokuju više migracijskih tiketa od same promjene protokola.

Korak 3: uvedite postepeno i provjerite i dozvolu 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 pola migriran. Uključite i očekivano nedostupno stanje: šta treba da se dogodi kada tunel padne i da li ga klijent provodi.

Zatim testirajte odredište koje treba da ostane odbijeno. Široko privremeno pravilo dozvole može učiniti novi tunel zdravim dok tiho uklanja granicu autorizacije koju je stara usluga provodila, i niko to ne primijeti do revizije. Uporedite rezultate dozvole i odbijanja jedan uz drugi, s istog klijenta, u istoj sesiji. Držite staru uslugu u radu dok se oba stupca ne poklope s projektom.

Prije nego premjestite administratorski pristup, potvrdite da imate ovlašten put oporavka koji ne zavisi od tunela koji mijenjate.

Korak 4: povucite stari identitet

Ispravno povlačenje starog identiteta znači opoziv zastarjelih korisnika i akreditiva uređaja kroz uslugu koja ih posjeduje, a zatim uklanjanje starih profila i listenera kada više ne ostane zavisnosti. Brisanje lokalne datoteke ne opoziva kopiju negdje drugdje, a stari listener koji još prihvata staru zajedničku tajnu su nenadgledana vrata.

Ta točka zaslužuje da usporimo. Deaktiviran klijentski profil na laptopu nije opozvan akreditiv; akreditiv živi na serveru i ostaje valjan dok server ne prestane da ga prihvata. Provjerite postoje li druge kopije stare konfiguracije — testni uređaji, zaboravljen telefon, instalater koji je neko sačuvao — i tretirajte gašenje listenera kao trenutak kada stara usluga zaista prestaje. Do tada migracija ima dvoja prednja vrata.

Zapis o prihvatanju je popis iz prvog koraka s dodanim stupcem: šta novi dizajn radi za svaki red i kako ste to provjerili. To pretvara nadogradnju protokola u zahtjev za uslugu s dokazima.

Držite ishod vezan za ono što usluga treba, a ne za ime protokola, jer moderan protokol s kopiranim starim pretpostavkama je isti rizik s boljim okvirom. RFC 3193 opisuje kako se L2TP prenosi preko IPsec-a, što je koristan podsjetnik da su ta dva sloja oduvijek bile odvojene odluke. Ako popis ima red koji ne možete objasniti, zaustavite se i otkrijte šta o njemu zavisi. Migracija je gotova kada lista postane dosadna.