Zergatik aldatzen dira DNS64 erantzunak VPN-a konektatzean?

DNS64 erantzunek sarearen antolaketa bat deskribatzen dute, ez zerbitzariaren propietatea. Resolverrak IPv4 helbide batetik IPv6 helbide bat sintetizatzen du, eta emaitza prefiko horren amaieran itzultzaile bat dagoen tokian soilik funtzionatzen du. Eraman VPN bat bidera eta antolaketa horrek eutsi, aldatu edo egia izateari utzi diezaioke hiru baldintzaren arabera.

Baldintza horiek erantzun zuen resolverra, zure gailuak sintetizatutako prefikorako duen bidea eta bide horretan ezerk itzulpena egiten duen ala ez dira. Bakoitza behatzeko modukoa da, eta horrek egiten du hutsa diagnostikagarri.

Zertara seinalatzen duen AAAA erregistro sintetizatu batek

DNS64 resolver batek IPv4 soilik duen izen baten AAAA kontsultari erantzuten dio IPv4 helbidea erabiltzeko konfiguratuta duen prefiko baten barruan txertatuz, eta lan horretarako prefiko ezaguna 64:ff9b::/96 da, RFC 6147 dokumentuan deskribatzen den bezala. Aplikazioarentzat erregistroa beste edozein AAAA erregistro bezalakoa da, eta horixe da kontua: IPv6 soilik duen bezero batek konexioa proba dezake helmugak inoiz IPv6 izan ez zuela jakin gabe. Ondoren konexio hori NAT64 funtzio baten mende dago, bidean nonbait bi familien artean itzultzen duena. Itzultzaile hori gabe, sintetizatutako helbidea itxura sinesgarria duen helmuga bat da, inora eramaten ez duena.

Beraz, erregistroak bi gauza kodetzen ditu batera: jatorrizko IPv4 helbidea eta itzultzailea eskuragarri dagoelako hipotesia. Lehenengoa soilik da ikusgai erantzunean bertan.

Hiru baldintzek erabakitzen dute oraindik funtzionatzen duen

Lehen baldintza resolverrek erregistroa sortu zuen da, DNS64 konfiguratuta ez duen batek izen horretarako ezer itzultzen ez duelako eta aplikazioak beste modu batera huts egiten duelako. Bigarrena zure gailuak sintetizatutako prefikorako bidea duen ala ez da, erantzuna baliozkoa izan baitaiteke hara bidea falta den bitartean. Hirugarrena prefiko horren jabe den itzultzailea erabiliko zenukeen bidean dagoen ala ez da, 64:ff9b::/96 beste norabait daraman tunel batek beste funtzio batera edo ezer ez baitu iristen. Hirurak bete daitezke tunelaren aurretik eta huts egin ondoren, eta horregatik sintomak bat-bateko erregresio itxura du.

Egiaztatu itzazu ordena horretan. Erantzunik eza eta biderik eza berdin ikusten dira nabigatzailean eta erabat desberdin resolverraren erregistroan.

Resolverra aldatzen denean, erantzuna aldatzen da

VPN bezero batek maiz bere resolverra bultzatzen du edo kontsultaren bide osoa bere gain hartzen du, eta resolver horrek agian ez du ezer sintetizatzen. IPv4 soilik duten izenen kontsultek orduan ez dute AAAA erregistrorik itzultzen, eta IPv6 soilik duen bezero batek iritsi ezin duen izen gisa bizi du hori. Alderantzizkoa ere gertatzen da: benetan sintetizatzen duen resolver batek zure tunel-bideak eramaten ez duen prefiko bat eman diezazuke.

Cacheak zailago egiten du hau ikustea. Bulegoko sarean lortutako erregistro sintetizatu batek sortu zuen testuingurua gaindi dezake, beraz bezeroak itzultzailea jada eskuragarri ez duen helbidera konektatzen jarraitzen du. Begira ezazu orain erantzuten ari den resolverrari, sarrera gorde zenean erantzun zuenari eta ez. Cachea hustea erantzun zaharra eta berria erregistratu gabe behar duzun froga suntsitzea da.

Probatu kontsulta eta bidea bereizita

Galdetu izenari zuzenean aplikazioa sartu aurretik, eta ohartu zein zerbitzarik erantzun zuen. Beheko komanduek AAAA erregistroa, erabiltzen ari den resolverra eta sintetizatutako prefikorako bidea badagoen erakusten dute. Exekutatu itzazu tunela jaitsita eta gero berriro igota.

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/

Irakurri emaitzak kate gisa. AAAA erregistroa falta da resolverrak ez duela sintetizatzen esan nahi du, beraz IPv6 soilik duen bideak ez du izen horretarako funtzionatuko, bezeroak zer egin ere. Erregistroa badago eta biderik ez: prefikoa ez du uneko bideak eramaten, eta hori bideratze-erabakia da, ez resolverraren akatsa. Bidea badago eta eskaerak huts egiten jarraitzen du: itzultzaileari berari seinalatzen dio, eta hori beste jabe bati dagokio.

Erregistra itzazu resolverra, sare-testuingurua eta helbide-familia emaitza bakoitzaren ondoan. Ohar horri esker, hurrengo konparaketak resolver-aldaketa bat bideratze-aldaketatik bereizten du.