IPv6 přes tunel OpenVPN: průchod domácím routerem

Notebook má adresu IPv6, tunel běží přes IPv4, a přesto každý test IPv6 selže. Nebo hůř: test projde a provoz vyšel cestou poskytovatele, aniž by kdy vstoupil do tunelu. Oba výsledky vedou ke stejnému chybějícímu rozhodnutí: nikdo nedal routeru prefix, který by mohl směrovat ke klientům. Projití cesty od klienta ven najde, která část chybí.

Začněte tam, kde sedí klient

Podívejte se na klienta, než se dotknete serveru. ip -6 addr by měl ukázat adresu tunelu z poolu a ip -6 route by měl ukázat protlačený prefix ukazující na tunelové zařízení. Když adresa je a cesta ne, push chybí nebo ho klient ignoroval. Když není ani jedno, server nepřidělil vůbec nic.

Pak zkontrolujte, co si klient myslí o vnějším světě. Výchozí cesta tunelem si nárokuje veškerý provoz IPv6, zatímco cesta pro 2000::/3 si nárokuje jen globální unicast. Obojí může být správně a odpovídá na různé otázky o úniku.

Klient bez jakékoli výchozí cesty IPv6 selže v každém veřejném testu, i když je tunel sám naprosto zdravý. To je mezera v politice, ne rozbitý tunel.

Zkontrolujte pool, který server skutečně umí směrovat

Server může přidělovat jen z prefixu, který skutečně ovládá. Pokud poskytovatel deleguje /56, rezervujte jeden /64 pro tunel a zbytek nechte pro LAN. Když poskytovatel předá na WAN jen jeden /64 a nic dalšího nesměruje, nechte prefix LAN na pokoji a dejte tunelu jedinečný lokální rozsah, s tím, že klienti nebudou mít globální výstup.

Pool a push patří k sobě. server-ipv6 2001:db8:80:10::/64 přiděluje adresy a push "route-ipv6 2000::/3" říká klientům, co mají posílat do tunelu. Protlačení 2000::/3 pokrývá globální unicast a nechává rozsahy link-local a multicast mimo tunel.

Zapište zvolený prefix do záznamu o nasazení. Kdo příště změní předání od poskytovatele, musí vědět, který /64 tunel už zabírá.

Zapněte forwarding pro druhou rodinu

Forwarding IPv4 neznamená forwarding IPv6. Nastavte net.ipv6.conf.all.forwarding=1 a zrcadlete vše, co politika FORWARD pro IPv4 už dovoluje. Na routeru, jehož řetěz FORWARD ve výchozím stavu zahazuje, vypadá chybějící sada pravidel přesně jako mrtvý tunel.

Handshake projde, klient dostane adresu a zpět nepřijde nic. Přidejte pravidla pro oba směry a pro větev WAN, protože tunel, který dosáhne na LAN, ale ne na internet, selže ve třetím testu. Po neúspěšném pokusu zkontrolujte počítadla řetězu, protože pravidlo, které nikdy neodpovídalo, je jiný problém než to, které odpovědělo a zahodilo.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Jeden vedlejší efekt chytí lidi, kteří nakonec viní tunel. Zapnutím forwardingu jádro vynechá konfiguraci adresy přes Router Advertisement, pokud mu neřeknete jinak, a výchozí cesta takto naučená s ní zmizí. Buď na rozhraní WAN připněte výslovnou výchozí cestu, nebo tam vědomě nastavte accept_ra na 2. Po kterékoli změně potvrďte, že router má ještě použitelnou cestu IPv6 ven, než znovu otestujete klienty.

Odpovězte na objevování sousedů, když upstream nesměruje

Zařízení výše v síti někdy považuje delegovaný /64 za součást svého vlastního spoje a odmítá směrovat jakýkoli podprefix do VPN boxu. Když se to stane, něco musí odpovídat na žádosti sousedů pro každou klientskou adresu jednotlivě.

OpenVPN vystavuje přidělenou adresu háku client-connect, takže záznamy mohou následovat skutečný pool místo ručně udržovaného seznamu. Hák přidá ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 a odpovídající hák client-disconnect ho zase odebere. Bez odebrání tabulka proxy zestárne a pozdější klient může zdědit záznam pro adresu, kterou nikdy nedostal. Stav potvrďte pomocí ip -6 neigh show proxy.

Berte proxying jako záplatu. Statická cesta pro /64 tunelu namířená na router přežije změny klientů a nepotřebuje žádný privilegovaný shellový hák.

Sledujte cestu ven, skok za skokem

Testujte ven ve třech krocích: nejdřív adresa tunelu routeru, pak hostitel v LAN a potřetí veřejný cíl přes traceroute6. Pool dokazuje první krok, forwarding a firewall LAN druhý a zpáteční cestu přes upstream třetí. Každé selhání zúží hledání na jedno zařízení, místo aby otevřelo celý návrh znovu.

Hlídejte MTU tunelu, protože routery IPv6 na cestě za vás fragmentovat nebudou. Příliš velké MTU se projeví jako chyba packet-too-big a zaseknutý TLS, ne jako čisté selhání. Nastavte ho výslovně a testujte s užitečným zatížením blízko limitu.