Kahekordse virna VPN: aadressiperekonna valib klient, mitte teie

Tunnel on üleval, IPv4 saidid laadivad ja üks hostinimi aegub. Vahetu järeldus on, et VPN on katki või et volitused on valed, ja tavaliselt pole kumbki tõsi. Nimi tagastas nii IPv4- kui ka IPv6-aadressi, rakendus valis ühe, ja ainult ühel neist kandidaatidest oli toimiv tee. Valiku tegi klient; tunnel lihtsalt ei katnud seda, mille ta valis.

Valik ei ole katte lubadus

Vaikimisi aadressivalik, mida kirjeldab RFC 6724, otsustab, millist allika ja sihtkoha paari host eelistab, kui saadaval on mitu. Happy Eyeballs lisab selle peale ühendusstrateegia: see alustab katseid mõlemas perekonnas ja hoiab selle, mis vastab esimesena, nii et kasutaja ei oota katkise perekonna aegumist.

Kumbki mehhanism ei loo marsruuti. Kui teie tunnel kannab ainult IPv4, on AAAA-kandidaat endiselt seaduslik sihtkoht, mida klient võib proovida, ja tõrge ilmneb aeglase laadimisena, mitte veana, sest brauser taandus. Kasutaja teatab aeglasest saidist, mitte katkisest, ja klienditugi pärib selle ebamäärasuse. Korrake seda fikseeritud perekonnaga ja aruanne muutub konkreetseks.

Just selle taandumise tõttu on sümptom rakenduste lõikes ebajärjekindel. Brauser peidab viivituse; fikseeritud perekonnaga käsurea klient näitab teile tegelikku tõrget kohe.

Leidke perekond, mida päring tegelikult kasutas

Alustage nimest, mitte tunnelist. Küsige mõlemat tüüpi kirjeid ja pange kirja, mis tagasi tuli:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Kui v4-päring õnnestub ja v6-päring nurjub, olete probleemi taasesitanud kujul, mida saate siluda. Kui mõlemad õnnestuvad kestast ja brauser ikka ei tööta, vaadake rakenduse enda lahendajat või vahemällu salvestatud vastust, enne kui tunnelit puudutate.

Hoidke perekond ja sihtkoht oma märkmetes. Pilet, mis ütleb, et sait ei laadi VPN-i kaudu, ei ole kellegi kontrollitav, samas kui pilet, mis ütleb, et AAAA nurjub ja A töötab, osutab konkreetsele marsruudile.

Kontrollige selle perekonna marsruuti

Nurjuva perekonna puhul küsige tuumalt, millist teed see kasutaks, ja võrrelge seda tunneli konfigureeritud aadressidega. Linuxis näitab ip -6 route get sihtkoha puhul liidest ja allikat, mis valitaks.

Seejärel kontrollige tunnelit ennast. WireGuard-peerid kannavad lubatud IP-de loendit ja kirje 0.0.0.0/0 kohta ei ütle IPv6 kohta midagi. Kui peeri loendis pole IPv6-prefiksit, pole kliendil põhjust saata AAAA-liiklust tunnelisse, ja pakett väljub selle kaudu, mida host muidu teeks.

Tulemüürireeglid ja NAT-poliitika väärivad sama kontrolli iga perekonna kohta. IPv4 jaoks kirjutatud reegel ei kata IPv6 ühelgi platvormil, ja see on kõige tavalisem põhjus, miks üks perekond töötab ja teine mitte.

Ärge lülitage IPv6 välja, et ekraanitõmmist lihtsamaks teha

IPv6 väljalülitamine kogu süsteemis paneb sümptomi kaduma ja jätab teid diagnoosita. See lõhub ka iga sihtkoha, mis on ainult IPv6, ja peidab sama vea järgmise rakenduse eest. Kui masin tõesti ei peaks IPv6 kasutama, on see teadlik poliitika, millel on omanik ja test. Selle väljalülitamine intsidendi ajal ei ole kumbki.

Otsustage, mida klient peaks perekonnaga tegema, ja seadistage see selgesõnaliselt: viige see tunnelist läbi või blokeerige see toetatud viisil, et valik ei pakuks kunagi kättesaamatut kandidaati. Mõlemad on õiguspärased lahendused. Globaalne väljalülitamine ei ole kumbki, sest see pole üldse lahendus.

Mida piletisse panna

Kirjutage üles neli asja: hostinimi, nurjunud perekond, tuuma valitud marsruut ja perekonnapõhise päringu tulemus. Sellest komplektist piisab, et keegi teine tõrget taasesitaks, ilma et peaks arvama, millist kahest teest te mõtlesite.

RFC 6724 aadressivaliku reeglid selgitavad, miks klient eelistas seda kandidaati, mida eelistas, ja RFC 8305 selgitab võidujooksukäitumist, mis viivituse peitis. Kumbki neist ei marsruudi teie eest paketti, ja just seda peab tunnel tegema.