IPv6 cez tunel OpenVPN: priechod domácim routerom

Notebook má adresu IPv6, tunel beží cez IPv4, a napriek tomu každý test IPv6 zlyhá. Alebo horšie: test prejde a prevádzka vyšla cestou poskytovateľa bez toho, aby kedy vstúpila do tunela. Oba výsledky vedú k jednému chýbajúcemu rozhodnutiu: nikto nedal routeru prefix, ktorý by mohol smerovať ku klientom. Prejdenie cesty od klienta von nájde, ktorá časť chýba.

Začnite tam, kde sedí klient

Pozrite sa na klienta, skôr než sa dotknete servera. ip -6 addr by mal ukázať adresu tunela z poolu a ip -6 route by mal ukázať pretlačený prefix ukazujúci na tunelové zariadenie. Keď adresa je a cesta nie, push chýba alebo ho klient ignoroval. Keď nie je ani jedno, server nepridelil vôbec nič.

Potom skontrolujte, čo si klient myslí o vonkajšom svete. Predvolená cesta tunelom si nárokuje všetku prevádzku IPv6, zatiaľ čo cesta pre 2000::/3 si nárokuje len globálny unicast. Obe môžu byť správne a odpovedajú na rôzne otázky o úniku.

Klient bez akejkoľvek predvolenej cesty IPv6 zlyhá v každom verejnom teste, hoci tunel sám je úplne zdravý. To je medzera v politike, nie pokazený tunel.

Skontrolujte pool, ktorý server naozaj dokáže smerovať

Server môže prideľovať len z prefixu, ktorý naozaj ovláda. Ak poskytovateľ deleguje /56, rezervujte jeden /64 pre tunel a zvyšok nechajte pre LAN. Tam, kde poskytovateľ odovzdá na WAN len jeden /64 a nič ďalšie nesmeruje, nechajte prefix LAN na pokoji a dajte tunelu jedinečný lokálny rozsah, pričom prijmite, že klienti nebudú mať globálny výstup.

Pool a push patria k sebe. server-ipv6 2001:db8:80:10::/64 prideľuje adresy a push "route-ipv6 2000::/3" hovorí klientom, čo majú posielať do tunela. Pretlačenie 2000::/3 pokrýva globálny unicast a necháva rozsahy link-local a multicast mimo tunela.

Zapíšte zvolený prefix do záznamu o nasadení. Kto nabudúce zmení odovzdanie od poskytovateľa, musí vedieť, ktorý /64 tunel už zaberá.

Zapnite preposielanie pre druhú rodinu

Preposielanie IPv4 neznamená preposielanie IPv6. Nastavte net.ipv6.conf.all.forwarding=1 a zrkadlite všetko, čo politika FORWARD pre IPv4 už dovoľuje. Na routeri, ktorého reťaz FORWARD predvolene zahadzuje, vyzerá chýbajúca sada pravidiel presne ako mŕtvy tunel.

Handshake prebehne, klient dostane adresu a späť neprichádza nič. Pridajte pravidlá pre oba smery a pre vetvu WAN, pretože tunel, ktorý dosiahne LAN, ale nie internet, zlyhá v treťom teste. Po neúspešnom pokuse sa pozrite na počítadlá reťaze, pretože pravidlo, ktoré nikdy neodpovedalo, je iný problém ako to, ktoré odpovedalo 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 vedľajší efekt chytí ľudí, ktorí nakoniec vinia tunel. Zapnutie preposielania spôsobí, že jadro vynechá konfiguráciu adresy cez Router Advertisement, ak mu nepoviete inak, a predvolená cesta takto naučená s ňou zmizne. Buď pripnite výslovnú predvolenú cestu na rozhraní WAN, alebo tam vedome nastavte accept_ra na 2. Po ktorejkoľvek zmene potvrďte, že router má ešte použiteľnú cestu IPv6 von, skôr než znova otestujete klientov.

Odpovedzte na objavovanie susedov, keď horná strana nesmeruje

Zariadenia vyššie v sieti niekedy považujú delegovaný /64 za súčasť svojho vlastného spoja a odmietajú smerovať akýkoľvek podprefix do VPN boxu. Keď sa to stane, niečo musí odpovedať na žiadosti susedov pre každú klientsku adresu jednotlivo.

OpenVPN vystavuje pridelenú adresu háku client-connect, takže záznamy môžu nasledovať skutočný pool namiesto ručne udržiavaného zoznamu. Hák pridá ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 a zodpovedajúci hák client-disconnect ho odoberie. Bez odobratia tabuľka proxy zostarne a neskorší klient môže zdediť záznam pre adresu, ktorú nikdy nedostal. Stav potvrďte pomocou ip -6 neigh show proxy.

Berte proxying ako obchádzku. Statická cesta pre /64 tunela namierená na router prežije zmeny klientov a nepotrebuje žiadny privilegovaný shellový hák.

Sledujte cestu von, skok za skokom

Testujte von v troch krokoch: najprv adresa tunela routera, potom hostiteľ v LAN a tretie verejný cieľ cez traceroute6. Pool dokazuje prvý, preposielanie a firewall LAN druhý a spiatočnú cestu cez hornú stranu tretí. Každé zlyhanie zúži hľadanie na jedno zariadenie namiesto opätovného otvorenia celého návrhu.

Sledujte MTU tunela, pretože routery IPv6 na ceste za vás fragmentovať nebudú. Príliš veľké MTU sa prejaví ako chyba packet-too-big a zaseknutý TLS, nie ako čisté zlyhanie. Nastavte ho výslovne a testujte s užitočným zaťažením blízko limitu.