Palitan ang ISP nang hindi muling binibilang ang mga address ng VPN ng site

Nagpapalit ng internet provider ang isang sangay, at pinapanatili ng file server ang address nito. Normal ang resultang ito sa isang ruted na site VPN at nakakagulat sa sinumang nag-aakala na ang address ng dulo ng tunnel ay ang address ng application. Nabubuhay ang dalawa sa magkaibang layer ng disenyo, at isa lang ang gumalaw. Ang ituring silang isa ay ang paraan kung paano nagiging proyekto ng muling pagbilang ang paglipat ng provider.

Dalawang plano ng address na gumagalaw nang hiwalay

Inilalarawan ng panloob na plano ang mga pribadong address na ginagamit ng mga application: ang server ng sangay sa 10.55.8.20, ang prefix ng punong tanggapan na nagru-ruta doon, at ang daan pabalik. Inilalarawan ng panlabas na plano kung paano naaabot ng dalawang gateway ang isa't isa: mga address ng peer, mga port ng pakikinig at ang daan sa internet.

Ang pagbabago ng provider ay humahawak sa panlabas na plano. Hindi nito kailangan sa sarili nitong baguhin ang panloob na plano.

Ang paghihiwalay ng dalawang imbentaryo ay ang praktikal na dahilan upang magpatakbo ng overlay kahit na ang application ay nag-e-encrypt na ng sarili nitong trapiko. Binibigyan ka ng overlay ng matatag na panloob na topolohiya na nakakayanan ang mga panlabas na pagbabago. Pinapanatili ng application ang address nito, ang mga tuntunin ng firewall at ang mga tala ng DNS. Ang mga entry ng transportasyon lang ang nagbabago, at iyon ay mas maliit na pagsusuri.

Dinadala ng panlabas na tunnel ang panloob na usapan

Sa tunnel na gateway-sa-gateway, ang panlabas na header ng IP ay nag-a-address sa dalawang gateway. Pinapangalanan pa rin ng panloob na header ang tunay na mga dulo ng application. Itinuturing ng paglalarawan ng gateway-sa-gateway sa RFC 7296 ito bilang ordinaryong routing na naghahatid ng trapiko sa pamamagitan ng mga dulo ng tunnel.

Kaya't mapanatili ng server ng sangay ang 10.55.8.20 habang nagbabago ang pampublikong address ng gateway. Wala talagang address ng provider sa panloob na packet.

Ang paghihiwalay ay katangian ng disenyo, hindi awtomatikong garantiya. Kung hindi maitatag ng kapalit na link ang sinusuportahang tunnel, o hindi maibalik ang mga panloob na ruta, mawawala ang daan ng application kahit na hindi nagbago ang address nito.

May checklist pa rin ang paglipat ng provider

May limang entry ang panlabas na checklist: ang address ng peer o ang pinapanatiling pangalan, ang listener at anumang pagsasala sa itaas, ang pagsasalin sa daan, ang inaasahang pagkakakilanlan ng peer at ang pinapayagang setting ng kabilang gateway. Bawat isa ay maaaring mabigo nang mag-isa. Magpanatili ng hiwalay na daan ng pagbawi habang binabago ang link na nagdadala ng administrasyon. Ang pagputol ng malayuang pag-access sa gitna ng paglipat ng link ay pagkawalang dulot mo mismo.

Pagkatapos, suriin ang prefix ng sangay, ang ruta sa dalawang direksyon, ang patakaran sa proteksyon at isang tunay na daloy ng application. Ang bagong authenticated na tunnel ay hindi nag-aayos ng rutang tumuturo sa lumang pribadong subnet.

Ang pagtawid ng address sa ibang konektadong site ay hiwalay na suliranin sa pagpaplano. Hindi ito nililikha ng pagbabago ng provider, ngunit ang paglipat ang karaniwang sandali kung kailan ito lumilitaw.

Ang hindi nananatili: pampublikong pinagmulan at mga sesyon

Ang matatag na pribadong address ng server ay hindi matatag na pampublikong pinagmulan. Kung ang pag-browse ay lumalabas nang direkta sa bagong provider, nakikita ng mga website ang bagong address na nakaharap sa provider.

Upang mapanatiling matatag ang address na iyon, kailangan ng sinadyang disenyo ng labasan, na may sariling kakayahang magamit at patakaran. Hindi ito libreng kasama ng tunnel.

Kahit ang mga naitatag na sesyon ay hindi nakakayanan ang pagbabago ng daan. Ang tunnel ay maaaring maibalik sa loob ng ilang segundo at mapuputol pa rin ang pangmatagalang koneksyon na nakakabit sa lumang daan. Planuhin ang paglipat para sa isang bintana kung saan katanggap-tanggap ang muling pagkonekta. Huwag sabihing hindi makikita ang paglipat maliban kung nasubukan ang mga partikular na client at ang kanilang mga timeout.

I-verify ang paglipat sa apat na pagsusuri

Pagkatapos ng pagbabago, i-verify ang apat na bagay sa ayos: naitatag ang tunnel sa nilalayong peer, may panloob na ruta patungo sa prefix ng sangay, pinapayagan ng patakaran ang daloy ng application at tumutugon ang application. Bawat isa ay may sariling utos.

Sa isang gateway na Linux, sinasaklaw ng tatlong ito ang gitna ng listahang iyon:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Itago ang mga address ng transportasyon sa isang imbentaryo at ang mga address ng application sa isa pa. I-update lamang ang mga entry na talagang gumalaw. Ang muling pagbilang ng mga panloob na dependency dahil nagbago ang panlabas na address ng tunnel ay trabahong maiiwasan.