Má prevádzka IPv6 prechádzať cez VPN, alebo priamo?

Minulý mesiac ma dvaja ľudia požiadali o opačné výsledky: jeden chcel, aby VPN pokrývala IPv6, druhý chcel, aby kancelárska tlačiareň ďalej fungovala. Jedna trasa ::/0 nemôže oboje zabezpečiť sama. Či táto trasa patrí dovnútra tunela, závisí od troch podmienok, a prvá ju vylučuje pre väčšinu komerčných výstupov. Ak výstup nenesie IPv6, smerovanie predvolenej trasy doň skryje váš tok v tuneli, ktorý nemá kam ho poslať.

Odpoveď určujú tri podmienky

Predvolená trasa je jeden riadok, ::/0, a zodpovedá každému cieľu IPv6 bez konkrétnejšej trasy (RFC 4291). Nainštalovať ju je jednoduché. Rozhodnutie, či by ste mali, sa zužuje na tri podmienky.

Podmienka jedna: výstup, ku ktorému sa pripájate, má funkčné IPv6 a je ochotný ho preposielať. Podmienka dva: váš klient si udrží cestu ku koncovému bodu tunela, ktorý zvyčajne leží v rozsahu, ktorý sa chystáte smerovať. Podmienka tri: dokážete pomenovať lokálne ciele IPv6, ktoré musia zostať mimo tunela.

Každá podmienka zlyháva po svojom, a preto hádanie stojí celý večer. Zlyhaná prvá podmienka vám dá ticho a smerovaciu tabuľku, ktorá vyzerá správne. Zlyhaná druhá podmienka zabije handshake niekoľko sekúnd po začiatku. Zlyhaná tretia podmienka nechá fungujúci tunel a nespokojného kolegu pri tlačiarni.

Nesie výstup naozaj IPv6?

Rozhranie tunela s adresou IPv6 nič nedokazuje o druhej strane. Mnohé komerčné profily sú vnútri iba IPv4: server vám dá adresu v4 a všetko ostatné zahodí. Nainštalujte nad to predvolenú trasu z AllowedIPs a jadro s radosťou pošle IPv6 do rozhrania, ktorého partner ho nikdy nevidí.

Testujte z klienta, kým je tunel hore. ping -6 -c 3 2001:4860:4860::8888 a ip -6 route get 2001:4860:4860::8888 odpovedajú na rôzne otázky: či sa vracia odpoveď a ktoré zariadenie jadro vybralo. Keď druhé pomenuje váš tunel a prvé nič nevráti, problém je vo výstupe, nie v trase.

Ak výstup spravujete sami, test klienta môže prejsť a cesta aj tak skončí v slepej uličke. Potvrďte net.ipv6.conf.all.forwarding=1 na bráne a že jej firewall prijíma pakety preposielané z tunela. Správne smerovaný paket do výstupu, ktorý odmieta preposielať, vyzerá z pohľadu klienta presne ako chyba smerovania.

Dokáže klient udržať cestu ku koncovému bodu?

Toto je prípad, ktorý ma chytil na notebooku s koncovým bodom WireGuard iba IPv6. Adresa koncového bodu je bežná globálna adresa, takže spadá do ::/0. Nasmerujte celý prefix do rozhrania a pakety handshake budú naháňať samy seba do tunela, ktorý sa ešte snažia postaviť. Tunel nikdy nenabehne a nič vo výstupe klienta nepovie prečo.

wg-quick to rieši na Linuxe. Odvodzuje trasy z AllowedIPs, inštaluje ich do svojej tabuľky a pridá pravidlo zásad, aby sa tok ku koncovému bodu najprv vyriešil cez hlavnú tabuľku: pravidlo suppress_prefixlength 0, ktoré nájdete v ip -6 rule. Preto wg-quick up uspeje tam, kde ručne napísaná ip -6 route add default dev wg0 preruší spojenie.

Skontrolujte oba stavy pomocou ip -6 route get <endpoint-v6>, pred zdvihnutím tunela a po ňom. Ak sa odpoveď zmení na vaše tunelové zariadenie, odstránili ste cestu, ktorú tunel potrebuje. Keď trasy píšete sami, pridajte hostiteľskú trasu ku koncovému bodu cez pôvodnú bránu, alebo sa pripojte ku koncovému bodu cez IPv4 a IPv6 nechajte nákladu.

Čo musí zostať mimo tunela?

Konkrétnejšie trasy porážajú predvolenú, takže prefix na prepojení alebo rozsah ULA s vlastnou trasou funguje ďalej bez ďalšieho úsilia. Toto je tichý dôvod, prečo toľko plnotunelových nastavení IPv4 prežíva: prefixy LAN sú konkrétnejšie ako predvolená trasa a nikdy nevstúpia do tunela.

Rozbije sa to, keď je lokálne zariadenie dostupné cez globálnu adresu, čo je normálne pre tlačiareň, ktorej ten istý router pridelil verejný prefix, NAS alebo televízor. Tieto adresy zodpovedajú ::/0 a ničomu inému, takže sa presunú do tunela so všetkým ostatným a zmiznú.

Rozhodujte podľa cieľa, nie podľa protokolu. Ak záleží na dvoch alebo troch lokálnych hostiteľoch, dajte ich prefixom trasu von fyzickým rozhraním, alebo ich vyraďte z vyjednaného súboru. Ak zoznam ďalej rastie, poctivá odpoveď je split tunneling pre IPv6 s písomným zoznamom výnimiek, nie predvolená trasa, ktorú stále záplatujete.

Ak je odpoveď nie, zablokujte to

Nechať IPv6 bez trasy nie je to isté ako nechať ho na pokoji. Hostiteľ s funkčnou predvolenou trasou IPv6 ju ďalej používa, kým tunel nesie IPv4, takže tok odchádza vedľa VPN a každá služba, ktorá preferuje IPv6, vidí vašu skutočnú adresu. To je únik, nie rozdelený tunel.

Vyberte jednu a napíšte, ktorú ste vybrali. Smerujte predvolenú a prijmite kompromisy vyššie, alebo vypnite IPv6 na čas trvania tunela. Vynechať prefix z AllowedIPs samo o sebe nestačí, pretože operačný systém si drží vlastnú predvolenú trasu. Na Linuxe je hrubá verzia sysctl -w net.ipv6.conf.all.disable_ipv6=1; jemnejšia verzia zhodí IPv6 mimo tunela pravidlom firewallu. Telefónni klienti majú výslovný prepínač blokovania IPv6, ktorý robí to isté.

Overte to ako únik

Zdvihnite tunel a čítajte stav, namiesto toho, aby ste verili prepínaču. ip -6 route show default by mal ukázať jednu predvolenú trasu a ip -6 route get pre cieľ mimo vašej LAN by mal pomenovať tunelové zariadenie. Zopakujte oboje po odpojení: predvolená trasa, ktorá prežije tunel, je chyba, ktorú ste hľadali.

Potom otestujte opačný smer. Z hostiteľa v lokálnej sieti sa dostanete ku klientovi na jeho lokálnej adrese IPv6. Ak to prestane fungovať, podmienka tri nikdy nebola splnená, čokoľvek vtedy tvrdila smerovacia tabuľka.

Výsledok napíšte tam, kde ho nájde ďalší človek: ktoré prefixy zostávajú lokálne, prečo a čo klient robí po odpojení. Dva riadky v runbooku ušetria ďalšiemu inžinierovi znovuobjavenie slučky koncového bodu o polnoci.