Duální VPN: rodinu adres vybírá klient, ne vy

Tunel běží, stránky IPv4 se načítají a jedno jméno hostitele vyprší. Okamžitý závěr je, že VPN je rozbitá nebo jsou přihlašovací údaje špatné, a obvykle není pravda ani jedno. Jméno vrátilo adresu IPv4 i IPv6, aplikace si jednu vybrala a jen jeden z těchto kandidátů měl funkční cestu. Rozhodnutí o výběru udělal klient; tunel prostě nepokrýval to, co si vybral.

Výběr není slib pokrytí

Výchozí výběr adresy, popsaný v RFC 6724, určuje, kterou dvojici zdroje a cíle hostitel upřednostní, když je k dispozici několik. Happy Eyeballs na to navíc přidává strategii připojení: spustí pokusy v obou rodinách a ponechá ten, který odpoví první, takže uživatel nečeká, až rozbitá rodina vyprší.

Ani jeden z mechanismů nevytváří trasu. Pokud váš tunel přenáší jen IPv4, kandidát AAAA je stále legitimní cíl, který může klient zkusit, a selhání se projeví jako pomalé načítání, nikoli jako chyba, protože prohlížeč se vrátil zpět. Uživatel hlásí pomalý web, ne rozbitý, a tiket podpory tuto vágnost zdědí. Zopakujte to s pevnou rodinou a zpráva se stane konkrétní.

Právě kvůli tomuto návratu je symptom mezi aplikacemi nekonzistentní. Prohlížeč zpoždění skryje; klient příkazové řádky s pevnou rodinou vám skutečné selhání ukáže okamžitě.

Zjistěte, kterou rodinu požadavek skutečně použil

Začněte jménem, ne tunelem. Ověřte oba typy záznamů a poznamenejte si, co se vrátilo:

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

Pokud požadavek v4 uspěje a požadavek v6 selže, problém jste reprodukovali v podobě, kterou lze ladit. Pokud oba uspějí ze shellu a prohlížeč stále selhává, podívejte se na vlastní resolver aplikace nebo na kešovanou odpověď, než se tunelu dotknete.

Držte rodinu i cíl ve svých poznámkách. Tiket, který říká, že se web přes VPN nenačítá, nemůže nikdo ověřit, zatímco tiket, který říká, že AAAA selhává a A funguje, ukazuje na konkrétní trasu.

Zkontrolujte trasu pro danou rodinu

U selhávající rodiny se zeptejte jádra, kterou cestu by použilo, a porovnejte ji s nakonfigurovanými adresami tunelu. V Linuxu ip -6 route get pro cíl zobrazí rozhraní a zdroj, které by byly vybrány.

Potom zkontrolujte samotný tunel. Peery WireGuard nesou seznam povolených IP a záznam pro 0.0.0.0/0 o IPv6 neříká nic. Pokud seznam peeru nemá prefix IPv6, klient nemá důvod posílat provoz AAAA do tunelu a paket odchází tím, co by hostitel jinak udělal.

Pravidla firewallu a politika NAT si zaslouží stejnou kontrolu pro každou rodinu. Pravidlo napsané pro IPv4 nepokrývá IPv6 na žádné platformě, a to je nejčastější důvod, proč jedna rodina funguje a druhá ne.

Nevypínejte IPv6, abyste si zjednodušili snímek obrazovky

Vypnutí IPv6 v celém systému způsobí, že symptom zmizí, a vy zůstanete bez diagnózy. Také rozbije každý cíl, který je pouze IPv6, a skryje stejnou chybu pro další aplikaci. Pokud nějaký stroj skutečně nemá IPv6 používat, je to záměrná politika s vlastníkem a testem. Vypnutí během incidentu není ani jedno z toho.

Rozhodněte, co má klient s rodinou dělat, a explicitně to nakonfigurujte: protáhněte ji tunelem, nebo ji zablokujte podporovaným způsobem, aby výběr nikdy nenabídl nedostupného kandidáta. Oba návrhy jsou legitimní. Globální vypnutí není ani jeden z nich, protože to vůbec není návrh.

Co uvést v tiketu

Zaznamenejte čtyři věci: jméno hostitele, rodinu, která selhala, trasu, kterou jádro zvolilo, a výsledek požadavku specifického pro rodinu. Tato sada stačí, aby někdo jiný selhání reprodukoval, aniž by hádal, kterou ze dvou cest jste mysleli.

Pravidla výběru adres RFC 6724 vysvětlují, proč klient upřednostnil kandidáta, kterého upřednostnil, a RFC 8305 vysvětluje závodní chování, které zpoždění skrylo. Ani jedno z nich za vás nezajistí trasu paketu, a to je část, kterou musí udělat tunel.