Duálny VPN: rodinu adries vyberá klient, nie vy

Tunel beží, stránky IPv4 sa načítavajú a jedno meno hostiteľa vyprší. Okamžitý záver je, že VPN je pokazená alebo sú prihlasovacie údaje nesprávne, a zvyčajne nie je pravda ani jedno. Meno vrátilo adresu IPv4 aj IPv6, aplikácia si jednu vybrala a len jeden z týchto kandidátov mal funkčnú cestu. Rozhodnutie o výbere urobil klient; tunel jednoducho nepokrýval to, čo si vybral.

Výber nie je sľub pokrytia

Predvolený výber adresy, opísaný v RFC 6724, určuje, ktorú dvojicu zdroja a cieľa hostiteľ uprednostní, keď je k dispozícii viacero. Happy Eyeballs na to pridáva stratégiu pripojenia: spustí pokusy v oboch rodinách a ponechá ten, ktorý odpovie prvý, aby používateľ nečakal na vypršanie pokazenej rodiny.

Ani jeden mechanizmus nevytvára trasu. Ak váš tunel prenáša iba IPv4, kandidát AAAA je stále legitímny cieľ, ktorý môže klient skúsiť, a zlyhanie sa prejaví ako pomalé načítanie, nie ako chyba, pretože prehliadač sa vrátil späť. Používateľ hlási pomalú stránku, nie pokazenú, a tiket podpory dedí túto nejasnosť. Zopakujte to s pevnou rodinou a správa sa stane konkrétnou.

Práve kvôli tomuto návratu je príznak medzi aplikáciami nekonzistentný. Prehliadač oneskorenie skryje; klient príkazového riadka s pevnou rodinou vám skutočné zlyhanie ukáže okamžite.

Zistite, ktorú rodinu požiadavka skutočne použila

Začnite menom, nie tunelom. Overte oba typy záznamov a poznamenajte si, čo sa 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

Ak požiadavka v4 uspeje a požiadavka v6 zlyhá, problém ste reprodukovali v podobe, ktorú možno ladiť. Ak obe uspejú z shellu a prehliadač stále zlyháva, pozrite sa na vlastný resolver aplikácie alebo na kešovanú odpoveď, než sa tunela dotknete.

Držte rodinu aj cieľ vo svojich poznámkach. Tiket, ktorý hovorí, že sa stránka cez VPN nenačítava, nemôže nikto overiť, zatiaľ čo tiket, ktorý hovorí, že AAAA zlyháva a A funguje, ukazuje na konkrétnu trasu.

Skontrolujte trasu pre danú rodinu

Pri zlyhávajúcej rodine sa opýtajte jadra, ktorú cestu by použilo, a porovnajte ju s nakonfigurovanými adresami tunela. V Linuxe ip -6 route get pre cieľ zobrazí rozhranie a zdroj, ktoré by boli vybrané.

Potom skontrolujte samotný tunel. Peery WireGuard nesú zoznam povolených IP a záznam pre 0.0.0.0/0 nehovorí o IPv6 nič. Ak zoznam peera nemá prefix IPv6, klient nemá dôvod posielať prevádzku AAAA do tunela a paket odchádza tým, čo by hostiteľ inak urobil.

Pravidlá firewallu a politika NAT si zaslúžia rovnakú kontrolu pre každú rodinu. Pravidlo napísané pre IPv4 nepokrýva IPv6 na žiadnej platforme, a to je najčastejší dôvod, prečo jedna rodina funguje a druhá nie.

Nevypínajte IPv6, aby ste si zjednodušili snímku obrazovky

Vypnutie IPv6 v celom systéme spôsobí, že príznak zmizne, a vy zostanete bez diagnózy. Tiež pokazí každý cieľ, ktorý je iba IPv6, a skryje tú istú chybu pre ďalšiu aplikáciu. Ak stroj naozaj nemá používať IPv6, je to zámerná politika s vlastníkom a testom. Vypnutie počas incidentu nie je ani jedno z toho.

Rozhodnite, čo má klient s rodinou robiť, a explicitne to nakonfigurujte: preveďte ju tunelom, alebo ju zablokujte podporovaným spôsobom, aby výber nikdy neponúkol nedostupného kandidáta. Oba sú legitímne návrhy. Globálne vypnutie nie je ani jeden z nich, pretože to vôbec nie je návrh.

Čo uviesť v tikete

Zapíšte štyri veci: meno hostiteľa, rodinu, ktorá zlyhala, trasu, ktorú vybralo jadro, a výsledok požiadavky špecifickej pre rodinu. Táto sada stačí, aby niekto iný zlyhanie reprodukoval bez hádania, ktorú z dvoch ciest ste mysleli.

Pravidlá výberu adries RFC 6724 vysvetľujú, prečo klient uprednostnil kandidáta, ktorého uprednostnil, a RFC 8305 vysvetľuje pretekárske správanie, ktoré oneskorenie skrylo. Ani jedno z nich za vás nevytrasuje paket, a to je časť, ktorú musí urobiť tunel.