Varför ändras DNS64-svaren så snart VPN:et ansluter?

DNS64-svar beskriver ett nätverksarrangemang snarare än en egenskap hos servern. Resolvern syntetiserar en IPv6-adress från en IPv4-adress, och resultatet fungerar bara där en översättare sitter i änden av det prefixet. För in ett VPN i vägen och det arrangemanget kan hålla, ändras eller sluta vara sant beroende på tre villkor.

Dessa villkor är resolvern som svarade, den rutt din enhet har till det syntetiserade prefixet, och om något på den rutten utför översättningen. Var och en går att observera, och det är just det som gör felet diagnostiserbart.

Vad en syntetiserad AAAA-post egentligen pekar på

En DNS64-resolver besvarar en AAAA-fråga för ett namn som bara har IPv4 genom att bädda in IPv4-adressen i ett prefix som den är konfigurerad att använda, och det välkända prefixet för det jobbet är 64:ff9b::/96 som beskrivs i RFC 6147. Posten ser för applikationen ut som vilken annan AAAA-post som helst, och det är poängen: en klient som bara har IPv6 kan försöka med en anslutning utan att veta att målet aldrig hade IPv6. Den anslutningen beror sedan på en NAT64-funktion som någonstans på vägen översätter mellan de två familjerna. Utan den översättaren är den syntetiserade adressen ett trovärdigt utseende mål som inte leder någonstans.

Posten kodar alltså två saker på en gång: den ursprungliga IPv4-adressen och antagandet att en översättare är nåbar. Bara det första syns i själva svaret.

Tre villkor avgör om det fortfarande fungerar

Det första villkoret är vilken resolver som producerade posten, eftersom en utan konfigurerad DNS64 inte returnerar något för det namnet och applikationen misslyckas på ett annat sätt. Det andra är om din enhet har en rutt till det syntetiserade prefixet, eftersom ett svar kan vara giltigt medan vägen dit saknas. Det tredje är om översättaren som äger prefixet finns på den väg du skulle använda, eftersom en tunnel som bär 64:ff9b::/96 någon annanstans når en annan funktion eller ingenting. Alla tre kan gälla före tunneln och misslyckas efter den, och därför ser symtomet ut som en plötslig regression.

Kontrollera dem i den ordningen. Ett saknat svar och en saknad rutt ser likadana ut i en webbläsare och helt olika i en resolverlogg.

När resolvern ändras ändras svaret

En VPN-klient trycker ofta in sin egen resolver eller tar över hela frågevägen, och den resolvern kanske inte syntetiserar något. Frågor efter namn som bara har IPv4 ger då ingen AAAA-post, vilket en klient som bara har IPv6 upplever som ett namn den inte når. Det motsatta händer också: en resolver som faktiskt syntetiserar kan ge dig ett prefix som din tunnlade väg inte bär.

Cachning gör detta svårare att se. En syntetiserad post hämtad på kontorsnätet kan överleva det sammanhang som skapade den, så klienten fortsätter att ansluta till en adress vars översättare inte längre är nåbar. Titta på resolvern som svarar nu i stället för den som svarade när posten sparades. Att tömma cachen utan att anteckna det gamla och det nya svaret förstör det bevis du behöver.

Testa uppslaget och vägen var för sig

Fråga direkt efter namnet innan du kopplar in applikationen, och notera vilken server som svarade. Kommandona nedan visar AAAA-posten, resolvern som används och om det finns en rutt till det syntetiserade prefixet. Kör dem med tunneln nere och sedan igen med den uppe.

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/

Läs resultaten som en kedja. En saknad AAAA-post betyder att resolvern framför dig inte syntetiserar, så en väg som bara har IPv6 kommer inte att fungera för det namnet, vad klienten än gör. En post som finns utan rutt betyder att prefixet inte bärs av den aktuella vägen, och det är ett routingbeslut och inte ett resolverfel. En rutt som finns medan begäran fortfarande misslyckas pekar på själva översättaren, och det tillhör en annan ägare.

Anteckna resolvern, nätverkssammanhanget och adressfamiljen bredvid varje resultat. Det är den anteckningen som låter nästa jämförelse skilja ett resolverbyte från ett routingbyte.