Paglipat ng VPN provider: planuhin ang hostname, hindi lang ang IP
Hindi inililipat ng bagong DNS record ang mga umiiral na session. Planuhin kung sino ang kumokontrol sa pangalan, kailan ito nireresolba ng bawat kliyente, at paano mo ipaparesante ang lumang endpoint.
Tama ang DNS record mo, malusog ang kapalit, at may mga kliyenteng gumugugol pa rin ng oras sa pag-dial sa lumang address. Ilan ang agad na nabigo sa isang pangalang nireresolba at hindi kailanman sumasagot. Ang dalawang resulta ay nagmumula sa isang puwang: binabago ng hostname ang hinahanap ng kliyente, hindi kung kailan ito hinahanap, at hindi kung ano ang pinagkakatiwalaan nito kapag dumating ang sagot.
Ang sintomas: tamang record, lumang tunnel
Ang profile na nag-iimbak ng pangalan ay hindi kliyenteng patuloy na nagreresolba nito. Karamihan ay nagreresolba isang beses, kapag inilapat ang configuration o kapag umangat ang tunnel, at pagkatapos ay ginagamit muli ang address na iyon hanggang matapos ang session. Ang mahabang TTL sa ibabaw nito ang dahilan kung bakit kailangang planuhin ang paglipat sa paligid ng mga muling pagkonekta at hindi sa paligid ng pag-edit ng DNS.
Wala sa dalawang pag-uugali ang depekto, at iyon ang dahilan kung bakit nakakalito ang sintomas. Gumagana ang kliyente batay sa sagot na nakuha nito kanina, at walang anuman sa panig ng server ang nagpapakita kung aling sagot iyon. Planuhin ang muling pagkonekta sa window ng maintenance at sabihin sa mga user kung ano ang makikita nila, o gamitin ang window sa pagsagot ng mga ticket. Ang pila ng magkakatulad na ulat ang karaniwang resulta.
Sino ang kumokontrol sa pangalan, at ano ang bini-verify ng kliyente
Ang kontrol sa zone ang nagtatakda kung gaano kabilis makakagalaw ang isang migration. Itago ang record sa isang registrar na maaari mong pasukin, at isulat kung sino pa ang makakapagbago nito.
Hindi sinusundan ng tiwala ang pangalan. Ang kliyenteng nakabatay sa TLS ay maaaring mag-verify ng pagkakakilanlan ng certificate o naka-pin na pangalan, habang ang WireGuard ay nagpapatotoo sa public key ng peer at ganap na binabalewala ang hostname. Ang pagkakaibang iyon ang nagtatakda kung sapat ang pag-edit ng DNS o kailangan ng bawat profile ng bagong fingerprint. Ang pagbabago ng record ay hindi dapat kailanman magbigay ng awtoridad sa endpoint na walang sinumang inaprubahan.
Itago ang administratibong access at access sa pag-recover nang malayo sa pampublikong pangalan ng kliyente. Ang pagkawala ng hosting account ay hindi dapat gawing kawalan din ng record na nagre-redirect sa mga kliyente. Itago ang landas ng pag-recover sa lugar na hindi nakadepende sa provider na iiwan mo.
Kailan muling binabasa ng bawat kliyente ang pangalan
Ang oras ng resolution ay katangian ng bawat kliyente, kaya suriin ang implementasyong talagang ipinapadala mo bago mangako ng window ng paglipat. Nireresolba ng wg-quick ang endpoint kapag umangat ang interface at pinapanatili ang address na iyon hanggang ma-restart ang tunnel. Ang kliyenteng OpenVPN ay naghahanap ng pangalan kapag kumokonekta, at kung titingin muli ito sa muling pagkonekta ay nakadepende sa mga opsyon nito.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
Ang mga mobile client ang karaniwang sorpresa, dahil maaari nilang itago ang naresolbang address sa pagtulog o pagbabago ng network. I-publish ang A at AAAA record lamang kung sumasagot ang kapalit sa parehong pamilya. Ang address na sumasagot sa isang pamilya ay walang pinapatunayan tungkol sa isa, at ang patay na AAAA record ay nagdadagdag ng timeout sa bawat pagtatangka. Idokumento ang pag-uugali ng resolution para sa bawat kliyenteng sinusuportahan mo, pagkatapos ay subukan sa mga device na talagang ginagamit ng mga tao.
Ang muling pagkonekta ay aksyon ng user sa karamihan ng kliyente, at hindi ito maipilit ng server. Ilagay ang hakbang na iyon sa maintenance note, kasama ang isang linyang tungkol sa makikita ng user kapag nangyari ito.
Lumipat batay sa ebidensya, pagkatapos ay iparesante ang lumang endpoint
Bago ang paglilipat, patunayan ang bawat layer sa kapalit: sumasagot ang listener, pinapayagan ng firewall ang port, bumabalik nang tama ang mga ruta, nireresolba ang pangalan sa bagong address, at tinatanggap ang kilalang pagkakakilanlan. Ang listener na tumatanggap ng koneksyon ay hindi kapareho ng isang nagtatapos ng handshake, kaya subukan ang handshake at hindi ang port. Itago ang kasalukuyang revocation list sa tabi ng configuration, dahil ang naibalik na backup ay muling gumagawa ng peer list na gaya ng dati at muling magbubukas ng access na isinara mo na. Itala kung anong pagkakakilanlan ang ginamit mo sa pagsubok, dahil ang «gumagana ito» ay hindi ebidensyang maaaring ulitin ng sinuman.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesSa panahon ng paglipat, pagmasdan ang mga pagtatangka ng koneksyon sa dalawang endpoint para sa parehong pagkakakilanlan. Ang kliyenteng nag-aautentika pa rin laban sa lumang address ay isang profile o naka-cache na sagot na hindi kailanman gumalaw. Ipareasante ang lumang endpoint ayon sa planong may petsa, dahil ang dalawang serbisyo na tumatanggap ng isang pagkakakilanlan ay nag-iiwan ng dalawang bukas na pinto.
Ang pagsubok ng paglipat ay isang session ng application sa pamamagitan ng bagong endpoint, hindi ping. Kapag gumana ang session na iyon at walang naitalang awtorisadong pagtatangka ang lumang endpoint sa isang buong ikot ng muling pagkonekta, tapos na ang paglipat.