Ilipat ang VPN server sa bagong pampublikong IP: ano ang unang susuriin

Ang muling pagtatalaga ng address ay tumatagal ng isang minuto. Ang susunod na linggo ang lugar kung saan nasisira ang paglipat, at bihirang doon kung saan iminumungkahi ng console ng provider. Ang bagong pampublikong IP ay tinutukoy sa apat na lugar: ang socket na pinakikinggan ng daemon, ang anchor ng tiwala na vine-verify ng mga client, bawat tuntuning nagbabanggit ng lumang address, at ang DNS record na nag-uugnay sa kanila. Ang dalawang paglipat ay magkamukha mula sa control panel ngunit ibang-iba ang pag-uugali: muling italaga ang address sa makina na pinapatakbo mo, o magtayo ng pangalawang endpoint at ilipat doon ang mga client. Inuuna ng mga pagsusuri sa ibaba ang murang mga pagkabigo, at sinasabi ng bawat seksyon kung aling paglipat ang sakop nito.

Ang pagpapalit sa lugar at paralel na paglipat ay magkaibang gawain

Pinapanatili ng pagpapalit sa lugar ang host, mga susi, routing table at listahan ng user; address lang ang nagbabago. Iyon ang ginagawa ng muling pagtatalaga ng lumulutang na IP, at sa ilang provider hindi ito napapansin ng bisita, dahil nagaganap ang pagsasalin sa harap ng instance. Ang muling pagbuo o muling pagtatalaga ng provider ay mas mabigat: nakikita ng bisita ang pagbabago, at lahat ng nag-cache ng lumang halaga ay natututo nito sa parehong sandali.

Ang paralel na endpoint ay pangalawang host na gumagawa ng parehong trabaho. Itayo ito, subukan gamit ang isang profile, at hayaang sumagot ang luma hanggang mapatunayan ng bago ang sarili sa totoong landas. Ang halaga ay estado. Kung walang pinagsasaluhang peer entry, pagpapawalang-bisa at pag-log, mayroon kang dalawang network na nagkataong nagbabahagi ng isang pangalan.

Hanapin ang bawat lugar kung saan nakasulat ang lumang address

Magsimula sa text sweep, dahil ang mga config file ang madaling kalahati. Hanapin sa config ng daemon, mga tipak ng firewall, mga target ng monitoring at anumang nabuong client bundle sa disk. Isama ang IPv6 address kung naglalathala ka ng isa; ang paglipat na sumusunod lamang sa A record ay iniiwan ang mga dual-stack client sa lumang landas.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Pagkatapos ay suriin ang kernel, dahil ang tumatakbong sistema ay may hawak ng address sa mga lugar na walang file na nagbabanggit. Ang static na source NAT rule, ipset entry, bind address at conntrack entry ay nabubuhay nang mas matagal kaysa sa pagbabago ng config na nag-alis sa kanila, at ang ilan ay nakakalampas pa sa reboot dahil bumalik sila mula sa naka-save na ruleset. Isang antas sa itaas, ang mga security group ng provider, target ng load balancer at pag-check ng monitoring ay wala talaga sa filesystem mo.

Isulat ang imbentaryo bago baguhin ang anuman; nagsisilbi rin itong rollback script.

Ang mga client na may hostname ay gumagaling; ang mga client na may literal na IP ay tumatahimik

Kung naaabot ng mga client ang server sa pamamagitan ng hostname, ang paglipat ay pangunahing problema sa DNS, at ang TTL na itinakda mo kahapon ang magpapasya kung gaano ito kalala. Nag-cache ang mga resolver, nag-cache muli ang mga stub resolver, at maraming client ay hinahanap lang ang pangalan sa bagong koneksyon, kaya pinapanatili ng naitatag na tunnel ang panimulang address nito.

Kung ang endpoint ay literal na address, walang muling nire-resolve at walang nagtatala ng reklamo. Iniimbak ng WireGuard ang na-resolve na socket address: ang Endpoint = vpn.example.net:51820 ay nagiging IP sa sandaling tumakbo ang wg-quick up at nananatiling ganoong IP hanggang baguhin mo ito. Mas mapagbigay ang OpenVPN: nire-resolve nito ang hostname na remote sa oras ng koneksyon at, gamit ang resolv-retry infinite, sinusubukan muli ang DNS sa muling pagkonekta. Sa literal na IP, parehong patuloy na tumatawag sa makinang wala na.

