Plánování IPv6 pro WireGuard hub se dvěma lokalitami: prefix, protějšky, trasy

Dvě LAN, jeden hub WireGuard a plán adres IPv6, který musí odpovědět na tři samostatné otázky: který prefix, která adresa patří každému routeru a který protějšek vlastní kterou podsíť. Chyba v jedné z nich vytvoří tunel, který provede handshake a nic nesměruje. Následující plán prochází privátní návrh dvou lokalit v tomto pořadí. Záměrně neposkytuje přístup k internetu přes IPv6.

Určete, k čemu prefix slouží

Jedinečně lokální prefix z fd00::/8 je přirozená volba, když je cílem privátní dostupnost mezi lokalitami. Zůstává stabilní bez ohledu na to, který poskytovatel obsluhuje každé místo, a neoznamuje se do globální směrovací tabulky, takže nemůže uniknout vaše interní číslování na internet.

Stejná vlastnost je i omezením. ULA neposkytuje veřejnou zpětnou cestu, protože žádný nadřazený systém neví, že ji má směrovat k vaší bráně. Pokud požadavek zahrnuje odchod do internetu přes IPv6, potřebujete přidělení od poskytovatele, který vám ho směruje, a to je samostatné návrhové rozhodnutí s vlastní velikostí prefixu.

Nepředpokládejte, že každé nasazení potřebuje /48. RFC 6177 se odklonil od jediné povinné velikosti koncové lokality a správná velikost vychází z počtu sítí, které budete provozovat. Generujte ULA postupem RFC 4193, místo abyste vymýšleli prefix, který může použít i jiná organizace. Zapište výsledek do plánu adres dřív, než nakonfigurujete jakékoli zařízení, protože prefix, který nikdo nezaznamenal, je prefix, který někdo znovu použije.

Rozdělte prefix na role

Níže uvedený příklad používá fd7c:2e91:4a00::/48 a tabulka je uspořádána podle toho, kam se každý blok zapisuje, ne podle lokality. Berte hodnoty jako vzorek a před nasazením si vygenerujte vlastní.

Bloky LAN jsou /64, protože běžný SLAAC očekává 64bitový identifikátor rozhraní. Rozdělení LAN na menší blok tuto předpoklad na většině hostitelů poruší a provozní náklady nestojí za úsporu adres v privátním plánu. Oba bloky LAN pocházejí ze středu /48, takže nízký rozsah zůstává volný pro pozdější lokality.

Adresy tunelu jsou administrativní fond, ne síť na propojení. Každé rozhraní z něj dostane jednu /128, takže žádný hostitel nepředpokládá sdílenou podsíť na tunelu a všude, kde to není potřeba, neběží objevování sousedů. Udržujte role oddělené a zaznamenejte je v plánu adres organizace, aby pozdější lokalita blok znovu nepoužila.

Dejte každému routeru jednu adresu tunelu

Přidělte jeden /128 na router a zachovejte stávající klíče a koncové body fungujícího hubu. Tři hodnoty níže se liší jen v části hostitele.

Hub:    Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128

Tato /128 popisuje jedinou adresu přiřazenou tomu rozhraní. Neříká nic o tom, kolik cílů protějšek smí směrovat, protože dostupnost se vyjadřuje v AllowedIPs, ne v prefixu rozhraní.

Každý router lokality také potřebuje adresu ve svém bloku LAN a způsob, jak ji distribuovat, obvykle oznámení routeru pro SLAAC. WireGuard tato oznámení za vás neodesílá a obě LAN nespojuje. Router lokality je routerem v obou směrech.

Vložte vlastnictví podsítě do AllowedIPs

Záznam protějšku v hubu pro lokalitu A vlastní adresu tunelu A a LAN A a tato dvojice je celým prohlášením o vlastnictví. Nic dalšího v této části protějšku nemusí lokalitu popisovat.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

Záznam protějšku pro lokalitu B vlastní odpovídající dvojici a symetrie je zde důležitější než stručnost. Přečtěte oba řádky společně a rozdělení vlastnictví je vidět na první pohled.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Jsou to dvě samostatné části protějšku, ne dva seznamy soutěžící o jeden protějšek. WireGuard používá AllowedIPs v obou směrech: vybírá protějšek pro odchozí cíl a odmítá příchozí paket, jehož zdroj neodpovídá rozsahu přiřazenému protějšku, který jej dešifroval. Přidělení celého /48 oběma protějškům by tuto druhou kontrolu vypnulo a zastřelo, která lokalita vlastní který blok. Právě tento rozdíl dělá chybnou zdrojovou adresu viditelnou, místo aby byla tiše přijata.

Každá lokalita potřebuje jen cíle dostupné přes svůj protějšek v hubu: lokalita A uvádí adresu hubu, adresu tunelu lokality B a LAN B, a lokalita B uvádí opačnou množinu. Seznamy jsou záměrně asymetrické, protože každý router vidí jinou stranu topologie. Oba pište z plánu adres, ne z konfigurace druhé lokality, protože tak zastaralý rozsah přežije přečíslování.

S wg-quick tyto rozsahy vytvářejí i trasy. Se systemd-networkd nebo ručním nastavením přidejte ekvivalentní trasy sami; jinak tunel přenáší pakety, které do něj jádro nikdy nepošle.

Dokončete předávání a otestujte oba směry

Zapněte předávání IPv6 na hubu a na obou routerech lokalit a v politice předávání povolte požadované služby mezi lokalitami. Udržujte zprávy ICMPv6 Packet Too Big použitelné, protože jejich zahazování rozbíjí zjišťování MTU cesty a způsobuje zaseknutí velkých přenosů, které vypadají jako chyby aplikace. Hub, který předává bez povolení firewallu, paket zahodí mezi směrováním a tunelem. Tento režim selhání stojí za to znát, protože tunel zůstává aktivní a umírají jen některé toky.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Testujte z hostitele v lokalitě A na hostitele v lokalitě B a pak opačným směrem. Ping na adresu tunelu hubu procvičí jen první skok a projde i tehdy, když jsou trasy LAN špatné. Tok od hostitele k hostiteli je ten, který plán dokazuje.

Vnější připojení WireGuard může běžet přes IPv4, zatímco vnitřní provoz je IPv6, a tato nezávislost je při migraci užitečná. Pokud se později přidá globální odchod IPv6, přehodnoťte přidělení od poskytovatele, výběr zdrojové adresy a zpětné směrování jako nový krok návrhu; privátní plán výše zůstává platný pro provoz mezi lokalitami.