Miért változnak meg a DNS64 válaszok, amint a VPN csatlakozik?

A DNS64 válasz egy fordítási feltevést kódol. Ellenőrizze, melyik feloldó válaszolt, a prefix útvonalazott-e, és ül-e fordító az útvonalán.

A DNS64 válaszok hálózati elrendezést írnak le, nem a kiszolgáló tulajdonságát. A feloldó IPv4-címből IPv6-címet szintetizál, és az eredmény csak ott működik, ahol a prefix végén fordító ül. Vigyen VPN-t az útvonalba, és ez az elrendezés három feltételtől függően fennmaradhat, megváltozhat vagy megszűnhet igaz lenni.

Ezek a feltételek a válaszoló feloldó, az útvonal, amely az eszközétől a szintetizált prefixig vezet, és az, hogy végrehajt-e valami fordítást azon az útvonalon. Mindegyik megfigyelhető, és éppen ez teszi diagnosztizálhatóvá a hibát.

Mire mutat valójában egy szintetizált AAAA-rekord

A DNS64 feloldó úgy válaszol egy csak IPv4-es név AAAA-kérdésére, hogy az IPv4-címet beágyazza egy prefixbe, amelynek használatára be van állítva, és ennek a munkának a jól ismert prefixe a 64:ff9b::/96, ahogyan a RFC 6147 leírja. A rekord az alkalmazás számára úgy néz ki, mint bármely más AAAA-rekord, és éppen ez a lényeg: egy csak IPv6-os kliens megkísérelhet kapcsolatot anélkül, hogy tudná, a cél soha nem rendelkezett IPv6-tal. Ez a kapcsolat aztán egy NAT64-függvénytől függ, amely valahol az útvonalon a két család között fordít. E fordító nélkül a szintetizált cím hihetőnek látszó cél, amely sehová nem vezet.

A rekord tehát egyszerre két dolgot kódol: az eredeti IPv4-címet és azt a feltevést, hogy a fordító elérhető. Csak az első látható magában a válaszban.

Három feltétel dönti el, működik-e még

Az első feltétel az, melyik feloldó állította elő a rekordot, mert a beállított DNS64 nélküli semmit sem ad vissza arra a névre, és az alkalmazás más módon hibázik. A második az, van-e az eszközének útvonala a szintetizált prefixhez, mert a válasz érvényes lehet, miközben hiányzik hozzá az út. A harmadik az, hogy a prefixet birtokló fordító azon az útvonalon van-e, amelyet használna, mert a 64:ff9b::/96-ot máshová vivő alagút más funkcióhoz vagy semmihez érkezik. Mindhárom teljesülhet az alagút előtt és hiúsulhat meg utána, és ezért tűnik a tünet hirtelen visszaesésnek.

Ebben a sorrendben ellenőrizze őket. A hiányzó válasz és a hiányzó útvonal egy böngészőben azonosnak látszik, egy feloldónaplóban pedig teljesen különbözik.

Amikor a feloldó megváltozik, a válasz is megváltozik

A VPN-kliens gyakran a saját feloldóját tolja át, vagy teljesen átveszi a lekérdezési útvonalat, és az a feloldó lehet, hogy semmit nem szintetizál. A csak IPv4-es nevek lekérdezései ekkor nem adnak vissza AAAA-rekordot, amit a csak IPv6-os kliens olyan névként él meg, amelyet nem ér el. Fordítva is előfordul: egy valóban szintetizáló feloldó olyan prefixet adhat, amelyet az alagutazott útvonala nem visz.

A gyorsítótárazás nehezebbé teszi ezt látni. Az irodai hálózaton szerzett szintetizált rekord túlélheti az őt létrehozó környezetet, így a kliens továbbra is olyan címhez kapcsolódik, amelynek fordítója már nem érhető el. Most a válaszoló feloldót nézze, ne azt, amelyik a bejegyzés mentésekor válaszolt. A gyorsítótár törlése a régi és az új válasz rögzítése nélkül megsemmisíti a szükséges bizonyítékot.

A lekérdezést és az útvonalat külön tesztelje

Kérdezze le a nevet közvetlenül, mielőtt az alkalmazást bevonná, és jegyezze fel, melyik kiszolgáló válaszolt. Az alábbi parancsok megmutatják az AAAA-rekordot, a használt feloldót és azt, hogy létezik-e útvonal a szintetizált prefixhez. Futtassa őket lezárt alagúttal, majd újra nyitottal.

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áncként olvassa az eredményeket. A hiányzó AAAA-rekord azt jelenti, hogy az Ön előtti feloldó nem szintetizál, tehát a csak IPv6-os útvonal nem fog működni ahhoz a névhez, bármit tesz a kliens. A rekord megvan, de útvonal nincs: a prefixet a jelenlegi útvonal nem viszi, és ez útvonalválasztási döntés, nem feloldóhiba. Az útvonal megvan, miközben a kérés továbbra is meghiúsul: ez magára a fordítóra mutat, és az már egy másik tulajdonoshoz tartozik.

Jegyezze fel a feloldót, a hálózati környezetet és a címcsaládot minden eredmény mellé. Ez a feljegyzés teszi lehetővé, hogy a következő összehasonlítás elválassza a feloldóváltást az útvonalválasztás-váltástól.

Kapcsolódó cikkek