Delegace prefixu IPv6 přes VPN mezi lokalitami: kontrolní seznam

Zvednout tunel je ta snadnější polovina. Viděl jsem spojení mezi lokalitami zůstat navázané celé dny, zatímco každý hostitel ve vzdálené LAN dostával zpět jen ticho, protože delegovaný prefix za tou bránou byl nakonfigurovaný na rozhraní, ale nikdy se nesměroval do tunelu. Adresy tunelu po celou dobu odpovídaly na pingy, a právě proto se nikdo na prefix nepodíval. Tohle je pořadí, které kontroluji, když delegovaný prefix IPv6 musí projít přes VPN mezi lokalitami: mapa prefixů, provozní selektory, forwarding a firewall, a pak zpětná cesta.

Napište mapu prefixů, než se dotknete tunelu

Delegace prefixu předá blok směrovači, který o něj požádal. Nenainstaluje trasu na protějšek, nerozšíří ten blok na lince ani neřekne vzdálené bráně, co žije za žádajícím směrovačem. Tyhle tři věci konfigurujete vy a patří do plánu adres dřív, než se změní jakýkoli konfigurační soubor.

Pro každou lokalitu zaznamenejte delegovaný prefix, /64, která se na LAN skutečně používá, adresy tunelu a vlastníka každé trasy. Poskytovatel deleguje lokalitě A 2001:db8:a1::/56, která na své LAN obsluhuje 2001:db8:a1:10::/64; lokalita B si drží 2001:db8:b2::/64. Pokud lokalita A obsluhuje jen tuto jednu /64, mají oba konce jmenovat 2001:db8:a1:10::/64, a ne celou /56.

Dvě chyby se objeví téměř pokaždé. První je považovat vzdálený prefix za lokální na lince, přemostit ho nebo ho dát na rozhraní tunelu, aby brána odpovídala na sousedskou solicitu za hostitele, na které nedosáhne. Druhá je inzerovat celou /56, když je nakonfigurovaná jen jedna /64: směrovací tabulka tvrdí, že blok je dosažitelný, a většina adres propadá do černé díry.

Slaďte provozní selektory obou konců s trasami

IKEv2 i WireGuard odmítají neshodný provoz, dost tiše na to, aby tunel pořád vypadal zdravě.

V strongSwanu jsou selektory explicitní. Na lokalitě A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

conn lokality B zrcadlí obě podsítě. Když se neshodnou, responder odmítne CHILD_SA s TS_UNACCEPTABLE, takže podřízená SA nikdy nevznikne, i když IKE_SA vznikla. Na obou stranách se nakonfigurovaná podsíť musí rovnat tomu, co místní jádro směruje k tunelu.

WireGuard nese stejnou informaci v AllowedIPs, s jedním obratem: AllowedIPs je zdrojový filtr při příjmu a zároveň trasa při odesílání. Pokud záznam protějšku lokality B pro lokalitu A vynechá 2001:db8:a1:10::/64, pakety z lokality A dorazí na platném handshake a jsou zahozeny jako nepovolené. To dává známý vzorec handshake, který se pořád obnovuje, zatímco nikdy neodejde odpověď. Porovnejte oba konce pomocí wg show wg0 allowed-ips. Kontrolujte ten seznam znovu při každé změně delegace; zastaralá /64 drží relaci nahoru a nový prefix nedosažitelný.

Nejdřív vylučte forwarding, firewall a MTU

Než přečtete další řádek logu, ověřte, že brány vůbec forwardují. sysctl net.ipv6.conf.all.forwarding musí na obou vrátit 1, aplikované i na rozhraní tunelu a LAN. Jeden chyták je v tom zabudovaný: jakmile je forwarding zapnutý, rozhraní s accept_ra=1 přestane přijímat oznámení směrovače od poskytovatele, takže stroj může ztratit výchozí trasu nahoru, zatímco uvnitř tunelu směruje bezchybně. Nastavte accept_ra=2 tam, kde je RA od poskytovatele ještě potřeba.

Pravidla firewallu pak musí propustit prefix v obou směrech a ICMPv6 musí přežít: objevování sousedů, packet-too-big a nedosažitelný cíl nejsou volitelné. Zahoďte je a objevování MTU cesty se rozbije, takže dostanete spojení, která se otevřou a pak se zaseknou na první velké odpovědi. Minimální dvojice pravidel vypadá takto:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU je za tím. Tunel zmenšuje použitelné MTU pod 1500 a IPv6 vyžaduje, aby každé spojení uneslo alespoň 1280. Malé pingy projdou, SSH relace zamrzne při velkém nárazu a /proc/net/snmp6 ukazuje zprávy packet-too-big, které se nikdy nevrátí. Nastavte MTU tunelu explicitně, nebo omezte TCP MSS v tabulce mangle, a nechte ICMPv6, které hlásí menší MTU, aby se vrátilo.

Testujte zpětnou cestu, ne adresu tunelu

Selhání, které stojí nejvíc času, je jednosměrné směrování. Každá brána směruje vzdálený prefix do tunelu, ale hostitelé odpovídají přes svou vlastní výchozí bránu, protože tam žije jejich /64. Dostat paket k cíli je jen polovina cesty.

Dva příkazy vyřeší většinu. Na lokalitě A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ukáže, které rozhraní by použila odpověď z tohoto zdroje; proveďte zrcadlovou kontrolu na lokalitě B. Pak generujte provoz z hostitele, ne z brány, a porovnejte čítače na obou koncích.

Pokud se v tunelu objeví sousedská solicita pro vzdálený prefix, je tento prefix na lince někde, kde by být neměl; opravte to dřív, než budete upravovat trasy. Proxy NDP pokrývá případy, kdy je přemostění opravdu potřeba, a není náhradou za trasu.

Počítejte s tím, že se prefix pod vámi změní

Delegace prefixu je pronájem mezi delegujícím a žádajícím směrovačem a obnova může vrátit jiný blok: jinou /56 po migraci poskytovatele nebo kratší pronájem, než jak dlouho je tunel nahoru. Každé místo, které jmenuje starý prefix, zastará naráz: trasy, selektory, AllowedIPs, pravidla firewallu, záznamy DNS a jakýkoli monitoring, který natvrdo kóduje doslovné adresy. Tok zpráv je v RFC 8415.

Tam, kde se očekává pohyb prefixu, udržujte interní plán adres, který na něm nezávisí, a překládejte na hranici. NPTv6 je bezstavová volba a udržuje interní politiku čitelnou, ale je to překlad prefixů, ne magická vrstva: hranice /64 musí lícovat, kontrolní součty se upravují a aplikace, které vkládají doslovné adresy, se pořád rozbijí. Pokud držíte adresy poskytovatele od konce do konce, zapište do plánu adres chování pronájmu a postup změny.

Skončete testem, který přežije čas: povolený hostitel v každé LAN dosáhne služby v druhé LAN, odpověď se vrátí tunelem a stejná dvojice funguje i po restartu tunelu a obnově delegace. Pokud poslední část selže, návrh závisí na stavu, který týden nepřežije.