Zašto se odgovori DNS64 mijenjaju čim se VPN poveže?

Odgovori DNS64 opisuju mrežni raspored, a ne svojstvo servera. Razrješivač sintetizira adresu IPv6 iz adrese IPv4, i rezultat radi samo tamo gdje na kraju tog prefiksa stoji prevodilac. Uvedite VPN u putanju i taj raspored može ostati, promijeniti se ili prestati biti istinit, zavisno od tri uslova.

Ti uslovi su razrješivač koji je odgovorio, ruta koju vaš uređaj ima do sintetiziranog prefiksa, i to da li bilo šta na toj ruti obavlja prevođenje. Svaki se može posmatrati, i upravo to kvar čini dijagnostikovanim.

Na šta sintetizirani AAAA zapis zapravo pokazuje

Razrješivač DNS64 odgovara na AAAA upit za ime koje podržava samo IPv4 tako što adresu IPv4 ugrađuje u prefiks koji je konfigurisan da koristi, a poznati prefiks za taj posao je 64:ff9b::/96 kako je opisano u RFC 6147. Zapis za aplikaciju izgleda kao i svaki drugi AAAA zapis, i u tome je poenta: klijent koji podržava samo IPv6 može pokušati vezu i ne znajući da odredište nikada nije imalo IPv6. Ta veza zatim zavisi od funkcije NAT64 koja negdje na putu obavlja prevođenje između dvije familije. Bez tog prevodioca, sintetizirana adresa je uvjerljivo odredište koje nikuda ne vodi.

Zapis dakle kodira dvije stvari odjednom: originalnu adresu IPv4 i pretpostavku da je prevodilac dostupan. Samo je prva vidljiva u samom odgovoru.

Tri uslova odlučuju da li još radi

Prvi uslov je koji je razrješivač proizveo zapis, jer onaj bez konfigurisanog DNS64 ne vraća ništa za to ime i aplikacija pada na drugačiji način. Drugi je da li vaš uređaj ima rutu do sintetiziranog prefiksa, jer odgovor može biti valjan dok put do njega nedostaje. Treći je da li je prevodilac koji posjeduje taj prefiks na putu koji biste koristili, jer tunel koji nosi 64:ff9b::/96 negdje drugdje stiže do druge funkcije ili ni do čega. Sva tri mogu vrijediti prije tunela i zakazati poslije njega, i zato simptom izgleda kao iznenadna regresija.

Provjerite ih tim redom. Odgovor koji nedostaje i ruta koja nedostaje izgledaju isto u pregledniku, a potpuno različito u dnevniku razrješivača.

Kada se razrješivač promijeni, odgovor se promijeni

VPN klijent često nameće svoj razrješivač ili preuzima cijelu putanju upita, a taj razrješivač možda ništa ne sintetizira. Upiti za imena koja podržavaju samo IPv4 tada ne vraćaju AAAA zapis, što klijent koji podržava samo IPv6 doživljava kao ime do kojeg ne može doći. Događa se i obrnuto: razrješivač koji zaista sintetizira može vam dati prefiks koji vaša tunelirana putanja ne nosi.

Keširanje ovo čini teže vidljivim. Sintetizirani zapis dobijen na uredskoj mreži može nadživjeti kontekst koji ga je proizveo, pa se klijent nastavlja povezivati na adresu čiji prevodilac više nije dostupan. Gledajte razrješivač koji odgovara sada, a ne onaj koji je odgovorio kada je unos sačuvan. Pražnjenje keša bez bilježenja starog i novog odgovora uništava dokaz koji vam treba.

Ispitajte pretragu i putanju odvojeno

Pitajte ime direktno prije nego uključite aplikaciju, i zabilježite koji je server odgovorio. Komande ispod pokazuju AAAA zapis, razrješivač koji se koristi i da li postoji ruta do sintetiziranog prefiksa. Pokrenite ih s isključenim tunelom, pa ponovo s uključenim.

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/

Čitajte rezultate kao lanac. AAAA zapis koji nedostaje znači da razrješivač pred vama ne sintetizira, pa putanja koja podržava samo IPv6 neće raditi za to ime, šta god klijent radio. Zapis postoji a rute nema znači da prefiks ne nosi trenutna putanja, i to je odluka o rutiranju, a ne kvar razrješivača. Ruta postoji dok zahtjev još pada — to pokazuje na sam prevodilac, a to pripada još jednom vlasniku.

Zabilježite razrješivač, mrežni kontekst i familiju adresa pored svakog rezultata. Upravo ta bilješka omogućava sljedećem poređenju da odvoji promjenu razrješivača od promjene rutiranja.