Směrování IPv6 mezi dvěma lokalitami přes existující VPN

WAN pouze s IPv4 stále může přenášet vnitřní IPv6. Sledujte selektory, trasy jádra, předávání a návratový prefix, který tiše zahazuje odpovědi.

Když přidáte prefix IPv6 do tunelu mezi lokalitami, paket necestuje tak, jak naznačuje diagram. Místní brána vezme celý paket IPv6, zašifruje ho a před něj vloží vnější hlavičku IP, jejíž rodinu adres určují adresy koncových bodů, ne to, co je uvnitř. Vzdálená brána tuto vnější hlavičku odstraní a předá původní paket do své LAN, kde je opět obyčejným paketem IPv6. Vnější tunel a vnitřní provoz jsou dvě oddělené konverzace, které sdílejí klíč, pár koncových bodů a nic dalšího.

Dvě hlavičky, dvě rodiny adres

V režimu tunelu IPsec se vnitřní paket IPv6 stává nákladem za hlavičkou ESP. Vnější hlavička nesoucí tento paket ESP může být IPv4 nebo IPv6 a řídí se local_addrs a remote_addrs. WireGuard dělá totéž s menší ceremonií: vnitřní paket je náklad datagramu UDP na koncový bod protější strany. Obě nechávají vnitřní hlavičku nedotčenou, a proto ji vzdálená strana může po dekapsulaci směrovat.

Cesta mezi lokalitami vidí pouze UDP 4500, když IPsec používá průchod NAT, nebo UDP 51820 pro výchozí posluchač WireGuard. Jakýkoli router na cestě může být pouze IPv4 a provoz IPv6 přesto prochází, protože se na této cestě nikdy neobjeví jako paket IPv6. To dává čisté první rozdělení: tcpdump -ni eth0 udp port 51820 ukazuje šifrovanou cestu, tcpdump -ni wg0 ip6 ukazuje vnitřní provoz. Rušný vnější odposlech s tichým vnitřním znamená, že jádro nevkládá IPv6 do tunelu; to je směrování nebo politika, ne stav spoje.

Brána také snižuje vnitřní Hop Limit při předávání, takže se koncové body počítají jako routery na cestě IPv6. Vnější počet skoků a vnitřní Hop Limit se pohybují nezávisle a paket, který zemře na vzdálené bráně, zemřel při předávání, ne při šifrování.

Selektory a AllowedIPs jsou seznam oprávnění

IKEv2 vyjednává, které vnitřní prefixy může child SA nést. Na strongSwan 5.9 a novějších vypadá jejich vypsání v swanctl.conf takto:

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

Vynecháte-li local_ts a remote_ts, strongSwan je odvodí z podsítí zvoleného rozhraní. Na hostiteli s dual-stack tato zkratka často dává pár pouze IPv4: SA vstane a IPv6 je odmítnuto, než se dostane ke kódu ESP. Vypsání obou prefixů dělá SA schopnou je nést a start_action = trap ji zvedne u prvního odpovídajícího paketu.

WireGuard má jeden seznam plnící dvě úlohy. V bloku partnera je AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 jak trasou nainstalovanou při odesílání, tak filtrem uplatněným při příjmu: dešifrovaný paket, jehož vnitřní zdroj padne mimo seznam tohoto partnera, je tiše zahozen. wg-quick přidá trasu pro každý záznam, takže blok partnera níže nepotřebuje samostatný příkaz ip -6 route.

