Kodėl DNS64 atsakymai pasikeičia vos prisijungus VPN?

DNS64 atsakymai aprašo tinklo išdėstymą, o ne serverio savybę. Resolveris sintetizuoja IPv6 adresą iš IPv4 adreso, ir rezultatas veikia tik ten, kur to prefikso gale yra vertėjas. Įveskite VPN į kelią, ir tas išdėstymas gali išsilaikyti, pasikeisti arba nustoti būti teisingas priklausomai nuo trijų sąlygų.

Tos sąlygos yra atsakęs resolveris, maršrutas, kurį jūsų įrenginys turi iki sintetizuoto prefikso, ir tai, ar kas nors tame maršrute atlieka vertimą. Kiekvieną galima stebėti, ir būtent tai leidžia diagnozuoti gedimą.

Į ką iš tikrųjų nurodo sintetizuotas AAAA įrašas

DNS64 resolveris atsako į AAAA užklausą dėl vardo, turinčio tik IPv4, įterpdamas IPv4 adresą į prefiksą, kurį naudoti jis sukonfigūruotas, o žinomas šio darbo prefiksas yra 64:ff9b::/96, kaip aprašyta RFC 6147. Programai įrašas atrodo kaip bet kuris kitas AAAA įrašas, ir būtent tai yra esmė: klientas, turintis tik IPv6, gali bandyti ryšį nežinodamas, kad paskirties vieta niekada neturėjo IPv6. Tada tas ryšys priklauso nuo NAT64 funkcijos, kuri kažkur kelyje verčia tarp dviejų šeimų. Be to vertėjo sintetizuotas adresas yra patikimai atrodanti paskirties vieta, kuri niekur neveda.

Taigi įrašas užkoduoja du dalykus vienu metu: pradinį IPv4 adresą ir prielaidą, kad vertėjas pasiekiamas. Tik pirmasis matomas pačiame atsakyme.

Trys sąlygos nusprendžia, ar tai dar veikia

Pirmoji sąlyga yra tai, kuris resolveris sukūrė įrašą, nes tas be sukonfigūruoto DNS64 tam vardui nieko negrąžina ir programa nepavyksta kitaip. Antroji yra tai, ar jūsų įrenginys turi maršrutą iki sintetizuoto prefikso, nes atsakymas gali būti galiojantis, kai kelio į jį nėra. Trečioji yra tai, ar vertėjas, kuriam priklauso tas prefiksas, yra tame kelyje, kurį naudotumėte, nes tunelis, nešantis 64:ff9b::/96 kitur, pasiekia kitą funkciją arba nieko. Visos trys gali galioti prieš tunelį ir nepavyksti po jo, ir todėl simptomas atrodo kaip staigus regresas.

Tikrinkite jas ta tvarka. Trūkstamas atsakymas ir trūkstamas maršrutas naršyklėje atrodo vienodai, o resolverio žurnale visiškai skirtingai.

Kai pasikeičia resolveris, pasikeičia atsakymas

VPN klientas dažnai įstumia savo resolverį arba perima visą užklausos kelią, ir tas resolveris gali nieko nesintetizuoti. Užklausos dėl vardų, turinčių tik IPv4, tada negrąžina jokio AAAA įrašo, ką klientas, turintis tik IPv6, išgyvena kaip vardą, kurio negali pasiekti. Pasitaiko ir priešingai: resolveris, kuris tikrai sintetizuoja, gali duoti prefiksą, kurio jūsų tuneliuotas kelias neneša.

Talpykla daro tai sunkiau pastebimą. Biure gautas sintetizuotas įrašas gali pergyventi jį sukūrusį kontekstą, todėl klientas ir toliau jungiasi prie adreso, kurio vertėjas nebepasiekiamas. Žiūrėkite į dabar atsakantį resolverį, o ne į tą, kuris atsakė, kai įrašas buvo išsaugotas. Talpyklos išvalymas neužfiksavus seno ir naujo atsakymo sunaikina įrodymą, kurio jums reikia.

Tikrinkite užklausą ir kelią atskirai

Užklauskite vardo tiesiogiai prieš įtraukdami programą ir pasižymėkite, kuris serveris atsakė. Toliau pateiktos komandos rodo AAAA įrašą, naudojamą resolverį ir tai, ar yra maršrutas iki sintetizuoto prefikso. Vykdykite jas su išjungtu tuneliu, o paskui vėl su įjungtu.

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/

Skaitykite rezultatus kaip grandinę. Trūkstamas AAAA įrašas reiškia, kad priešais esantis resolveris nesintetizuoja, tad kelias, turintis tik IPv6, tam vardui neveiks, kad ir ką klientas darytų. Įrašas yra, bet maršruto nėra — prefikso neneša dabartinis kelias, ir tai yra maršrutizavimo sprendimas, o ne resolverio gedimas. Maršrutas yra, bet užklausa vis tiek nepavyksta — tai nurodo į patį vertėją, ir tai priklauso dar kitam savininkui.

Užrašykite resolverį, tinklo kontekstą ir adresų šeimą prie kiekvieno rezultato. Būtent ta pastaba leidžia kitam palyginimui atskirti resolverio pasikeitimą nuo maršrutizavimo pasikeitimo.