Kial DNS64-respondoj ŝanĝiĝas, tuj kiam la VPN konektiĝas?

DNS64-respondoj priskribas retan aranĝon, ne econ de la servilo. La solvilo sintezas IPv6-adreson el IPv4-adreso, kaj la rezulto funkcias nur tie, kie tradukilo sidas ĉe la fino de tiu prefikso. Enportu VPN-on en la vojon, kaj tiu aranĝo povas teniĝi, ŝanĝiĝi aŭ ĉesi esti vera laŭ tri kondiĉoj.

Tiuj kondiĉoj estas la solvilo, kiu respondis, la itinero, kiun via aparato havas al la sintezita prefikso, kaj ĉu io ajn sur tiu itinero plenumas la tradukon. Ĉiu estas observebla, kaj ĝuste tio igas la fiaskon diagnozebla.

Kion sintezita AAAA-registraĵo efektive montras

DNS64-solvilo respondas AAAA-demandon por nur-IPv4 nomo enteksante la IPv4-adreson ene de prefikso, kiun ĝi estas agordita uzi, kaj la konata prefikso por tiu tasko estas 64:ff9b::/96 kiel priskribite en RFC 6147. La registraĵo aspektas por la aplikaĵo kiel iu ajn alia AAAA-registraĵo, kaj tio estas la celo: nur-IPv6 kliento povas provi konekton sen scii, ke la celo neniam havis IPv6. Tiu konekto poste dependas de NAT64-funkcio, kiu ie sur la vojo tradukas inter la du familioj. Sen tiu tradukilo, la sintezita adreso estas kredinde aspekta celo, kiu kondukas nien.

La registraĵo do kodas du aferojn samtempe: la originan IPv4-adreson kaj la supozon, ke tradukilo estas atingebla. Nur la unua estas videbla en la respondo mem.

Tri kondiĉoj decidas, ĉu ĝi ankoraŭ funkcias

La unua kondiĉo estas, kiu solvilo produktis la registraĵon, ĉar tiu sen agordita DNS64 redonas nenion por tiu nomo kaj la aplikaĵo fiaskas alimaniere. La dua estas, ĉu via aparato havas itineron al la sintezita prefikso, ĉar respondo povas esti valida dum la vojo al ĝi mankas. La tria estas, ĉu la tradukilo posedanta tiun prefikson troviĝas sur la vojo, kiun vi uzus, ĉar tunelo portanta 64:ff9b::/96 aliloken atingas alian funkcion aŭ nenion. Ĉiuj tri povas validi antaŭ la tunelo kaj fiaski post ĝi, kaj tial la simptomo aspektas kiel subita regreso.

Kontrolu ilin en tiu ordo. Mankanta respondo kaj mankanta itinero aspektas idente en retumilo kaj tute alie en solvila protokolo.

Kiam la solvilo ŝanĝiĝas, la respondo ŝanĝiĝas

VPN-kliento ofte trudas sian propran solvilon aŭ tute transprenas la demando-vojon, kaj tiu solvilo eble sintezas nenion. Demandoj pri nur-IPv4 nomoj tiam redonas neniun AAAA-registraĵon, kion nur-IPv6 kliento spertas kiel nomon, kiun ĝi ne povas atingi. La malo ankaŭ okazas: solvilo, kiu vere sintezas, povas doni al vi prefikson, kiun via tunela vojo ne portas.

Kaŝmemoro igas tion pli malfacile videbla. Sintezita registraĵo akirita en la ofica reto povas postvivi la kuntekston, kiu produktis ĝin, do la kliento daŭre konektiĝas al adreso, kies tradukilo jam ne estas atingebla. Rigardu la solvilon respondantan nun, ne tiun, kiu respondis kiam la enskribo estis konservita. Malplenigi la kaŝmemoron sen registri la malnovan kaj novan respondojn detruas la pruvon, kiun vi bezonas.

Testu la serĉadon kaj la vojon aparte

Demandu la nomon rekte antaŭ ol engaĝi la aplikaĵon, kaj notu, kiu servilo respondis. La subaj komandoj montras la AAAA-registraĵon, la uzatan solvilon kaj ĉu ekzistas itinero al la sintezita prefikso. Rulu ilin kun la tunelo mallevita kaj poste denove kun ĝi levita.

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/

Legu la rezultojn kiel ĉeno. Mankanta AAAA-registraĵo signifas, ke la solvilo antaŭ vi ne sintezas, do nur-IPv6 vojo ne funkcios por tiu nomo, kion ajn la kliento faras. Registraĵo ĉeesta sen itinero signifas, ke la prefikson ne portas la nuna vojo, kaj tio estas enkursiga decido, ne solvila fuŝo. Itinero ĉeesta dum la peto ankoraŭ fiaskas montras al la tradukilo mem, kaj tio apartenas al ankoraŭ alia posedanto.

Registru la solvilon, la retan kuntekston kaj la adresan familion apud ĉiu rezulto. Ĝuste tiu noto ebligas al la sekva komparo apartigi solvilan ŝanĝon disde enkursigan ŝanĝon.