Nasira ang patakaran ng domain ng VPN kapag binago ng CDN ang mga address nito

Kinokopya mo ang address mula sa isang paghahanap papunta sa iyong patakaran sa pagruruta, gumagana ang site, at pagkaraan ng isang linggo ay hindi na. Walang nagbago sa patakaran. Lumipat ang serbisyo sa ibang address sa gilid, nagresolba ang kliyente ng ibang pangalan ng host, o lumipat ang sesyon sa IPv6. Ang desisyon sa harap mo ay kung ang patakarang nakabatay sa pangalan o tahasang saklaw ang tamang kasangkapan para sa serbisyong ito, at tatlong kundisyon ang nagtatakda nito. Hinihiwalay ng sumusunod ang pangalan sa address, dahil isa lamang sa dalawa ang matatag.

Bakit ang isang paghahanap ay hindi imbentaryo

Sumasagot ang isang network ng paghahatid ng nilalaman gamit ang address na pinili para sa resolver, rehiyon at sandali. Magtanong nang dalawang beses mula sa magkaibang network at maaari kang makakuha ng magkaibang sagot. Magtanong nang isang beses at ituring ang sagot na listahan ng address ng serbisyo, at ang patakarang isusulat mo ay snapshot, hindi patakaran. Iyon ang buong problema sa pagturing sa sagot ng DNS bilang konfigurasyon.

May pangalawang puwang. Ang isang nakikitang pangalan ng host ay bihirang sumasaklaw sa buong aplikasyon, dahil ang pag-log in, media at trapik ng API ay kadalasang gumagamit ng magkakahiwalay na pangalan. Ang patakarang binuo mula sa pangalan ng host sa address bar ay maaaring sumaklaw sa pahina at mawala ang video, na binabasa bilang bahagyang pagkabigo at hindi bilang error sa pagruruta.

Ang pangatlong puwang ay ang pamilya ng address. Ang patakarang para lamang sa v4 ay walang sinasabi tungkol sa rekord na AAAA na maaaring mas gusto ng kliyente.

Tatlong kundisyon na nagtatakda ng patakaran ng domain o mga saklaw

Una, naglalathala ba ang serbisyo ng matatag na hanay ng mga prefix na maaari mong pagmamay-ari at idokumento? Kung oo, ang tahasang saklaw ay tapat at mura. Kung hindi, ang patakaran ng domain ang tanging mekanismong makakasunod sa serbisyo.

Ikalawa, nagre-refresh ba ang mekanismo ng domain ng iyong kliyente? Ang patakarang nagresolba nang isang beses sa pagkonekta at hindi na muling nagresolba ay snapshot na may mas magandang branding. Ikatlo, sinasaklaw ba ng mekanismo ang mga subdomain at parehong pamilya ng address, o ang mga pangalang itina-type mo lamang?

Sagutin ang tatlong iyon at ang pagpili ay karaniwang malinaw. Ang hula ay gumagawa ng patakarang gumagana sa pagsubok at nabibigo sa produksyon.

Subukan ang sesyon, hindi ang pahina

I-load ang pahina, pagkatapos gawin ang mahalagang operasyon: mag-log in, simulan ang pag-playback, mag-upload ng file. Ang bawat isa ay maaaring makarating sa ibang host, at ang nabibigo ay ang napalampas ng iyong patakaran.

Ilista kung ano ang aktwal na kinokontak ng sesyon sa halip na kung ano ang ipinapakita ng pahina:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Panatilihing nakikita ang resolver sa panahon ng paghahambing, dahil ang patakarang gumagana mula sa isang resolver at nabibigo mula sa iba ay nagsasabi sa iyo tungkol sa sagot ng CDN, hindi tungkol sa tunnel. Ang maikling TTL ay nangangahulugan ding may petsa ng pag-expire ang sagot na naitala mo.

Ano ang aktwal na sinasaklaw ng bawat mekanismo

Ang dalawang mekanismo ay mukhang mapagpapalit sa pahina ng mga setting at kumikilos nang iba sa ilalim.

Ang ruta ng address sa kernel ay tumutugma sa mga prefix. Wala itong ideya kung ano ang pangalan ng host, kaya hindi nito masusundan ang serbisyong nagbabago ng address. Ang patakaran ng domain ay nagresolba ng mga pangalan at nagruruta ng resulta; sinusundan nito ang serbisyo ngunit nakadepende sa resolver, sa pag-uugali ng pag-refresh at sa paghawak ng kliyente sa mga subdomain, kaya ang patakarang sumusunod sa mga pangalan ay dapat subukan sa resolver na aktwal na ginagamit ng kliyente.

Wala sa dalawa ang superset ng isa, kaya ang paghahalo sa kanila nang walang tala ay lumilikha ng kalituhan sa hinaharap.

Suriin muli pagkatapos magbago ang serbisyo

Pagkatapos ng update ng kliyente o pagbabago ng serbisyo, patakbuhin muli ang parehong pagsubok ng sesyon. Ang listahan ng address na gumana noon ay ebidensya tungkol sa panahong iyon, hindi permanenteng imbentaryo ng imprastruktura ng serbisyo.

Isulat kung aling mekanismo ang sumasaklaw sa aling pangalan ng host, at ang petsa ng huling pagpapatunay.

Ang talang iyon ang pagkakaiba ng patakarang maipagtatanggol mo at patakarang walang sinumang nangangahas na hawakan. Kung naglalathala ang serbisyo ng sarili nitong listahan ng prefix, gamitin iyon at banggitin ang petsa. Kung hindi, sabihin iyon, at itago ang patakaran ng domain kasama ang pag-uugali nitong pag-refresh na nakasulat sa tabi.