IPv6-routing mellem to lokationer over et eksisterende VPN

Et WAN med kun IPv4 kan stadig bære indre IPv6. Følg selectors, kernetruter, videresendelse og returpræfikset, der lydløst dropper svar.

Når du tilføjer et IPv6-præfiks til en site-til-site-tunnel, rejser pakken ikke den vej, diagrammet antyder. Den lokale gateway tager hele IPv6-pakken, krypterer den og sætter en ydre IP-header foran, hvis adressfamilie bestemmes af endpointadresserne, ikke af hvad der er indeni. Den fjerne gateway stripper den ydre header og videresender den oprindelige pakke til sit LAN, hvor den igen er en almindelig IPv6-pakke. Ydre tunnel og indre trafik er to separate samtaler, der deler en nøgle, et endpoint-par og intet andet.

To headers, to adressfamilier

I IPsec-tunneltilstand bliver den indre IPv6-pakke nyttelasten bag en ESP-header. Den ydre header, der bærer den ESP-pakke, kan være IPv4 eller IPv6, og den følger local_addrs og remote_addrs. WireGuard gør det samme med mindre ceremoni: den indre pakke er nyttelasten i et UDP-datagram til peerens endpoint. Begge lader den indre header være urørt, hvilket er grunden til, at den anden side kan route den efter dekapsulering.

Vejen mellem lokationerne ser kun UDP 4500, når IPsec bruger NAT-traversal, eller UDP 51820 for en standard WireGuard-lytter. Enhver router undervejs kan kun køre IPv4, og IPv6-trafikken krydser alligevel, fordi den aldrig optræder som en IPv6-pakke på den vej. Det giver en ren første opdeling: tcpdump -ni eth0 udp port 51820 viser den krypterede vej, tcpdump -ni wg0 ip6 viser den indre trafik. En travl ydre optagelse med en tavs indre betyder, at kernen ikke lægger IPv6 i tunnelen; det er routing eller politik, ikke linktilstand.

Gatewayen nedsætter også den indre Hop Limit, når den videresender, så endpoints tæller som routere på IPv6-vejen. Ydre hopantal og indre Hop Limit bevæger sig uafhængigt, og en pakke, der dør ved den fjerne gateway, døde i videresendelsen, ikke i krypteringen.

Selectors og AllowedIPs er tilladelseslisten

IKEv2 forhandler, hvilke indre præfikser en child-SA må bære. På strongSwan 5.9 og senere ser det sådan ud, når man skriver dem ud 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
  }
}

Udelad local_ts og remote_ts, og strongSwan udleder dem fra subnettene på det interface, den vælger. På en dual-stack-vært giver den genvej ofte et par med kun IPv4: SA'en kommer op, og IPv6 afvises, før det når ESP-koden. At skrive begge præfikser ud gør SA'en berettiget til at bære dem, og start_action = trap starter den ved den første matchende pakke.

WireGuard har én liste, der udfører to opgaver. I peer-blokken er AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 både ruten, der installeres ved afsendelse, og filteret, der anvendes ved modtagelse: en dekrypteret pakke, hvis indre kilde falder uden for peerens liste, droppes lydløst. wg-quick tilføjer en rute per post, så peer-blokken nedenfor har ikke brug for en særskilt 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 lister skal spejles: lokation B accepterer lokation A's præfiks som fjernselector og router det tilbage, og tunnelen virker kun, når de to retninger er enige. En asymmetrisk liste giver det symptom, der koster mest tid — et sundt handshake, tællere der bevæger sig på den ene side, og en ping fra A til B, der lykkes, mens intet fra B når A.

Videresendelse, ruter og returpræfikset

Linux videresender ikke IPv6, før du siger det, og indstillingen gælder per namespace snarere end per interface:

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 anden linje er den, folk glemmer i rutebaserede designs. Politikbaseret IPsec installerer en XFRM-politik, der matcher præfikserne, men en rutebaseret opsætning med vti6 eller WireGuard har brug for en faktisk IPv6-rute, der peger på den enhed. Gør sysctl'en permanent under /etc/sysctl.d/; ellers sætter en genstart stille videresendelsen tilbage til fra.

Videresendelse har en bivirkning værd at kende: kernen ignorerer derefter router advertisements, medmindre net.ipv6.conf.<wan>.accept_ra er 2, så en gateway, hvis WAN-adresse ankommer via SLAAC, kan miste sin standardrute i det øjeblik, du aktiverer videresendelse. Sæt accept_ra = 2 på det interface i samme fil, og ruten overlever. Lokation B's core skal også lære 2001:db8:aa::/48 fra tunnelgatewayen, via en statisk rute eller en routingprotokol over tunnelen, ellers dør svaret inde i B's eget netværk.

En firetrins-kontrol, der lokaliserer bruddet

Arbejd i denne rækkefølge, og stop ved det første trin, der fejler, fordi hvert senere trin afhænger af de tidligere.

  1. Selectors: swanctl --list-sas bør vise IPv6-præfiksparret på child-SA'en, eller wg show wg0 allowed-ips fjernpræfikset med en frisk latest-handshakes.
  2. Kernetrute: ip -6 route get 2001:db8:bb::10 skal svare med tunnel-enheden, ikke WAN-interfacet.
  3. Indre optagelse: tcpdump -ni wg0 ip6 mens du pinger mellem rigtige LAN-værter. Pakker, der går ud, men ingen, der kommer tilbage, peger på B's rute eller firewall; slet ingen pakker peger tilbage på trin 1 eller 2.
  4. Destination: på B-værten bekræfter ss -6 -ltn, at tjenesten lytter på IPv6, og de lokale firewall-tællere viser, om pakken blev accepteret eller droppet.

MTU hører til samme gennemgang. IPv6-routere fragmenterer ikke, så en for stor pakke droppes, og Packet Too Big kommer tilbage til afsenderen. Hvis handshakes og små pings virker, men en filoverførsel går i stå, så skrump nyttelasten, indtil den passerer: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard-interfaces har som standard 1420 byte MTU, og IPsec over IPv4 trækker mere fra, så det er bedre at sætte den indre MTU end at håbe på path-MTU-opdagelse gennem en firewall, der dropper ICMPv6.

Fejltilstande, der ligner firewallproblemer

Den mest almindelige er slet ikke en firewall: tjenesten binder til 0.0.0.0 i stedet for ::, AAAA-posten findes, og klienten får en hurtig afvisning over IPv6, som en dual-stack-browser skjuler ved at falde tilbage til IPv4. Hvis kun nogle programmer fejler, så kontroller den lyttende familie, før du rører et regelsæt.

Den anden er ICMPv6-filtrering. Neighbor Discovery og Packet Too Big er en del af normal drift, ikke diagnostik, og en politik, der dropper al ICMPv6, giver en tunnel, der forbinder, autentificerer og derefter går i stå på alt større end en lille pakke. Tillad de typer, vejen afhænger af, og lad tællerne være tændt, så et drop er synligt.

Den tredje er et præfiks, der tilføjes tunnelen, men aldrig til adresseplanen for den lokation, der ejer det, så ingen router annoncerer det, og ingen vært kan svare fra det. Start med ét præfiks og ét værtspar, bevis begge retninger med de fire trin, og tilføj derefter resten; et defekt præfiks forbliver én linje i en konfiguration i stedet for en ombygning. Den ene officielle reference, det er værd at holde åben, er RFC 8200, som definerer den header, tunnelen bærer.

Relaterede artikler