De ce se schimbă răspunsurile DNS64 de îndată ce se conectează VPN-ul?

Un răspuns DNS64 codează o presupunere de traducere. Verificați ce resolver a răspuns, dacă prefixul este rutat și dacă pe calea voastră stă un traducător.

Răspunsurile DNS64 descriu o aranjare de rețea, nu o proprietate a serverului. Resolverul sintetizează o adresă IPv6 dintr-o adresă IPv4, iar rezultatul funcționează doar acolo unde un traducător stă la capătul acelui prefix. Aduceți un VPN pe cale și acea aranjare poate rezista, se poate schimba sau poate înceta să fie adevărată în funcție de trei condiții.

Aceste condiții sunt resolverul care a răspuns, ruta pe care dispozitivul vostru o are spre prefixul sintetizat și dacă ceva de pe acea rută face traducerea. Fiecare este observabilă, și exact asta face defecțiunea diagnosticabilă.

Spre ce indică de fapt o înregistrare AAAA sintetizată

Un resolver DNS64 răspunde la o interogare AAAA pentru un nume care are doar IPv4 încorporând adresa IPv4 într-un prefix pe care este configurat să îl folosească, iar prefixul bine cunoscut pentru această sarcină este 64:ff9b::/96, așa cum este descris în RFC 6147. Înregistrarea arată pentru aplicație ca orice altă înregistrare AAAA, și acesta este rostul: un client care are doar IPv6 poate încerca o conexiune fără să știe că destinația nu a avut niciodată IPv6. Acea conexiune depinde apoi de o funcție NAT64 care traduce între cele două familii undeva pe cale. Fără acel traducător, adresa sintetizată este o destinație care arată plauzibil și care nu duce nicăieri.

Înregistrarea codează așadar două lucruri deodată: adresa IPv4 originală și presupunerea că un traducător este accesibil. Doar primul este vizibil în răspunsul propriu-zis.

Trei condiții decid dacă încă funcționează

Prima condiție este ce resolver a produs înregistrarea, fiindcă unul fără DNS64 configurat nu returnează nimic pentru acel nume și aplicația eșuează în alt mod. A doua este dacă dispozitivul vostru are o rută spre prefixul sintetizat, fiindcă un răspuns poate fi valid în timp ce lipsește drumul spre el. A treia este dacă traducătorul care deține acel prefix se află pe ruta pe care ați folosi-o, fiindcă un tunel care duce 64:ff9b::/96 în altă parte ajunge la altă funcție sau la nimic. Toate trei pot fi valabile înainte de tunel și pot eșua după el, și de aceea simptomul arată ca o regresie bruscă.

Verificați-le în această ordine. Un răspuns lipsă și o rută lipsă arată la fel într-un browser și complet diferit într-un jurnal de resolver.

Când resolverul se schimbă, răspunsul se schimbă

Un client VPN impune adesea propriul resolver sau preia întreaga cale a interogării, iar acel resolver poate să nu sintetizeze nimic. Interogările pentru nume care au doar IPv4 nu returnează atunci nicio înregistrare AAAA, ceea ce un client care are doar IPv6 trăiește ca un nume la care nu poate ajunge. Se întâmplă și invers: un resolver care chiar sintetizează vă poate da un prefix pe care calea voastră tunelată nu îl transportă.

Memoria cache face asta mai greu de văzut. O înregistrare sintetizată obținută în rețeaua biroului poate supraviețui contextului care a produs-o, așa că clientul continuă să se conecteze la o adresă al cărei traducător nu mai este accesibil. Uitați-vă la resolverul care răspunde acum, nu la cel care a răspuns când a fost salvată intrarea. Golirea memoriei cache fără a nota răspunsul vechi și pe cel nou distruge dovada de care aveți nevoie.

Testați interogarea și ruta separat

Interogați numele direct înainte de a implica aplicația, și notați ce server a răspuns. Comenzile de mai jos arată înregistrarea AAAA, resolverul folosit și dacă există o rută spre prefixul sintetizat. Rulați-le cu tunelul coborât și apoi din nou cu el ridicat.

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/

Citiți rezultatele ca pe un lanț. O înregistrare AAAA lipsă înseamnă că resolverul din fața voastră nu sintetizează, deci o cale care are doar IPv6 nu va funcționa pentru acel nume, orice ar face clientul. O înregistrare prezentă fără rută înseamnă că prefixul nu este transportat de calea actuală, iar aceasta este o decizie de rutare și nu o defecțiune a resolverului. O rută prezentă în timp ce cererea încă eșuează indică traducătorul însuși, iar aceasta aparține unui alt proprietar.

Notați resolverul, contextul de rețea și familia de adrese lângă fiecare rezultat. Tocmai această notă permite comparației următoare să separe o schimbare de resolver de o schimbare de rutare.

Articole similare