Dvostruki stack VPN: klijent bira porodicu adresa, ne vi

Tunel je podignut, IPv4 stranice se učitavaju, a jedno ime hosta ističe. Neposredan zaključak je da je VPN pokvaren ili su verodajnice pogrešne, a obično nije tačno ni jedno. Ime je vratilo i IPv4 i IPv6 adresu, aplikacija je izabrala jednu, a samo je jedan od tih kandidata imao radni put. Odluku o izboru doneo je klijent; tunel jednostavno nije pokrivao ono što je izabrao.

Izbor nije obećanje pokrivenosti

Podrazumevani izbor adrese, opisan u RFC 6724, određuje koji par izvora i odredišta host preferira kada ih je dostupno nekoliko. Happy Eyeballs dodaje povrh toga strategiju povezivanja: započinje pokušaje na obe porodice i zadržava onaj koji prvi odgovori, pa korisnik ne čeka da pokvarena porodica istekne.

Nijedan mehanizam ne stvara rutu. Ako vaš tunel nosi samo IPv4, AAAA kandidat je i dalje legitiman cilj koji klijent može pokušati, a neuspeh se pojavljuje kao sporo učitavanje, a ne kao greška, jer je pregledač pao na rezervu. Korisnik prijavljuje sporu stranicu, a ne pokvarenu, i tiket za podršku nasleđuje tu neodređenost. Reprodukujte to s fiksnom porodicom i izveštaj postaje konkretan.

Zbog tog povratka simptom je nedosledan među aplikacijama. Pregledač skriva kašnjenje; klijent komandne linije s fiksnom porodicom odmah vam pokaže pravi neuspeh.

Pronađite porodicu koju je zahtev zaista koristio

Počnite s imenom, ne s tunelom. Proverite oba tipa zapisa i zabeležite šta se vratilo:

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

Ako v4 zahtev uspe, a v6 zahtev ne uspe, reprodukovali ste problem u obliku koji možete otklanjati. Ako oba uspeju iz ljuske, a pregledač i dalje ne uspeva, pogledajte vlastiti razrešivač aplikacije ili keširani odgovor pre nego što dirate tunel.

Držite porodicu i odredište u svojim beleškama. Tiket koji kaže da se stranica ne učitava preko VPN-a ne može proveriti niko, dok tiket koji kaže da AAAA ne uspeva, a A radi, ukazuje na konkretnu rutu.

Proverite rutu za tu porodicu

Za porodicu koja ne uspeva, pitajte kernel koji bi put koristio i uporedite ga s konfigurisanim adresama tunela. Na Linuxu ip -6 route get za odredište prikazuje interfejs i izvor koji bi bili izabrani.

Zatim proverite sam tunel. WireGuard peerovi nose listu dozvoljenih IP adresa, a unos za 0.0.0.0/0 ne govori ništa o IPv6. Ako lista peera nema IPv6 prefiks, klijent nema razloga da šalje AAAA saobraćaj u tunel, a paket izlazi kroz ono što bi host inače uradio.

Pravila firewall-a i NAT politika zaslužuju istu proveru po porodici. Pravilo napisano za IPv4 ne pokriva IPv6 ni na jednoj platformi, i to je najčešći razlog zašto jedna porodica radi, a druga ne.

Ne isključujte IPv6 da biste pojednostavili snimak ekrana

Isključivanje IPv6 na nivou sistema učiniće da simptom nestane i ostaviti vas bez dijagnoze. Ono takođe kvari svako odredište koje je samo IPv6, i skriva istu grešku za sledeću aplikaciju. Ako neka mašina zaista ne treba da koristi IPv6, to je namerna politika s vlasnikom i testom. Isključivanje tokom incidenta nije ni jedno ni drugo.

Odlučite šta klijent treba da radi s porodicom i konfigurišite to eksplicitno: provedite je kroz tunel ili je blokirajte na podržan način tako da izbor nikada ne nudi nedostupnog kandidata. Oba su legitimna dizajna. Globalno isključivanje nije ni jedno od toga, jer uopšte nije dizajn.

Šta staviti u tiket

Zabeležite četiri stvari: ime hosta, porodicu koja nije uspela, rutu koju je kernel izabrao i rezultat zahteva specifičnog za porodicu. Taj skup je dovoljan da neko drugi reprodukuje neuspeh bez nagađanja koji od dva puta ste mislili.

Pravila izbora adrese RFC 6724 objašnjavaju zašto je klijent preferirao kandidata kojeg jest, a RFC 8305 objašnjava trkajuće ponašanje koje je sakrilo kašnjenje. Nijedno od njih neće rutirati paket umesto vas, a to je deo koji tunel mora da odradi.