Pāreja no PPP balstīta VPN, nekopējot tā pieņēmumus

VPN migrācija ir pabeigta, kad lietotāji, galamērķi, nosaukumu atrisināšana un uzvedība kļūmes laikā joprojām ir pareiza, nevis kad jaunais klients rāda zaļu ikonu. Vecās PPP balstītās instalācijas nes sev līdzi pieņēmumus, kas nekad nav pierakstīti: kopīgs noslēpums, kas reizē bija vienīgā identitātes pārbaude, fiksēta adrešu kopa, ko ugunsmūris tur atļauto sarakstā, un DNS sufikss, ko serveris sūta. Protokola nomaiņa, neuzskaitot šos pieņēmumus, rada tuneli, kas veic rokasspiedienu, un robežu, kas neeksistē. Zemāk sniegtā secība ir tā, ko izmantoju es, un pēdējais solis ir tas, ko komandas izlaiž.

1. solis: uzskaitiet, ko nodrošina vecais savienojums

Uzskaite tiek rakstīta, nevis atcerēta. Pierakstiet atbalstītos klientus, autentifikācijas lomas, adrešu kopas, aizsargātos tīklus, DNS prasības un pakalpojumu atļaujas, kas nepieciešamas katrai lietotāju grupai.

L2TP/IPsec gadījumā skaidri atdaliet abus slāņus. IPsec partnera identitāte autentificē mašīnas; PPP autentificē lietotāju, parasti ar CHAP vai MSCHAPv2.

Tieši šajā atdalījumā vecās instalācijas slēpj savus pieņēmumus. Iepriekš kopīgota atslēga, ko izmanto katrs klients, autentificē grupu, nevis ierīci, un bieži vien tas ir vienīgais, kas jebkad ir mainīts. Ja PPP konts ir īstā katra lietotāja kontrole, pasakiet to, jo aizstājējam šī kontrole jāatveido ar kaut ko, kas nav kopīga virkne. Pierakstiet arī fiksētās avota adreses un vietējā tīkla izņēmumus, jo tās ir atkarības, ko neviens nedokumentē, līdz tās salūzt.

2. solis: apzināti projektējiet aizstājēju

Aizstājēja izvēle ir prasību pa prasībai kartēšana: protokols un uzturēts klients, ko organizācija atbalsta, un katra identitātes un piekļuves prasība nonāk reālā mehānismā. Kopīgs noslēpums automātiski nav līdzvērtīgs atslēgai vai sertifikātam katrai ierīcei, un PPP konts katram lietotājam nav līdzvērtīgs ierīces sertifikātam.

Adrešu diapazonus saskaņojiet pirms visa cita, jo aizstājēju kopa, kas pārklājas ar mājas vai biroja LAN, rada kļūmi, kam nav nekāda sakara ar šifra stiprumu. Pārbaudiet kopu pret to pašu sarakstu, ko veidojāt vecajam pakalpojumam, plus to, ko jaunais klients pieņem pēc noklusējuma. Apstipriniet aizsargāto tīklu atgriešanās maršrutēšanu un apstipriniet, ka jaunais klients var nosūtīt vai dokumentēt to DNS sufiksu, ko sūtīja vecais. Šie divi punkti rada vairāk migrācijas biļešu nekā pati protokola maiņa.

3. solis: ieviesiet pakāpeniski un pārbaudiet gan atļauju, gan aizliegumu

Ieviesiet ar vienu reprezentatīvu lietotāju un vienu reprezentatīvu lietojumprogrammu. Iekļaujiet testā privāto DNS atrisināšanu, jo tunelis, kas sasniedz adresi, bet nevar atrisināt iekšēju nosaukumu, ir tikai pa pusei migrēts. Iekļaujiet arī gaidīto nepieejamības stāvokli: kas jānotiek, kad tunelis nokrīt, un vai klients to īsteno.

Pēc tam pārbaudiet galamērķi, kam jāpaliek aizliegtam. Plašs pagaidu atļaujas noteikums var likt jaunajam tunelim izskatīties veselam, vienlaikus klusi noņemot autorizācijas robežu, ko īstenoja vecais pakalpojums, un neviens to nepamana līdz auditam. Salīdziniet atļaujas un aizlieguma rezultātus blakus, no tā paša klienta, tajā pašā sesijā. Turiet veco pakalpojumu darbībā, līdz abas kolonnas atbilst projektam.

Pirms pārvietojat administratora piekļuvi, apstipriniet, ka jums ir autorizēts atkopšanas ceļš, kas nav atkarīgs no tuneļa, kuru maināt.

4. solis: izņemiet veco identitāti

Pareiza vecās identitātes izņemšana nozīmē atsaukt novecojušos lietotājus un ierīču akreditācijas datus caur pakalpojumu, kas tos pārvalda, un pēc tam noņemt vecos profilus un klausītājus, kad vairs nepaliek atkarību. Vietējā faila dzēšana neatsauc kopiju citur, un vecs klausītājs, kas joprojām pieņem veco kopīgo noslēpumu, ir nevērota durvju aile.

Šajā punktā ir vērts palēnināties. Izņemts klienta profils portatīvajā datorā nav atsaukts akreditācijas datums; akreditācijas dati dzīvo serverī un paliek derīgi, līdz serveris pārstāj tos pieņemt. Meklējiet citas vecās konfigurācijas kopijas — testa ierīces, aizmirstu tālruni, kāda saglabātu instalētāju — un uzskatiet klausītāja izslēgšanu par brīdi, kad vecais pakalpojums patiešām beidzas. Līdz tam migrācijai ir divas priekšējās durvis.

Pieņemšanas ieraksts ir pirmā soļa uzskaite ar pievienotu kolonnu: ko jaunais projekts dara katrai rindai un kā jūs to pārbaudījāt. Tas pārvērš protokola jauninājumu pakalpojuma prasībā ar pierādījumiem.

Turiet rezultātu saistītu ar to, kas pakalpojumam nepieciešams, nevis ar protokola nosaukumu, jo moderns protokols ar iekopētiem vecajiem pieņēmumiem ir tas pats risks ar labāku ietvaru. RFC 3193 apraksta, kā L2TP tiek pārnests pāri IPsec, kas ir noderīgs atgādinājums, ka abi slāņi vienmēr bija atsevišķi lēmumi. Ja uzskaitē ir rinda, ko nevarat izskaidrot, apstājieties un noskaidrojiet, kas no tās ir atkarīgs. Migrācija ir pabeigta, kad saraksts ir garlaicīgs.