IPv6 gjennom ein OpenVPN-tunnel: ein gjennomgang av heimerutaren

Den berebære maskina har ein IPv6-adresse, tunnelen er oppe over IPv4, og likevel feilar kvar IPv6-test. Eller verre: testen lukkast, og trafikken forlét vegen til leverandøren utan å nokon gong kome inn i tunnelen. Begge utfalla går tilbake til éi manglande avgjerd: ingen gav rutaren eit prefiks han kunne rute mot klientane. Å gå vegen frå klienten og utover finn kva bit som manglar.

Byrja der klienten sit

Sjå på klienten før du rører serveren. ip -6 addr bør vise ei tunneladresse frå poolen, og ip -6 route bør vise det pusja prefikset som peikar på tunneleininga. Når adressa er der men ruta ikkje, manglar pusjet eller klienten ignorerte det. Når ingen av dei er der, har serveren ikkje tildelt noko som helst.

Sjekk deretter kva klienten trur om omverda. Ei standardrute over tunnelen krev all IPv6-trafikk, medan ei rute for 2000::/3 berre krev global unicast. Begge kan vere rette, og dei svarar på ulike spørsmål om lekkasje.

Ein klient utan noka IPv6-standardrute feilar på kvar offentleg test sjølv om tunnelen sjølv er heilt sunn. Det er eit hol i policyen, ikkje ein øydelagd tunnel.

Sjekk poolen serveren faktisk kan rute

Ein server kan berre tildele frå eit prefiks han faktisk kontrollerer. Viss leverandøren delegerer eit /56, reserver eitt /64 til tunnelen og lat resten vere til LAN. Der leverandøren berre overleverer eitt /64 på WAN og ikkje rutar noko meir, lat LAN-prefikset vere i fred og gje tunnelen eit unikt lokalt område, medan du godtek at klientane ikkje får nokon global utgang.

Poolen og pusjet høyrer saman. server-ipv6 2001:db8:80:10::/64 tildeler adresser, og push "route-ipv6 2000::/3" fortel klientane kva dei skal sende inn i tunnelen. Å pusje 2000::/3 dekkjer global unicast og held link-local- og multicast-område utanfor tunnelen.

Skriv det valde prefikset i utrullingsprotokollen. Den som neste gong endrar overleveringa frå leverandøren, må vite kva /64 tunnelen alt opptek.

Slå på videresending for den andre familien

IPv4-videresending betyr ikkje IPv6-videresending. Set net.ipv6.conf.all.forwarding=1 og spegl alt IPv4-FORWARD-policyen alt tillèt. På ein ruter der FORWARD-kjeda droppar som standard, ser eit manglande regelsett nøyaktig ut som ein død tunnel.

Handtrykket lukkast, klienten får ei adresse, og ingenting kjem tilbake. Legg til reglar for begge retningar og for WAN-beinet, fordi ein tunnel som når LAN men ikkje internett, feilar på den tredje testen. Etter eit mislukka forsøk, sjå på teljarane i kjeda, fordi ein regel som aldri traff, er eit anna problem enn ein som traff og droppa.

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

Ein biverknad fangar dei som til slutt gir tunnelen skulda. Når videresending blir slått på, hoppar kjernen over adressekonfigurasjon via Router Advertisement med mindre du seier noko anna, og ei standardrute lært slik forsvinn med henne. Anten fest ei eksplisitt standardrute på WAN-grensesnittet, eller set accept_ra medvite til 2 der. Etter kvar endring, stadfest at rutaren framleis har ein brukbar IPv6-veg ut før du testar klientane igjen.

Svar på nabo-oppdaging når oppstraums ikkje rutar

Utstyr oppstraums handsamar nokre gonger det delegerte /64 som om det høyrer til si eiga lenkje og nektar å rute noko underprefiks til VPN-boksen. Når det skjer, må noko svare på nabo-førespurnader for kvar klientadresse individuelt.

OpenVPN eksponerer den tildelte adressa til ein client-connect-krok, slik at oppføringar kan følgje den ekte poolen i staden for ei liste som blir halden for hand. Kroken legg til ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, og ein tilsvarande client-disconnect-krok fjernar han. Utan fjerninga blir proxy-tabellen utdatert, og ein seinare klient kan arve ei oppføring for ei adresse han aldri fekk. Stadfest tilstanden med ip -6 neigh show proxy.

Handsam proxy som ei naudløysing. Ei statisk rute for tunnelens /64 retta mot rutaren overlever klientutskiftingar og treng ikkje nokon privilegert shell-krok i det heile.

Følg vegen utover, hopp for hopp

Test utover i tre trinn: først tunneladressa til rutaren, deretter ein LAN-vert og tredje eit offentleg mål via traceroute6. Poolen blir prova av det første, videresendinga og LAN-brannmuren av det andre, og returvegen via oppstraums av det tredje. Kvar feil snevrar søket inn til éi eining i staden for å opne heile designet på nytt.

Følg med på MTU-en til tunnelen, fordi IPv6-rutarane på vegen ikkje fragmenterer for deg. Ein for stor MTU viser seg som ein packet-too-big-feil og fastlåst TLS i staden for ein rein feil. Set han eksplisitt og test med ei nyttelast nær grensa.