Rute IPv6 mellom to stader over eit eksisterande VPN

Eit WAN med berre IPv4 kan framleis bera indre IPv6. Følg selektorar, kjernaruter, videresending og returprefikset som stille slepp svar.

Når du legg til eit IPv6-prefiks i ein stad-til-stad-tunnel, reiser pakka ikkje slik diagrammet antyder. Den lokale gatewayen tek heile IPv6-pakka, krypterer henne og set ein ytre IP-header framfor der adressefamilien blir avgjort av endepunktsadressene, ikkje av kva som er inni. Den fjerne gatewayen fjernar den ytre headeren og videresender den opphavlege pakka til sitt LAN, der ho igjen er ei vanleg IPv6-pakke. Ytre tunnel og indre trafikk er to separate samtalar som deler ein nøkkel, eit endepunktspar og ingenting anna.

To headarar, to adressefamiliar

I IPsec-tunnelmodus blir den indre IPv6-pakka nyttelasta bak ein ESP-header. Den ytre headeren som ber den ESP-pakka, kan vere IPv4 eller IPv6, og han følgjer local_addrs og remote_addrs. WireGuard gjer det same med mindre seremoni: den indre pakka er nyttelasta i eit UDP-datagram til endepunktet til peeren. Begge lét den indre headeren vere urørd, og difor kan den andre sida rute han etter dekapsulering.

Vegen mellom stadene ser berre UDP 4500 når IPsec brukar NAT-traversal, eller UDP 51820 for ein standard WireGuard-lyttar. Kvar ruter undervegs kan berre IPv4, og IPv6-trafikken kryssar likevel, fordi han aldri opptrer som ei IPv6-pakke på den vegen. Det gir ein rein første todeling: tcpdump -ni eth0 udp port 51820 viser den krypterte vegen, tcpdump -ni wg0 ip6 viser den indre trafikken. Ei travel ytre fangst med ei stille indre tyder på at kjernen ikkje legg IPv6 i tunnelen; det er ruting eller policy, ikkje lenketilstand.

Gatewayen reduserer òg den indre Hop Limit når han videresender, så endepunkta tel som rutarar på IPv6-vegen. Ytre hopptal og indre Hop Limit rører seg uavhengig, og ei pakke som døyr ved den fjerne gatewayen, døydde i videresendinga, ikkje i krypteringa.

Selektorar og AllowedIPs er løyvelista

IKEv2 forhandlar kva indre prefiks ein child-SA kan bera. På strongSwan 5.9 og nyare ser det slik ut når ein skriv dei 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 utleier dei frå subnetta til grensesnittet han vel. På ein dual-stack-vert gir den snarvegen ofte eit par med berre IPv4: SA-en kjem opp, og IPv6 blir avvist før det når ESP-koden. Å skrive ut begge prefiksa gjer SA-en kvalifisert til å bera dei, og start_action = trap bringer han opp ved den første passande pakka.

WireGuard har éi liste som gjer to jobbar. I peer-blokka er AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 både ruta som blir installert ved sending og filteret som blir brukt ved mottak: ei dekryptert pakke der den indre kjelda fell utanfor lista til peeren, blir slept stille. wg-quick legg til ei rute per oppføring, så peer-blokka nedanfor treng ingen eigen 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å speglast: stad B godtek prefikset til stad A som ekstern selektor og ruter det tilbake, og tunnelen verkar berre når dei to retningane er samde. Ei asymmetrisk liste gir symptomet som kostar mest tid — eit sunt handtrykk, teljarar som rører seg på éi side, og ein ping frå A til B som lukkast medan ingenting frå B når A.

Videresending, ruter og returprefikset

Linux videresender ikkje IPv6 før du seier det, og innstillinga gjeld per namespace og ikkje 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 linja er den folk gløymer i rutebaserte oppsett. Policybasert IPsec installerer ein XFRM-policy som matchar prefiksa, men eit rutebasert oppsett med vti6 eller WireGuard treng ei faktisk IPv6-rute som peiker på den eininga. Gjer sysctl-en varig under /etc/sysctl.d/; elles set ein omstart stille videresendinga tilbake til av.

Videresending har ein biverknad verd å kjenne: kjernen ignorerer då router advertisements med mindre net.ipv6.conf.<wan>.accept_ra er 2, så ein gateway der WAN-adressa kjem via SLAAC kan miste standardruta i same augneblink som du slår på videresending. Set accept_ra = 2 på det grensesnittet i same fil, og ruta overlever. Kjernen på stad B må òg lære 2001:db8:aa::/48 frå tunnelgatewayen, via ei statisk rute eller ein rutingsprotokoll over tunnelen, elles døyr svaret i nettverket til B.

Ein firetrinns kontroll som lokaliserer brotet

Arbeid i denne rekkjefølgja og stopp ved første trinn som feilar, fordi kvart seinare trinn avheng av dei tidlegare.

  1. Selektorar: swanctl --list-sas bør vise IPv6-prefiksparet på child-SA-en, eller wg show wg0 allowed-ips det eksterne prefikset med ein fersk latest-handshakes.
  2. Kjernarute: ip -6 route get 2001:db8:bb::10 må svare med tunnel-eininga, ikkje WAN-grensesnittet.
  3. Indre fangst: tcpdump -ni wg0 ip6 medan du pingar mellom ekte LAN-vertar. Pakker som går ut men ingen som kjem tilbake, peiker på ruta eller brannmuren til B; ingen pakker i det heile peiker tilbake på trinn 1 eller 2.
  4. Destinasjon: på B-verten stadfester ss -6 -ltn at tenesta lyttar på IPv6, og dei lokale brannmur-teljarane viser om pakka vart godteken eller sleppt.

MTU høyrer til i same gjennomgang. IPv6-rutarar fragmenterer ikkje, så ei for stor pakke blir slept og Packet Too Big kjem tilbake til sendaren. Viss handtrykk og små ping fungerer, men ei filoverføring stoppar, krymp nyttelasta til ho passerer: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard-grensesnitt har som standard 1420 byte MTU, og IPsec over IPv4 trekkjer av meir, så det er betre å setje den indre MTU-en enn å håpe på path-MTU-oppdaging gjennom ein brannmur som slepp ICMPv6.

Feilmodusar som ser ut som brannmurproblem

Den vanlegaste er ikkje ein brannmur i det heile: tenesta bind til 0.0.0.0 i staden for ::, AAAA-posten finst, og klienten får ei rask avvising over IPv6 som ein dual-stack-nettlesar skjuler ved å falle tilbake til IPv4. Viss berre nokre program feilar, sjekk den lyttande familien før du rører eit regelverk.

Den andre er ICMPv6-filtrering. Neighbor Discovery og Packet Too Big er ein del av normal drift, ikkje diagnostikk, og ein policy som slepp all ICMPv6 gir ein tunnel som koplar til, autentiserer og deretter stoppar på alt større enn ei lita pakke. Tillat typane vegen avheng av, og la teljarane stå på så ein dropp er synleg.

Den tredje er eit prefiks som blir lagt til tunnelen men aldri til adresseplanen for staden som eig det, så ingen ruter annonserer det og ingen vert kan svare frå det. Start med eitt prefiks og eitt vertspar, bevis begge retningane med dei fire trinna, og legg til resten etterpå; eit defekt prefiks blir ståande som éi linje i ein konfigurasjon i staden for ei ombygging. Den einaste offisielle referansen det er verd å halde open, er RFC 8200, som definerer headeren tunnelen ber.

Relaterte artiklar