Dlaczego odpowiedzi DNS64 zmieniają się, gdy tylko połączy się VPN?

Odpowiedzi DNS64 opisują układ sieci, a nie właściwość serwera. Resolver syntetyzuje adres IPv6 z adresu IPv4, a wynik działa tylko tam, gdzie na końcu tego prefiksu stoi translator. Wprowadź VPN na ścieżkę, a ten układ może się utrzymać, zmienić albo przestać być prawdziwy w zależności od trzech warunków.

Tymi warunkami są resolver, który odpowiedział, trasa, jaką twoje urządzenie ma do syntetyzowanego prefiksu, oraz to, czy cokolwiek na tej trasie wykonuje tłumaczenie. Każdy z nich można zaobserwować i właśnie to czyni awarię diagnozowalną.

Na co naprawdę wskazuje syntetyzowany rekord AAAA

Resolver DNS64 odpowiada na zapytanie AAAA o nazwę mającą tylko IPv4, osadzając adres IPv4 w prefiksie, którego jest skonfigurowany używać, a znanym prefiksem do tego zadania jest 64:ff9b::/96, jak opisano w RFC 6147. Dla aplikacji rekord wygląda jak każdy inny rekord AAAA i właśnie o to chodzi: klient mający tylko IPv6 może spróbować połączenia, nie wiedząc, że cel nigdy nie miał IPv6. To połączenie zależy wtedy od funkcji NAT64, która gdzieś na ścieżce tłumaczy między obiema rodzinami. Bez tego translatora syntetyzowany adres jest wiarygodnie wyglądającym celem, który donikąd nie prowadzi.

Rekord koduje więc dwie rzeczy naraz: pierwotny adres IPv4 i założenie, że translator jest osiągalny. W samej odpowiedzi widoczna jest tylko pierwsza.

Trzy warunki decydują, czy to nadal działa

Pierwszym warunkiem jest to, który resolver wytworzył rekord, bo ten bez skonfigurowanego DNS64 nic nie zwraca dla tej nazwy i aplikacja zawodzi w inny sposób. Drugim jest to, czy urządzenie ma trasę do syntetyzowanego prefiksu, bo odpowiedź może być poprawna, podczas gdy droga do niej brakuje. Trzecim jest to, czy translator będący właścicielem tego prefiksu znajduje się na trasie, której byś użył, bo tunel znoszący 64:ff9b::/96 gdzie indziej dociera do innej funkcji albo donikąd. Wszystkie trzy mogą zachodzić przed tunelem i zawieść po nim, i dlatego objaw wygląda jak nagła regresja.

Sprawdzaj je w tej kolejności. Brakująca odpowiedź i brakująca trasa wyglądają w przeglądarce identycznie, a w logu resolvera zupełnie inaczej.

Gdy zmienia się resolver, zmienia się odpowiedź

Klient VPN często przepycha własny resolver albo przejmuje całą ścieżkę zapytania, a ten resolver może niczego nie syntetyzować. Zapytania o nazwy mające tylko IPv4 nie zwracają wtedy rekordu AAAA, co klient mający tylko IPv6 odczuwa jako nazwę, do której nie może dotrzeć. Bywa też odwrotnie: resolver, który naprawdę syntetyzuje, może dać prefiks, którego twoja tunelowana ścieżka nie niesie.

Buforowanie utrudnia to zauważyć. Syntetyzowany rekord uzyskany w sieci biurowej może przeżyć kontekst, który go wytworzył, więc klient nadal łączy się z adresem, którego translator nie jest już osiągalny. Patrz na resolver, który odpowiada teraz, a nie na ten, który odpowiedział, gdy wpis został zapisany. Wyczyszczenie bufora bez zanotowania starej i nowej odpowiedzi niszczy dowód, którego potrzebujesz.

Testuj zapytanie i ścieżkę osobno

Zapytaj o nazwę bezpośrednio, zanim włączysz aplikację, i zanotuj, który serwer odpowiedział. Poniższe polecenia pokazują rekord AAAA, używany resolver i to, czy istnieje trasa do syntetyzowanego prefiksu. Uruchom je z wyłączonym tunelem, a potem ponownie z włączonym.

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/

Czytaj wyniki jak łańcuch. Brak rekordu AAAA oznacza, że resolver przed tobą nie syntetyzuje, więc ścieżka mająca tylko IPv6 nie zadziała dla tej nazwy, cokolwiek zrobi klient. Rekord jest, a trasy nie ma — prefiksu nie niesie bieżąca ścieżka, i to decyzja o routingu, a nie awaria resolvera. Trasa jest, a żądanie wciąż zawodzi — to wskazuje na sam translator, a to należy do innego właściciela.

Zanotuj resolver, kontekst sieci i rodzinę adresów obok każdego wyniku. Właśnie ta notatka pozwala następnemu porównaniu oddzielić zmianę resolvera od zmiany routingu.