Bakit nagbabago ang mga sagot ng DNS64 kapag kumonekta ang VPN?

Ang mga sagot ng DNS64 ay naglalarawan ng kaayusan ng network, hindi ng katangian ng server. Sinisintesis ng resolver ang isang IPv6 address mula sa IPv4 address, at gumagana lamang ang resulta kung saan may nakaupong tagasalin sa dulo ng prefix na iyon. Magdala ng VPN sa landas at ang kaayusang iyon ay maaaring manatili, magbago o tumigil na maging totoo depende sa tatlong kondisyon.

Ang mga kondisyong iyon ay ang resolver na sumagot, ang rutang mayroon ang iyong device papunta sa sinintesis na prefix, at kung may gumagawa ng pagsasalin sa rutang iyon. Ang bawat isa ay mapapansin, at iyon ang dahilan kung bakit nagiging masuri ang pagkabigo.

Saan talaga itinuturo ng sinintesis na AAAA record

Sinasagot ng DNS64 resolver ang isang AAAA query para sa isang pangalang may IPv4 lamang sa pamamagitan ng paglalagay ng IPv4 address sa loob ng isang prefix na naka-configure itong gamitin, at ang kilalang prefix para sa gawaing iyon ay 64:ff9b::/96 gaya ng inilalarawan sa RFC 6147. Ang record ay mukhang anumang iba pang AAAA record sa aplikasyon, at iyon ang punto: ang isang client na may IPv6 lamang ay maaaring sumubok ng koneksyon nang hindi alam na ang patutunguhan ay kailanman walang IPv6. Ang koneksyong iyon ay nakasalalay sa isang NAT64 function na nagsasalin sa pagitan ng dalawang pamilya saanman sa landas. Kung wala ang tagasaling iyon, ang sinintesis na address ay isang patutunguhang mukhang kapani-paniwala ngunit hindi umaabot kahit saan.

Kaya ang record ay nagko-code ng dalawang bagay nang sabay: ang orihinal na IPv4 address at ang palagay na maaabot ang tagasalin. Ang una lamang ang nakikita sa sagot mismo.

Tatlong kondisyon ang nagpapasya kung gumagana pa ito

Ang unang kondisyon ay kung aling resolver ang gumawa ng record, dahil ang isang walang naka-configure na DNS64 ay walang ibinabalik para sa pangalang iyon at nabigo ang aplikasyon sa ibang paraan. Ang ikalawa ay kung may ruta ang iyong device papunta sa sinintesis na prefix, dahil ang sagot ay maaaring wasto habang kulang ang daan patungo roon. Ang ikatlo ay kung ang tagasaling nagmamay-ari ng prefix na iyon ay nasa rutang gagamitin mo, dahil ang isang tunnel na nagdadala ng 64:ff9b::/96 sa ibang lugar ay umaabot sa ibang function o wala man lang. Ang tatlo ay maaaring totoo bago ang tunnel at mabigo pagkatapos nito, at iyon ang dahilan kung bakit ang sintomas ay mukhang biglang pagbabalik sa dati.

Suriin ang mga ito sa ganoong pagkakasunod-sunod. Ang nawawalang sagot at nawawalang ruta ay magkamukha sa browser at ganap na magkaiba sa log ng resolver.

Kapag nagbago ang resolver, nagbago ang sagot

Ang kliyente ng VPN ay kadalasang nagtutulak ng sarili nitong resolver o kinukuha ang buong landas ng query, at ang resolver na iyon ay maaaring walang sinisintesis. Ang mga query para sa mga pangalang may IPv4 lamang ay hindi nagbabalik ng AAAA record, na ang kliyenteng may IPv6 lamang ay nararanasan bilang pangalang hindi niya marating. Nangyayari rin ang kabaligtaran: ang resolver na tunay na nagsisintesis ay maaaring magbigay sa iyo ng prefix na hindi dinadala ng iyong tunel na landas.

Pinapahirap ng caching na makita ito. Ang sinintesis na record na nakuha sa network ng opisina ay maaaring mabuhay nang mas matagal kaysa sa kontekstong gumawa nito, kaya patuloy na kumokonekta ang kliyente sa isang address na hindi na maaabot ang tagasalin. Tingnan ang resolver na sumasagot ngayon at hindi ang sumagot noong na-save ang entry. Ang paglilinis ng cache nang hindi itinatala ang luma at bagong sagot ay sumisira sa ebidensyang kailangan mo.

Subukan ang paghahanap at ang landas nang hiwalay

Itanong ang pangalan nang direkta bago isangkot ang aplikasyon, at itala kung aling server ang sumagot. Ipinapakita ng mga utos sa ibaba ang AAAA record, ang resolver na ginagamit, at kung may rutang patungo sa sinintesis na prefix. Patakbuhin ang mga ito habang nakababa ang tunnel at muli habang nakataas ito.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Basahin ang mga resulta bilang isang kadena. Ang nawawalang AAAA record ay nangangahulugang hindi nagsisintesis ang resolver sa harap mo, kaya ang landas na may IPv6 lamang ay hindi gagana para sa pangalang iyon, anuman ang gawin ng kliyente. May record ngunit walang ruta ay nangangahulugang hindi dinadala ng kasalukuyang landas ang prefix, at iyon ay pasya sa pagruruta at hindi kasalanan ng resolver. May ruta habang nabibigo pa rin ang kahilingan ay tumuturo sa tagasalin mismo, at iyon ay pag-aari ng ibang may-ari.

Itala ang resolver, ang konteksto ng network at ang pamilya ng address sa tabi ng bawat resulta. Ang talang iyon ang nagbibigay-daan sa susunod na paghahambing na ihiwalay ang pagbabago ng resolver sa pagbabago ng pagruruta.