Waarom verander DNS64-antwoorde sodra die VPN koppel?
’n DNS64-antwoord kodeer ’n vertaalaanname. Kyk watter herleier geantwoord het, of die voorvoegsel gerouteer word, en of daar ’n vertaler op jou pad sit.
DNS64-antwoorde beskryf ’n netwerkreëling eerder as ’n eienskap van die bediener. Die herleier sintetiseer ’n IPv6-adres uit ’n IPv4-een, en die resultaat werk net waar ’n vertaler aan die einde van daardie voorvoegsel sit. Bring ’n VPN in die pad en daardie reëling kan hou, verander of ophou waar wees, afhangend van drie voorwaardes.
Daardie voorwaardes is die herleier wat geantwoord het, die roete wat jou toestel na die gesintetiseerde voorvoegsel het, en of enigiets op daardie roete die vertaling doen. Elkeen is waarneembaar, en dit is wat die faling diagnoseerbaar maak.
Waar ’n gesintetiseerde AAAA-rekord eintlik na wys
’n DNS64-herleier antwoord ’n AAAA-navraag vir ’n naam met net IPv4 deur die IPv4-adres in ’n voorvoegsel te plaas wat hy gekonfigureer is om te gebruik, en die welbekende voorvoegsel daarvoor is 64:ff9b::/96 soos beskryf in RFC 6147. Die rekord lyk vir die toepassing soos enige ander AAAA-rekord, en dit is die punt: ’n kliënt met net IPv6 kan ’n verbinding probeer sonder om te weet dat die bestemming nooit IPv6 gehad het nie. Daardie verbinding hang dan van ’n NAT64-funksie af wat elders langs die pad tussen die twee families vertaal. Sonder daardie vertaler is die gesintetiseerde adres ’n geloofwaardig-voorkomende bestemming wat nêrens heen gaan nie.
Die rekord kodeer dus twee dinge tegelyk, die oorspronklike IPv4-adres en die aanname dat ’n vertaler bereikbaar is. Net die eerste is in die antwoord self sigbaar.
Drie voorwaardes bepaal of dit steeds werk
Die eerste voorwaarde is watter herleier die rekord geproduseer het, want een sonder DNS64 gekonfigureer gee niks vir daardie naam terug nie, en die toepassing faal op ’n ander manier. Die tweede is of jou toestel ’n roete na die gesintetiseerde voorvoegsel het, want ’n antwoord kan geldig wees terwyl die pad daarheen ontbreek. Die derde is of die vertaler wat daardie voorvoegsel besit op die pad is wat jy sou gebruik, want ’n tonnel wat 64:ff9b::/96 elders heen dra, bereik ’n ander funksie of niks. Al drie kan voor die tonnel geld en daarna faal, en dit is waarom die simptoom soos ’n skielike regressie lyk.
Kontroleer hulle in daardie volgorde. ’n Ontbrekende antwoord en ’n ontbrekende roete lyk in ’n blaaier identies en in ’n herleierlog heeltemal anders.
Wanneer die herleier verander, verander die antwoord
’n VPN-kliënt stoot dikwels sy eie herleier of neem die navraagpad heeltemal oor, en daardie herleier sintetiseer dalk niks. Navrae vir name met net IPv4 gee dan geen AAAA-rekord terug nie, wat ’n kliënt met net IPv6 ervaar as ’n naam wat hy nie kan bereik nie. Die omgekeerde gebeur ook: ’n herleier wat wel sintetiseer kan jou ’n voorvoegsel gee wat jou getonnelde pad nie dra nie.
Die kasgeheue maak dit moeiliker om raak te sien. ’n Gesintetiseerde rekord wat op die kantoornetwerk verkry is, kan die konteks waarin dit ontstaan het oorleef, so die kliënt bly aan ’n adres koppel waarvan die vertaler nie meer bereikbaar is nie. Kyk na die herleier wat nou antwoord eerder as die een wat geantwoord het toe die inskrywing gestoor is. Om die kas te leegmaak sonder om die ou en nuwe antwoorde te boekstaaf, vernietig die bewyse wat jy nodig het.
Toets die opsoek en die pad apart
Vra die naam direk voordat jy die toepassing betrek, en let op watter bediener geantwoord het. Die opdragte hieronder wys die AAAA-rekord, die herleier wat gebruik word, en of daar ’n roete na die gesintetiseerde voorvoegsel bestaan. Voer hulle uit terwyl die tonnel af is en daarna weer terwyl dit aan is.
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/
Lees die resultate as ’n ketting. ’n Ontbrekende AAAA-rekord beteken die herleier voor jou sintetiseer nie, so ’n pad met net IPv6 sal nie vir daardie naam werk nie, wat die kliënt ook doen. ’n Rekord wat teenwoordig is sonder ’n roete beteken die voorvoegsel word nie deur die huidige pad gedra nie, wat ’n roetebeslissing is eerder as ’n herleierfout. ’n Roete wat teenwoordig is terwyl die versoek steeds misluk, wys op die vertaler self, en dit behoort aan nog ’n ander eienaar.
Boekstaaf die herleier, die netwerkkonteks en die adresfamilie langs elke resultaat. Dit is die nota wat die volgende vergelyking in staat stel om ’n herleierverandering van ’n roeteverandering te skei.