[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

Oba seznamy musí být zrcadlové: lokalita B přijímá prefix lokality A jako vzdálený selektor a směruje ho zpět, a tunel funguje jen tehdy, když se oba směry shodují. Asymetrický seznam dává příznak, který spotřebuje nejvíc času — zdravý handshake, počítadla se hýbou na jedné straně, a ping z A do B, který uspěje, zatímco nic z B se do A nedostane.

Předávání, trasy a návratový prefix

Linux nepředává IPv6, dokud neřeknete, a nastavení platí pro namespace, ne pro rozhraní:

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

Druhá řádka je ta, na kterou lidé v návrzích založených na trasách zapomínají. IPsec založený na politice instaluje politiku XFRM odpovídající prefixům, ale nastavení založené na trasách s vti6 nebo WireGuard potřebuje skutečnou trasu IPv6 ukazující na toto zařízení. Uložte sysctl pod /etc/sysctl.d/; jinak restart tiše vrátí předávání do vypnutého stavu.

Předávání má vedlejší účinek, který stojí za to znát: jádro pak ignoruje oznámení routerů, pokud net.ipv6.conf.<wan>.accept_ra není 2, takže brána, jejíž adresa WAN přichází přes SLAAC, může ztratit výchozí trasu ve chvíli, kdy předávání zapnete. Nastavte accept_ra = 2 na tomto rozhraní ve stejném souboru a trasa přežije. Jádro lokality B se také musí naučit 2001:db8:aa::/48 od brány tunelu, statickou trasou nebo směrovacím protokolem nad tunelem, jinak odpověď zemře uvnitř vlastní sítě B.

Kontrola ve čtyřech krocích, která lokalizuje poruchu

Pracujte v tomto pořadí a zastavte se u prvního kroku, který selže, protože každý další krok závisí na předchozích.

  1. Selektory: swanctl --list-sas by měl ukázat pár prefixů IPv6 na child SA, nebo wg show wg0 allowed-ips vzdálený prefix s čerstvým latest-handshakes.
  2. Trasa jádra: ip -6 route get 2001:db8:bb::10 musí odpovědět zařízením tunelu, ne rozhraním WAN.
  3. Vnitřní odposlech: tcpdump -ni wg0 ip6 při pingování mezi skutečnými hostiteli LAN. Pakety, které odcházejí, ale žádný se nevrací, ukazují na trasu nebo firewall B; vůbec žádné pakety ukazují zpět na krok 1 nebo 2.
  4. Cíl: na hostiteli B ss -6 -ltn potvrzuje, že služba naslouchá na IPv6, a místní počítadla firewallu ukazují, zda byl paket přijat, nebo zahozen.

MTU patří do stejného průchodu. Routery IPv6 nefragmentují, takže příliš velký paket je zahozen a Packet Too Big se vrací odesílateli. Pokud handshaky a malé pingy fungují, ale přenos souboru se zasekne, zmenšete náklad, dokud neprojde: ping -6 -s 1400 -c 3 2001:db8:bb::10. Rozhraní WireGuard mají standardně MTU 1420 bajtů a IPsec nad IPv4 ubírá více, takže nastavení vnitřního MTU je lepší než doufat v objevování MTU cesty přes firewall, který zahazuje ICMPv6.

Režimy selhání, které vypadají jako problémy firewallu

Nejčastější vůbec není firewall: služba se váže na 0.0.0.0 místo ::, záznam AAAA existuje a klient dostane rychlé odmítnutí přes IPv6, které prohlížeč s dual-stack skryje návratem k IPv4. Pokud selhávají jen některé aplikace, zkontrolujte naslouchající rodinu, než se dotknete sady pravidel.

Druhý je filtrování ICMPv6. Neighbor Discovery a Packet Too Big jsou součástí normálního provozu, ne diagnostiky, a politika, která zahazuje celé ICMPv6, vytváří tunel, který se připojí, ověří a pak se zasekne na čemkoli větším než malý paket. Povolte typy, na kterých cesta závisí, a nechte počítadla zapnutá, aby bylo zahození vidět.

Třetí je prefix přidaný do tunelu, ale nikdy do adresního plánu lokality, která ho vlastní, takže ho žádný router neoznamuje a žádný hostitel z něj nemůže odpovědět. Začněte jedním prefixem a jedním párem hostitelů, prokažte oba směry čtyřmi kroky a pak přidejte zbytek; rozbitý prefix zůstane jednou řádkou v konfiguraci místo přestavby. Jediná oficiální reference, kterou stojí za to držet otevřenou, je RFC 8200, která definuje hlavičku, kterou tunel nese.

Související články