Dvostruki stack VPN: klijent bira obitelj adresa, ne vi

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

Odabir nije obećanje pokrivenosti

Zadani odabir 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 obitelji i zadržava onaj koji prvi odgovori, pa korisnik ne čeka da pokvarena obitelj 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 pogreška, jer je preglednik pao na rezervu. Korisnik prijavljuje sporu stranicu, a ne pokvarenu, i zahtjev za podršku nasljeđuje tu neodređenost. Reproducirajte to s fiksnom obitelji i izvještaj postaje konkretan.

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

Pronađite obitelj koju je zahtjev zaista koristio

Počnite s imenom, ne s tunelom. Provjerite oba tipa zapisa i zabilježite što 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 razrješivač aplikacije ili keširani odgovor prije nego što dirate tunel.

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

Provjerite rutu za tu obitelj

Za obitelj koja ne uspijeva, pitajte jezgru koji bi put koristila i usporedite ga s konfiguriranim adresama tunela. Na Linuxu ip -6 route get za odredište prikazuje sučelje i izvor koji bi bili odabrani.

Zatim provjerite sam tunel. WireGuard peerovi nose popis dopuštenih IP adresa, a unos za 0.0.0.0/0 ne govori ništa o IPv6. Ako popis peera nema IPv6 prefiks, klijent nema razloga slati AAAA promet u tunel, a paket izlazi kroz ono što bi host inače učinio.

Pravila vatrozida i NAT politika zaslužuju istu provjeru po obitelji. Pravilo napisano za IPv4 ne pokriva IPv6 ni na jednoj platformi, i to je najčešći razlog zašto jedna obitelj radi, a druga ne.

Ne isključujte IPv6 da biste pojednostavili snimku zaslona

Isključivanje IPv6 na razini sustava 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 neko računalo zaista ne treba koristiti IPv6, to je namjerna politika s vlasnikom i testom. Isključivanje tijekom incidenta nije ni jedno ni drugo.

Odlučite što klijent treba raditi s obitelji i konfigurirajte to eksplicitno: provedite je kroz tunel ili je blokirajte na podržan način tako da odabir nikada ne nudi nedostupnog kandidata. Oba su legitimna dizajna. Globalno isključivanje nije ni jedno od toga, jer uopće nije dizajn.

Što staviti u zahtjev

Zabilježite četiri stvari: ime hosta, obitelj koja nije uspjela, rutu koju je jezgra odabrala i rezultat zahtjeva specifičnog za obitelj. Taj je skup dovoljan da netko drugi reproducira neuspjeh bez nagađanja koji od dva puta ste mislili.

Pravila odabira adresa RFC 6724 objašnjavaju zašto je klijent preferirao kandidata kojeg jest, a RFC 8305 objašnjava utrkujuć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.