Rute IPv6 mellom to steder over et eksisterende VPN

Et WAN med bare IPv4 kan fortsatt bære indre IPv6. Følg selektorer, kjerneruter, videresending og returprefikset som stille slipper svar.

Når du legger til et IPv6-prefiks i en site-til-site-tunnel, reiser pakken ikke slik diagrammet antyder. Den lokale gatewayen tar hele IPv6-pakken, krypterer den og setter en ytre IP-header foran, der adresserfamilien bestemmes av endepunktsadressene, ikke av hva som er inni. Den fjerne gatewayen fjerner den ytre headeren og videresender den opprinnelige pakken til sitt LAN, der den igjen er en vanlig IPv6-pakke. Ytre tunnel og indre trafikk er to separate samtaler som deler en nøkkel, et endepunktspar og ingenting annet.

To headere, to adresserfamilier

I IPsec-tunnelmodus blir den indre IPv6-pakken nyttelasten bak en ESP-header. Den ytre headeren som bærer den ESP-pakken, kan være IPv4 eller IPv6, og den følger local_addrs og remote_addrs. WireGuard gjør det samme med mindre seremoni: den indre pakken er nyttelasten i et UDP-datagram til peerens endepunkt. Begge lar den indre headeren være urørt, og det er derfor den andre siden kan rute den etter dekapsulering.

Veien mellom stedene ser bare UDP 4500 når IPsec bruker NAT-traversal, eller UDP 51820 for en standard WireGuard-lytter. Enhver ruter underveis kan bare IPv4, og IPv6-trafikken krysser likevel, fordi den aldri opptrer som en IPv6-pakke på den veien. Det gir en ren første todeling: tcpdump -ni eth0 udp port 51820 viser den krypterte veien, tcpdump -ni wg0 ip6 viser den indre trafikken. En travel ytre fangst med en stille indre betyr at kjernen ikke legger IPv6 i tunnelen; det er ruting eller policy, ikke lenketilstand.

Gatewayen reduserer også den indre Hop Limit når den videresender, så endepunktene teller som rutere på IPv6-veien. Ytre hoppantall og indre Hop Limit beveger seg uavhengig, og en pakke som dør ved den fjerne gatewayen, døde i videresendingen, ikke i krypteringen.

Selektorer og AllowedIPs er tillatelseslisten

IKEv2 forhandler hvilke indre prefikser en child-SA kan bære. På strongSwan 5.9 og nyere ser det slik ut når man skriver dem ut i swanctl.conf:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

Utelat local_ts og remote_ts, og strongSwan utleder dem fra subnettene til grensesnittet den velger. På en dual-stack-vert gir den snarveien ofte et par med bare IPv4: SA-en kommer opp, og IPv6 avvises før det når ESP-koden. Å skrive ut begge prefiksene gjør SA-en kvalifisert til å bære dem, og start_action = trap bringer den opp ved den første passende pakken.

WireGuard har én liste som gjør to jobber. I peer-blokken er AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 både ruten som installeres ved sending og filteret som brukes ved mottak: en dekryptert pakke hvis indre kilde faller utenfor peerens liste, slippes stille. wg-quick legger til en rute per oppføring, så peer-blokken nedenfor trenger ingen egen ip -6 route-kommando.

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

Begge listene må speiles: sted B godtar prefikset til sted A som ekstern selektor og ruter det tilbake, og tunnelen virker bare når de to retningene er enige. En asymmetrisk liste gir symptomet som koster mest tid — et sunt håndtrykk, tellere som beveger seg på én side, og en ping fra A til B som lykkes mens ingenting fra B når A.

Videresending, ruter og returprefikset

Linux videresender ikke IPv6 før du sier det, og innstillingen gjelder per namespace og ikke per grensesnitt:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

Den andre linjen er den folk glemmer i rutebaserte oppsett. Policybasert IPsec installerer en XFRM-policy som matcher prefiksene, men et rutebasert oppsett med vti6 eller WireGuard trenger en faktisk IPv6-rute som peker på den enheten. Gjør sysctl-en varig under /etc/sysctl.d/; ellers setter en omstart stille videresendingen tilbake til av.

Videresending har en bivirkning verd å kjenne: kjernen ignorerer da router advertisements med mindre net.ipv6.conf.<wan>.accept_ra er 2, så en gateway hvis WAN-adresse kommer via SLAAC kan miste standardruten i det øyeblikket du slår på videresending. Sett accept_ra = 2 på det grensesnittet i samme fil, og ruten overlever. Kjernen på sted B må også lære 2001:db8:aa::/48 fra tunnelgatewayen, via en statisk rute eller en rutingsprotokoll over tunnelen, ellers dør svaret i nettverket til B.

En firetrinns kontroll som lokaliserer bruddet

Arbeid i denne rekkefølgen og stopp ved første trinn som feiler, fordi hvert senere trinn avhenger av de tidligere.

  1. Selektorer: swanctl --list-sas bør vise IPv6-prefiksparet på child-SA-en, eller wg show wg0 allowed-ips det eksterne prefikset med en fersk latest-handshakes.
  2. Kjernerute: ip -6 route get 2001:db8:bb::10 må svare med tunnel-enheten, ikke WAN-grensesnittet.
  3. Indre fangst: tcpdump -ni wg0 ip6 mens du pinger mellom ekte LAN-verter. Pakker som går ut men ingen som kommer tilbake, peker på ruta eller brannmuren til B; ingen pakker i det hele tatt peker tilbake på trinn 1 eller 2.
  4. Destinasjon: på B-verten bekrefter ss -6 -ltn at tjenesten lytter på IPv6, og de lokale brannmur-tellerne viser om pakken ble godtatt eller sluppet.

MTU hører til i samme gjennomgang. IPv6-rutere fragmenterer ikke, så en for stor pakke slippes og Packet Too Big kommer tilbake til avsenderen. Hvis håndtrykk og små ping fungerer, men en filoverføring stopper, krymp nyttelasten til den passerer: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard-grensesnitt har som standard 1420 byte MTU, og IPsec over IPv4 trekker av mer, så det er bedre å sette den indre MTU-en enn å håpe på path-MTU-oppdagelse gjennom en brannmur som slipper ICMPv6.

Feilmoduser som ser ut som brannmurproblemer

Den vanligste er ikke en brannmur i det hele tatt: tjenesten binder til 0.0.0.0 i stedet for ::, AAAA-posten finnes, og klienten får en rask avvisning over IPv6 som en dual-stack-nettleser skjuler ved å falle tilbake til IPv4. Hvis bare noen programmer feiler, sjekk den lyttende familien før du rører et regelverk.

Den andre er ICMPv6-filtrering. Neighbor Discovery og Packet Too Big er en del av normal drift, ikke diagnostikk, og en policy som slipper all ICMPv6 gir en tunnel som kobler til, autentiserer og deretter stopper på alt større enn en liten pakke. Tillat typene veien avhenger av, og la tellerne stå på så en dropp er synlig.

Den tredje er et prefiks som legges til tunnelen men aldri til adresseplanen for stedet som eier det, så ingen ruter annonserer det og ingen vert kan svare fra det. Start med ett prefiks og ett vertspar, bevis begge retninger med de fire trinnene, og legg til resten etterpå; et defekt prefiks blir stående som én linje i en konfigurasjon i stedet for en ombygging. Den ene offisielle referansen det er verdt å holde åpen, er RFC 8200, som definerer headeren tunnelen bærer.

Relaterte artikler