Dvostruki stack VPN: klijent bira porodicu adresa, ne vi

Tunel je podignut, IPv4 stranice se učitavaju, a jedno ime hosta isteče. Neposredan zaključak je da je VPN pokvaren ili su vjerodajnice 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 donio je klijent; tunel jednostavno nije pokrivao ono što je izabrao.

Izbor nije obećanje pokrivenosti

Podrazumijevani 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 obje 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 neuspjeh se pojavljuje kao sporo učitavanje, a ne kao greška, jer je preglednik pao na rezervu. Korisnik prijavljuje sporu stranicu, a ne pokvarenu, i tiket za podršku nasljeđuje tu neodređenost. Reproducirajte to s fiksnom porodicom i izvještaj postaje konkretan.

Zbog tog povratka simptom je nedosljedan među aplikacijama. Preglednik skriva kašnjenje; klijent komandne linije s fiksnom porodicom odmah vam pokaže pravi neuspjeh.

Pronađite porodicu koju je zahtjev zaista koristio

Počnite s imenom, ne s tunelom. Provjerite oba tipa zapisa i zabiljež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 zahtjev uspije, a v6 zahtjev ne uspije, reproducirali ste problem u obliku koji možete otklanjati. Ako oba uspiju iz ljuske, a preglednik i dalje ne uspijeva, pogledajte vlastiti rješavač aplikacije ili keširani odgovor prije nego što dirate tunel.

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

Provjerite rutu za tu porodicu

Za porodicu koja ne uspijeva, pitajte kernel koji put bi 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 provjerite 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 slati AAAA promet u tunel, a paket izlazi kroz ono što bi host inače uradio.

Pravila firewall-a i NAT politika zaslužuju istu provjeru 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činit će da simptom nestane i ostaviti vas bez dijagnoze. Ono također kvari svako odredište koje je samo IPv6, i skriva istu grešku za sljedeću aplikaciju. Ako neka mašina zaista ne treba koristiti IPv6, to je namjerna politika s vlasnikom i testom. Isključivanje tokom incidenta nije ni jedno ni drugo.

Odlučite šta klijent treba raditi s porodicom i konfigurirajte 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će nije dizajn.

Šta staviti u tiket

Zabilježite četiri stvari: ime hosta, porodicu koja nije uspjela, rutu koju je kernel izabrao i rezultat zahtjeva specifičnog za porodicu. Taj skup je dovoljan da neko drugi reproducira neuspjeh 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 umjesto vas, a to je dio koji tunel mora odraditi.