Paglipat mula sa VPN na nakabatay sa PPP nang hindi kinokopya ang mga palagay nito

Ang paglipat ng VPN ay natapos kapag ang mga user, destinasyon, resolusyon ng pangalan at pag-uugali kapag may pagkabigo ay tama pa rin, hindi kapag ang bagong client ay nagpapakita ng berdeng icon. Ang mga lumang deployment na nakabatay sa PPP ay nagdadala ng mga palagay na hindi kailanman naisulat: isang shared secret na nagsilbing tanging pagsusuri ng pagkakakilanlan, isang fixed address pool na nasa allowlist ng firewall, at isang DNS suffix na itinutulak ng server. Ang pagpapalit ng protocol nang hindi ini-inventaryo ang mga palagay na iyon ay lumilikha ng tunnel na nagsasagawa ng handshake at hangganan na wala naman. Ang pagkakasunod-sunod sa ibaba ang ginagamit ko, at ang huling hakbang ang madalas laktawan ng mga team.

Hakbang 1: i-inventaryo kung ano ang ibinibigay ng lumang koneksyon

Ang inventory ay isinusulat, hindi sinasaulo. Itala ang mga sinusuportahang client, mga role ng authentication, mga address pool, mga protektadong network, mga kinakailangan sa DNS at mga permiso sa serbisyo na kailangan ng bawat pangkat ng user.

Para sa L2TP/IPsec, hiwalayin nang malinaw ang dalawang layer. Ang pagkakakilanlan ng IPsec peer ang nagpapatotoo sa mga makina; ang PPP ang nagpapatotoo sa user, karaniwang gamit ang CHAP o MSCHAPv2.

Sa paghihiwalay na iyon itinatago ng lumang deployment ang kanilang mga palagay. Ang pre-shared key na pinagsasaluhan ng bawat client ay nagpapatotoo sa isang pangkat at hindi sa isang device, at madalas ito ang tanging bagay na na-rotate kailanman. Kung ang PPP account ang tunay na kontrol sa bawat user, sabihin ito, dahil kailangang muling gawin ng kapalit ang kontrol na iyon gamit ang isang bagay na hindi shared string. Itala rin ang mga fixed source address at exception sa lokal na network, dahil iyon ang mga dependency na walang nagdodokumento hanggang sa masira.

Hakbang 2: sadyang idisenyo ang kapalit

Ang pagpili ng kapalit ay isang pagma-map ng pangangailangan sa pangangailangan: isang protocol at isang maintained client na sinusuportahan ng organisasyon, at bawat pangangailangan sa pagkakakilanlan at pag-access ay dumarating sa isang tunay na mekanismo. Ang shared secret ay hindi awtomatikong katumbas ng key o certificate sa bawat device, at ang PPP account sa bawat user ay hindi katumbas ng device certificate.

Isaayos ang mga saklaw ng address bago ang anupaman, dahil ang kapalit na pool na nagsasapawan sa LAN ng bahay o opisina ay lumilikha ng pagkabigong walang kinalaman sa lakas ng cipher. Suriin ang pool laban sa parehong listahan na ginawa mo para sa lumang serbisyo, kasama ang ipinapalagay ng bagong client bilang default. Kumpirmahin ang return routing para sa mga protektadong network at kumpirmahin na kayang itulak o idokumento ng bagong client ang DNS suffix na itinulak ng luma. Ang dalawang bagay na iyon ang lumilikha ng mas maraming migration ticket kaysa sa pagbabago ng protocol mismo.

Hakbang 3: ipatupad nang paunti-unti at i-verify ang parehong pagpayag at pagtanggi

Ipatupad gamit ang isang representative na user at isang representative na application. Isama sa pagsubok ang pribadong DNS resolution, dahil ang tunnel na nakakaabot sa address ngunit hindi maresolba ang panloob na pangalan ay kalahati lamang ang naipalipat. Isama rin ang inaasahang hindi available na estado: ano ang dapat mangyari kapag bumagsak ang tunnel, at kung ipinapatupad ito ng client.

Pagkatapos ay subukan ang destinasyong dapat manatiling tinanggihan. Ang malawak na pansamantalang tuntunin sa pagpayag ay maaaring magpakita ng bagong tunnel na mukhang malusog habang tahimik na inaalis ang hangganan ng awtorisasyon na ipinatupad ng lumang serbisyo, at walang nakakapansin hanggang sa isang audit. Ihambing ang mga resulta ng pagpayag at pagtanggi nang magkatabi, mula sa parehong client, sa parehong session. Panatilihing tumatakbo ang lumang serbisyo hanggang sa tumugma ang parehong hanay sa disenyo.

Bago ilipat ang access ng administrator, kumpirmahin na mayroon kang awtorisadong landas ng pagbawi na hindi nakadepende sa tunnel na binabago mo.

Hakbang 4: iretiro ang lumang pagkakakilanlan

Ang tamang pagreretiro ng lumang pagkakakilanlan ay nangangahulugan ng pagbawi ng mga lumang user at kredensyal ng device sa pamamagitan ng serbisyong nagmamay-ari sa kanila, pagkatapos ay alisin ang mga lumang profile at listener kapag wala nang natitirang dependency. Ang pagtanggal ng lokal na file ay hindi nagbabawi ng kopya sa ibang lugar, at ang lumang listener na tumatanggap pa rin ng lumang shared secret ay pintong walang pagmamatyag.

Ang puntong iyon ay karapat-dapat na dahan-dahanan. Ang na-retiro na profile ng client sa laptop ay hindi binawiang kredensyal; ang kredensyal ay nabubuhay sa server at nananatiling valid hanggang sa itigil ng server ang pagtanggap dito. Maghanap ng iba pang kopya ng lumang configuration — mga test device, nakalimutang telepono, installer na itinago ng isang tao — at ituring ang pagpatay ng listener bilang sandali na tunay na nagtatapos ang lumang serbisyo. Hanggang doon, may dalawang harapang pinto ang paglipat.

Ang talaan ng pagtanggap ay ang inventory mula sa unang hakbang na may idinagdag na hanay: ano ang ginagawa ng bagong disenyo para sa bawat hilera, at paano mo ito na-verify. Ginagawa nitong kinakailangan sa serbisyo na may ebidensya ang pag-upgrade ng protocol.

Panatilihing nakatali ang resulta sa kailangan ng serbisyo at hindi sa pangalan ng protocol, dahil ang modernong protocol na may nakopyang lumang palagay ay parehong panganib na may mas magandang balangkas. Inilalarawan ng RFC 3193 kung paano dinadala ang L2TP sa ibabaw ng IPsec, na isang kapaki-pakinabang na paalala na ang dalawang layer ay palaging magkahiwalay na desisyon. Kung may hilera sa inventory na hindi mo maipaliwanag, huminto at alamin kung ano ang nakadepende rito. Tapos na ang paglipat kapag ang listahan ay mayamot na.