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

Odgovori DNS64 opisuju mrežni raspored, a ne svojstvo poslužitelja. Razrješivač sintetizira adresu IPv6 iz adrese IPv4, i rezultat radi samo tamo gdje na kraju tog prefiksa sjedi prevodilac. Uvedite VPN u put i taj raspored može ostati, promijeniti se ili prestati biti istinit, ovisno o tri uvjeta.

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

Na što sintetizirani AAAA zapis zapravo pokazuje

Razrješivač DNS64 odgovara na AAAA upit za ime koje podržava samo IPv4 tako da adresu IPv4 ugrađuje u prefiks koji je konfiguriran koristiti, a poznati prefiks za taj posao je 64:ff9b::/96 kako je opisano u RFC 6147. Zapis aplikaciji izgleda kao i svaki drugi AAAA zapis, i u tome je poanta: 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 ovisi o funkciji NAT64 koja negdje na putu prevodi između dviju obitelji. Bez tog prevoditelja, sintetizirana adresa je uvjerljivo odredište koje nikamo ne vodi.

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

Tri uvjeta odlučuju radi li još

Prvi je uvjet koji je razrješivač proizveo zapis, jer onaj bez konfiguriranog DNS64 ne vraća ništa za to ime i aplikacija pada na drukčiji način. Drugi je ima li vaš uređaj rutu do sintetiziranog prefiksa, jer odgovor može biti valjan dok put do njega nedostaje. Treći je je li prevoditelj 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 jednako u pregledniku, a posve različito u dnevniku razrješivača.

Kad se razrješivač promijeni, odgovor se promijeni

VPN klijent često nameće svoj razrješivač ili preuzima cijeli put 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 doista sintetizira može vam dati prefiks koji vaš tunelirani put ne nosi.

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

Ispitajte pretragu i put odvojeno

Pitajte ime izravno prije nego uključite aplikaciju, i zabilježite koji je poslužitelj odgovorio. Naredbe ispod pokazuju AAAA zapis, razrješivač koji se koristi i postoji li ruta do sintetiziranog prefiksa. Pokrenite ih s isključenim tunelom, pa ponovno 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 put koji podržava samo IPv6 neće raditi za to ime, što god klijent radio. Zapis postoji a rute nema znači da prefiks ne nosi trenutni put, i to je odluka o rutiranju, a ne kvar razrješivača. Ruta postoji dok zahtjev još pada — to upućuje na sam prevoditelj, a to pripada još jednom vlasniku.

Zabilježite razrješivač, mrežni kontekst i obitelj adresa uz svaki rezultat. Upravo ta bilješka omogućuje sljedećoj usporedbi da odvoji promjenu razrješivača od promjene rutiranja.