IPv6 gennem en OpenVPN-tunnel: en gennemgang for hjemmeruteren

Bærbaren har en IPv6-adresse, tunnelen er oppe over IPv4, og alligevel fejler hver IPv6-test. Eller værre: testen lykkes, og trafikken forlod udbyderens vej uden nogensinde at komme ind i tunnelen. Begge udfald går tilbage til én manglende beslutning: ingen gav ruteren et præfiks, den kunne route mod klienterne. At gå vejen fra klienten og udad finder, hvilken brik der mangler.

Start hvor klienten sidder

Se på klienten, før du rører serveren. ip -6 addr bør vise en tunneladresse fra poolen, og ip -6 route bør vise det pushede præfiks, der peger på tunnel-enheden. Når adressen er der, men ruten ikke, mangler pushet, eller klienten ignorerede det. Når ingen af dem er der, har serveren slet ikke tildelt noget.

Kontroller derefter, hvad klienten tror om omverdenen. En standardrute over tunnelen kræver al IPv6-trafik, mens en rute til 2000::/3 kun kræver global unicast. Begge kan være rigtige, og de besvarer forskellige spørgsmål om lækage.

En klient uden nogen IPv6-standardrute fejler hver offentlig test, selvom tunnelen selv er helt sund. Det er et hul i politikken, ikke en ødelagt tunnel.

Kontroller den pool, serveren faktisk kan route

En server kan kun tildele fra et præfiks, den faktisk kontrollerer. Hvis udbyderen delegerer et /56, så reserver et /64 til tunnelen og lad resten være til LAN. Hvor udbyderen kun udleverer et enkelt /64 på WAN og ikke router videre, så lad LAN-præfikset være og giv tunnelen et unikt lokalt område, idet du accepterer, at klienterne ikke får nogen global udgang.

Poolen og pushet hører sammen. server-ipv6 2001:db8:80:10::/64 tildeler adresser, og push "route-ipv6 2000::/3" fortæller klienterne, hvad de skal sende ind i tunnelen. At pushe 2000::/3 dækker global unicast og holder link-local- og multicast-områder uden for tunnelen.

Skriv det valgte præfiks i udrulningsprotokollen. Den, der næste gang ændrer udbyderens overdragelse, skal vide, hvilket /64 tunnelen allerede optager.

Slå forwarding til for den anden familie

IPv4-forwarding betyder ikke IPv6-forwarding. Sæt net.ipv6.conf.all.forwarding=1, og spejl alt, hvad IPv4-FORWARD-politikken allerede tillader. På en ruter, hvis FORWARD-kæde dropper som standard, ser et manglende regelsæt præcis ud som en død tunnel.

Håndtrykket lykkes, klienten får en adresse, og intet kommer tilbage. Tilføj regler for begge retninger og for WAN-benet, fordi en tunnel, der når LAN, men ikke internettet, fejler den tredje test. Kig på kædens tællere efter et mislykket forsøg, fordi en regel, der aldrig matchede, er et andet problem end en, der matchede og droppede.

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

En bivirkning fanger dem, der ender med at give tunnelen skylden. Når forwarding slås til, springer kernen adressekonfiguration via Router Advertisement over, medmindre du siger andet, og en standardrute lært på den måde forsvinder med den. Enten fastgør en eksplicit standardrute på WAN-interfacet, eller sæt accept_ra bevidst til 2 der. Efter hver af ændringerne skal du bekræfte, at ruteren stadig har en brugbar IPv6-vej ud, før du tester klienterne igen.

Svar på nabo-opdagelse, når opstrøms ikke router

Udstyr opstrøms behandler nogle gange det delegerede /64 som hørende til sit eget link og nægter at route et underpræfiks til VPN-boksen. Når det sker, skal noget svare på nabo-forespørgsler for hver klientadresse individuelt.

OpenVPN eksponerer den tildelte adresse til et client-connect-hook, så poster kan følge den rigtige pool i stedet for en liste, der vedligeholdes manuelt. Hooket tilføjer ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, og et matchende client-disconnect-hook fjerner det igen. Uden fjernelsen bliver proxy-tabellen forældet, og en senere klient kan arve en post for en adresse, den aldrig fik. Bekræft tilstanden med ip -6 neigh show proxy.

Betragt proxying som en nødløsning. En statisk rute til tunnelens /64 rettet mod ruteren overlever klientudskiftning og kræver slet ikke noget privilegeret shell-hook.

Følg vejen udad, hop for hop

Test udad i tre trin: først ruterens tunneladresse, derefter en LAN-vært og tredje et offentligt mål via traceroute6. Poolen bevises af det første, forwarding og LAN-firewallen af det andet, og returvejen via opstrøms af det tredje. Hver fejl indsnævrer søgningen til én enhed i stedet for at åbne hele designet igen.

Hold øje med tunnelens MTU, fordi IPv6-ruterne på vejen ikke fragmenterer for dig. En for stor MTU viser sig som en packet-too-big-fejl og fastlåst TLS i stedet for en ren fejl. Sæt den eksplicit, og test med en nyttelast tæt på grænsen.