IPv6 gjennom en OpenVPN-tunnel: en gjennomgang av hjemmeruteren

Den bærbare maskinen har en IPv6-adresse, tunnelen er oppe over IPv4, og likevel feiler hver IPv6-test. Eller verre: testen lykkes, og trafikken forlot leverandørens vei uten å noen gang komme inn i tunnelen. Begge utfallene går tilbake til én manglende beslutning: ingen ga ruteren et prefiks den kunne rute mot klientene. Å gå veien fra klienten og utover finner hvilken bit som mangler.

Start der klienten sitter

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 prefikset som peker på tunnelenheten. Når adressen er der men ruten ikke, mangler pushet eller klienten ignorerte det. Når ingen av dem er der, har serveren ikke tildelt noe som helst.

Sjekk deretter hva klienten tror om omverdenen. En standardrute over tunnelen krever all IPv6-trafikk, mens en rute for 2000::/3 bare krever global unicast. Begge kan være riktige, og de svarer på forskjellige spørsmål om lekkasje.

En klient uten noen IPv6-standardrute feiler på hver offentlig test selv om tunnelen selv er helt sunn. Det er et hull i policyen, ikke en ødelagt tunnel.

Sjekk poolen serveren faktisk kan rute

En server kan bare tildele fra et prefiks den faktisk kontrollerer. Hvis leverandøren delegerer et /56, reserver ett /64 til tunnelen og la resten være til LAN. Der leverandøren bare overleverer ett /64 på WAN og ikke ruter noe mer, la LAN-prefikset være i fred og gi tunnelen et unikt lokalt område, mens du godtar at klientene ikke får noen global utgang.

Poolen og pushet hører sammen. server-ipv6 2001:db8:80:10::/64 tildeler adresser, og push "route-ipv6 2000::/3" forteller klientene hva de skal sende inn i tunnelen. Å pushe 2000::/3 dekker global unicast og holder link-local- og multicast-områder utenfor tunnelen.

Skriv det valgte prefikset i utrullingsprotokollen. Den som neste gang endrer leverandørens overlevering, må vite hvilket /64 tunnelen allerede opptar.

Slå på videresending for den andre familien

IPv4-videresending betyr ikke IPv6-videresending. Sett net.ipv6.conf.all.forwarding=1 og speil alt IPv4-FORWARD-policyen allerede tillater. På en ruter der FORWARD-kjeden dropper som standard, ser et manglende regelsett nøyaktig ut som en død tunnel.

Håndtrykket lykkes, klienten får en adresse, og ingenting kommer tilbake. Legg til regler for begge retninger og for WAN-beinet, fordi en tunnel som når LAN men ikke internett, feiler på den tredje testen. Etter et mislykket forsøk, se på kjedes tellere, fordi en regel som aldri traff, er et annet problem enn en som traff og droppet.

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 som til slutt gir tunnelen skylden. Når videresending slås på, hopper kjernen over adressekonfigurasjon via Router Advertisement med mindre du sier noe annet, og en standardrute lært slik forsvinner med den. Enten fest en eksplisitt standardrute på WAN-grensesnittet, eller sett accept_ra bevisst til 2 der. Etter hver endring, bekreft at ruteren fortsatt har en brukbar IPv6-vei ut før du tester klientene igjen.

Svar på nabo-oppdagelse når oppstrøms ikke ruter

Utstyr oppstrøms behandler noen ganger det delegerte /64 som om det tilhører sin egen lenke og nekter å rute noe underprefiks til VPN-boksen. Når det skjer, må noe svare på nabo-forespørsler for hver klientadresse individuelt.

OpenVPN eksponerer den tildelte adressen til en client-connect-krok, slik at oppføringer kan følge den ekte poolen i stedet for en liste som holdes for hånd. Kroken legger til ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, og en tilsvarende client-disconnect-krok fjerner den. Uten fjerningen blir proxy-tabellen utdatert, og en senere klient kan arve en oppføring for en adresse den aldri fikk. Bekreft tilstanden med ip -6 neigh show proxy.

Behandle proxy som en nødløsning. En statisk rute for tunnelens /64 rettet mot ruteren overlever klientutskiftninger og trenger ikke noen privilegert shell-krok i det hele tatt.

Følg veien utover, hopp for hopp

Test utover i tre trinn: først ruterens tunneladresse, deretter en LAN-vert og tredje et offentlig mål via traceroute6. Poolen bevises av det første, videresendingen og LAN-brannmuren av det andre, og returveien via oppstrøms av det tredje. Hver feil innsnevrer søket til én enhet i stedet for å åpne hele designet på nytt.

Følg med på tunnelens MTU, fordi IPv6-ruterne på veien ikke fragmenterer for deg. En for stor MTU viser seg som en packet-too-big-feil og fastlåst TLS i stedet for en ren feil. Sett den eksplisitt og test med en nyttelast nær grensen.