Ang nakakalito sa mga tao ay ang salamin na larawan. Ang client na nakaturo na sa bagong address, habang sumasagot pa ang lumang listener, ay pumasa sa bawat pagsubok na ginagawa mo mula sa sarili mong mesa. Nailoko rin ako niyan: ang bagong endpoint ay bumangon sa telepono sa unang pagsubok, at ang client na may lumang profile ay lumitaw lamang nang patayin ang lumang listener nang mas huli.

Hindi lumilipat ang tiwala kasama ng address

Hinihiwalay ng WireGuard ang pagkakakilanlan sa maabot, kaya halos libre ang paglipat ng address. Nakikilala ang mga peer sa pampublikong susi, at ang endpoint ay doon lang kung saan pumupunta ang mga packet ngayon; ina-update ng host ang endpoint ng peer mula sa source address ng huling authenticated packet. Ang idle peer ay kailangan pa rin ng dahilan para kausapin ang bagong lugar, at natututuhan lang nito ang address kapag tumanda ang session at nabigo ang mga retry ng handshake sa isang lugar na nakikita. Sinasaklaw ng mabilis na simula ng WireGuard ang field na endpoint.

Ang mga server na nakabatay sa TLS ang kabaligtaran. Ang certificate ay nakatali sa isang pangalan, at inihahambing ng client na nagdi-dial ng address ang idinial nito sa mga alternatibong pangalan ng subject. Kumonekta sa pamamagitan ng IP sa certificate na may DNS SAN lamang at mabibigo ang verification: ang pangalang ginamit ng client ay wala sa certificate. Ang muling pag-issue na may IP SAN ay nag-aayos ng isang koneksyong iyon at pinapalala ang susunod na paglipat. Ang pagpapanatili ng hostname sa profile at pag-iwan ng verify-x509-name sa lugar nito ay nagpapanatili ng mahigpit na pag-check habang nagbabago ang address sa ilalim.

Pagkatapos ay suriin kung ano ang nakatali ng daemon; ang socket na nakapako sa lumang address ay tahimik na nabibigo. Ang OpenVPN server na sinimulan gamit ang local 203.0.113.10 ay tumatangging bumangon kapag nawala ang address na iyon, habang ang listener sa 0.0.0.0 ay libreng sumusunod sa pagbabago. Nahahati rin ang NAT sa parehong paraan: sinusundan ng MASQUERADE ang anumang address na mayroon ang makina ngayon, at ang static na SNAT --to-source 203.0.113.10 ay patuloy na nagsusulat muli patungo sa address na hindi mo na pag-aari, kaya naglalaho ang return traffic. Kung ang bagong address ay may ibang upstream gateway, suriin ang rp_filter: itinatapon ng reverse-path filtering ang return traffic na dumarating sa interface na hindi inaasahan ng kernel.

Pagkakasunod-sunod ng paglipat at ang ebidensiyang gumana ito

Ibaba ang TTL isang araw bago, itayo ang bagong listener, at patunayan ito gamit ang profile na ikaw lang ang mayroon. Ang pagsubok mula sa loob ng parehong network ay halos walang pinapatunayan, kaya gumamit ng telepono sa cellular at subukan ang isang bagay na dapat dalhin ng tunnel kaysa sa ping sa endpoint.

Bantayan ang dalawang address sa buong window. Ang wg show all latest-handshakes sa bagong host, o ang status file ng OpenVPN, ay nagsasabi kung ilang peer ang tunay na lumipat. Kapag ang bagong endpoint ay may mga peer na inaasahan mo at ang luma ay may naiwan lang, iretiro ang lumang listener, alisin ang lumang NAT rule at alisin ang address sa firewall ng provider. Ang pag-alis ng lumang listener ang hakbang na madalas laktawan, at ito ang nagsasara ng butas kung saan naaabot pa ng lumang profile ang lumang network.

Isulat ang rollback trigger bago magsimula: kung ang bagong endpoint ay walang handshake mula sa kahit isang tunay na client pagkatapos ng napagkasunduang window, ibalik ang lumang address at itigil ang pamimigay ng profile. Patakbuhin muli ang sweep pagkatapos at tiyakin na walang listener ang nakatali pa sa retiradong address. Dalawang bagay ang dadalhin sa susunod na paglipat: isang hostname sa profile ng client upang ang susunod na pagbabago ay pag-edit ng DNS, at ang imbentaryong itinago sa tabi ng mga talaan ng pag-recover ng server.