Dvostopenjski VPN: družino naslovov izbere odjemalec, ne vi

Tunel deluje, spletna mesta IPv4 se nalagajo, eno ime gostitelja pa poteče. Takojšen sklep je, da je VPN pokvarjen ali da so poverilnice napačne, in običajno ni resnično niti eno. Ime je vrnilo naslov IPv4 in IPv6, aplikacija je izbrala enega, in le eden od teh kandidatov je imel delujočo pot. Odločitev o izbiri je sprejel odjemalec; tunel preprosto ni pokrival tega, kar je izbral.

Izbira ni obljuba pokritosti

Privzeta izbira naslova, opisana v RFC 6724, določi, kateri par vira in cilja gostitelj raje uporabi, ko je na voljo več. Happy Eyeballs doda vrh tega strategijo povezave: začne poskuse v obeh družinah in obdrži tisto, ki odgovori prva, da uporabnik ne čaka, da pokvarjena družina poteče.

Noben mehanizem ne ustvari poti. Če vaš tunel prenaša samo IPv4, je kandidat AAAA še vedno zakonit cilj, ki ga odjemalec lahko poskusi, in napaka se pokaže kot počasno nalaganje, ne kot napaka, ker se je brskalnik umaknil. Uporabnik poroča o počasnem spletnem mestu, ne o pokvarjenem, in zahtevek za podporo podeduje to nedoločenost. Ponovite s fiksno družino in poročilo postane konkretno.

Prav zaradi tega umika je simptom med aplikacijami nedosleden. Brskalnik zakasnitev skrije; odjemalec ukazne vrstice s fiksno družino vam takoj pokaže resnično napako.

Ugotovite, katero družino je zahteva dejansko uporabila

Začnite z imenom, ne s tunelom. Poizvedite po obeh vrstah zapisov in zapišite, kaj se je vrnilo:

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

Če zahteva v4 uspe in zahteva v6 ne uspe, ste težavo ponovili v obliki, ki jo lahko odpravljate. Če obe uspeta iz lupine in brskalnik še vedno ne uspe, poglejte lastni razreševalnik aplikacije ali shranjen odgovor, preden se dotaknete tunela.

Družino in cilj imejte v svojih zapiskih. Zahtevek, ki pravi, da se spletno mesto ne naloži prek VPN, ne more preveriti nihče, medtem ko zahtevek, ki pravi, da AAAA ne uspe in A deluje, kaže na določeno pot.

Preverite pot za to družino

Za družino, ki ne uspe, vprašajte jedro, katero pot bi uporabilo, in jo primerjajte z nastavljenimi naslovi tunela. V Linuxu ip -6 route get za cilj prikaže vmesnik in vir, ki bi bila izbrana.

Nato preverite sam tunel. WireGuard partnerji nosijo seznam dovoljenih IP-jev, in vnos za 0.0.0.0/0 ne pove ničesar o IPv6. Če seznam partnerja nima predpone IPv6, odjemalec nima razloga pošiljati prometa AAAA v tunel, in paket odide po tem, kar bi gostitelj sicer storil.

Pravila požarnega zidu in politika NAT si zaslužijo enako preverjanje za vsako družino. Pravilo, napisano za IPv4, ne pokriva IPv6 na nobeni platformi, in to je najpogostejši razlog, da ena družina deluje, druga pa ne.

Ne onemogočite IPv6, da bi poenostavili posnetek zaslona

Izklop IPv6 v celotnem sistemu bo odpravil simptom in vas pustil brez diagnoze. Prav tako pokvari vsak cilj, ki je samo IPv6, in skrije isto napako za naslednjo aplikacijo. Če stroj res ne bi smel uporabljati IPv6, je to namerna politika z lastnikom in testom. Izklop med incidentom ni niti eno niti drugo.

Odločite, kaj naj odjemalec stori z družino, in to izrecno nastavite: peljite jo skozi tunel ali jo blokirajte na podprt način, da izbira nikoli ne ponudi nedosegljivega kandidata. Oba sta legitimna načrta. Globalni izklop ni niti eden od njiju, ker sploh ni načrt.

Kaj vpisati v zahtevek

Zapišite štiri stvari: ime gostitelja, družino, ki ni uspela, pot, ki jo je izbralo jedro, in rezultat zahteve, specifične za družino. Ta nabor zadostuje, da nekdo drug ponovi napako, ne da bi ugibal, katero od dveh poti ste mislili.

Pravila izbire naslovov RFC 6724 pojasnjujejo, zakaj je odjemalec dal prednost kandidatu, ki mu jo je dal, in RFC 8305 pojasnjuje tekmo, ki je skrila zakasnitev. Nobeno od njiju ne bo usmerilo paketa namesto vas, in prav to mora storiti tunel.