Má provoz IPv6 procházet přes VPN, nebo přímo?

Dva lidé mě minulý měsíc žádali o opačné výsledky: jeden chtěl, aby VPN pokrývala IPv6, druhý chtěl, aby kancelářská tiskárna dál fungovala. Jediná trasa ::/0 nemůže obojí zajistit sama. Zda tato trasa patří dovnitř tunelu, závisí na třech podmínkách a první z nich ji vylučuje u většiny komerčních výstupů. Pokud výstup nenese IPv6, přesměrování výchozí trasy do něj skryje váš provoz v tunelu, který nemá kam ho poslat.

Odpověď určují tři podmínky

Výchozí trasa je jeden řádek, ::/0, a odpovídá každému cíli IPv6 bez konkrétnější trasy (RFC 4291). Nainstalovat ji je snadné. Rozhodnutí, zda byste měli, se zužuje na tři podmínky.

Podmínka jedna: výstup, ke kterému se připojujete, má funkční IPv6 a je ochoten ho předávat. Podmínka dvě: váš klient si udrží cestu ke koncovému bodu tunelu, který obvykle leží v rozsahu, který se chystáte směrovat. Podmínka tři: dokážete pojmenovat lokální cíle IPv6, které musí zůstat mimo tunel.

Každá podmínka selhává po svém, a proto hádání stojí celý večer. Selhaná první podmínka vám dá ticho a směrovací tabulku, která vypadá správně. Selhaná druhá podmínka zabije handshake několik sekund po začátku. Selhaná třetí podmínka nechá funkční tunel a nespokojeného kolegu u tiskárny.

Nese výstup opravdu IPv6?

Rozhraní tunelu s adresou IPv6 nic nedokazuje o druhé straně. Mnoho komerčních profilů je uvnitř jen IPv4: server vám dá adresu v4 a všechno ostatní zahodí. Nainstalujte nad to výchozí trasu z AllowedIPs a jádro s radostí pošle IPv6 do rozhraní, jehož protějšek ho nikdy nevidí.

Testujte z klienta, dokud je tunel nahoře. ping -6 -c 3 2001:4860:4860::8888 a ip -6 route get 2001:4860:4860::8888 odpovídají na různé otázky: zda se vrací odpověď a které zařízení jádro zvolilo. Když druhé jmenuje váš tunel a první nic nevrátí, problém je ve výstupu, ne v trase.

Pokud výstup spravujete sami, test klienta může projít a cesta přesto skončí ve slepé uličce. Potvrďte net.ipv6.conf.all.forwarding=1 na bráně a že její firewall přijímá pakety předávané z tunelu. Správně směrovaný paket do výstupu, který odmítá předávat, vypadá z pohledu klienta přesně jako chyba směrování.

Dokáže klient udržet cestu ke koncovému bodu?

Tohle mě chytilo na notebooku s koncovým bodem WireGuard jen na IPv6. Adresa koncového bodu je běžná globální adresa, takže spadá do ::/0. Nasměrujte celý prefix do rozhraní a pakety handshaku budou honit samy sebe do tunelu, který se teprve snaží postavit. Tunel nikdy nenaběhne a nic ve výstupu klienta neřekne proč.

wg-quick to na Linuxu řeší. Odvozuje trasy z AllowedIPs, instaluje je do své tabulky a přidá pravidlo zásad, aby se provoz ke koncovému bodu nejprve vyřešil přes hlavní tabulku: pravidlo suppress_prefixlength 0, které najdete v ip -6 rule. Proto wg-quick up uspěje tam, kde ručně napsaná ip -6 route add default dev wg0 přeruší spojení.

Zkontrolujte oba stavy pomocí ip -6 route get <endpoint-v6>, před zvednutím tunelu a po něm. Pokud se odpověď změní na vaše tunelové zařízení, odstranili jste cestu, kterou tunel potřebuje. Když trasy píšete sami, přidejte hostitelskou trasu ke koncovému bodu přes původní bránu, nebo se ke koncovému bodu připojte přes IPv4 a IPv6 nechte nákladu.

Co musí zůstat mimo tunel?

Konkrétnější trasy porážejí výchozí, takže prefix na lince nebo rozsah ULA s vlastní trasou funguje dál bez dalšího úsilí. To je tichý důvod, proč tolik plnotunelových nastavení IPv4 přežívá: prefixy LAN jsou konkrétnější než výchozí a nikdy do tunelu nevstoupí.

Rozbije se to, když je lokální zařízení dostupné přes globální adresu, což je normální pro tiskárnu, které stejný router přidělil veřejný prefix, NAS nebo televizi. Tyto adresy odpovídají ::/0 a ničemu jinému, takže se přesunou do tunelu se vším ostatním a zmizí.

Rozhodujte podle cíle, ne podle protokolu. Pokud záleží na dvou nebo třech lokálních hostitelích, dejte jejich prefixům trasu ven fyzickým rozhraním, nebo je vyřaďte z vyjednané sady. Pokud seznam dál roste, poctivá odpověď je split tunneling pro IPv6 s psaným seznamem výjimek, ne výchozí trasa, kterou pořád záplatujete.

Pokud je odpověď ne, zablokujte to

Nechat IPv6 bez trasy není totéž jako nechat ho na pokoji. Hostitel s funkční výchozí trasou IPv6 ji dál používá, zatímco tunel nese IPv4, takže provoz odchází vedle VPN a každá služba, která preferuje IPv6, vidí vaši skutečnou adresu. To je únik, ne split tunel.

Vyberte jednu a napište, kterou jste vybrali. Směrujte výchozí trasu a přijměte kompromisy výše, nebo vypněte IPv6 po dobu trvání tunelu. Vynechat prefix z AllowedIPs samo o sobě nestačí, protože operační systém si drží svou vlastní výchozí trasu. Na Linuxu je hrubá verze sysctl -w net.ipv6.conf.all.disable_ipv6=1; jemnější verze shodí IPv6 mimo tunel pravidlem firewallu. Telefonní klienti mají výslovný přepínač blokování IPv6, který dělá totéž.

Ověřte to jako únik

Zvedněte tunel a čtěte stav, místo abyste věřili přepínači. ip -6 route show default by měl ukázat jednu výchozí trasu a ip -6 route get pro cíl mimo vaši LAN by měl jmenovat tunelové zařízení. Obojí zopakujte po odpojení: výchozí trasa, která přežije tunel, je chyba, kterou jste hledali.

Pak otestujte opačný směr. Z hostitele v lokální síti se dostanete ke klientovi na jeho lokální adrese IPv6. Pokud to přestane fungovat, podmínka tři nebyla nikdy splněna, ať tehdy směrovací tabulka tvrdila cokoli.

Výsledek napište tam, kde ho najde další člověk: které prefixy zůstávají lokální, proč a co klient dělá po odpojení. Dva řádky v runbooku ušetří dalšímu inženýrovi znovuobjevení smyčky koncového bodu o půlnoci.