Planlægning af IPv6 til et WireGuard-hub med to lokationer: præfiks, peere, ruter

To LAN, ét WireGuard-hub og en IPv6-adresseplan, der skal besvare tre separate spørgsmål: hvilket præfiks, hvilken adresse der hører til hver router, og hvilken peer der ejer hvilket undernet. Er ét af dem forkert, får man en tunnel, der laver håndtryk og ikke ruter noget. Planen nedenfor gennemgår et privat design med to lokationer i den rækkefølge. Den giver bevidst ikke internetadgang via IPv6.

Beslut, hvad præfikset skal bruges til

Et unikt lokalt præfiks fra fd00::/8 er det naturlige valg, når målet er privat forbindelse mellem lokationer. Det forbliver stabilt uanset hvilken udbyder der betjener hver lokation, og det annonceres ikke i den globale routingtabel, så det kan ikke lække din interne nummerering til internettet.

Den samme egenskab er begrænsningen. En ULA giver ingen offentlig returvej, fordi ingen upstream ved, at den skal routes til din gateway. Hvis kravet omfatter internetudgang via IPv6, har du brug for en tildeling fra en udbyder, der router den til dig, og det er en separat designbeslutning med sin egen præfiksstørrelse.

Antag ikke, at hver udrulning kræver et /48. RFC 6177 bevægede sig væk fra én obligatorisk slutstedstørrelse, og den rigtige størrelse følger antallet af netværk, du vil drive. Generér ULA'en med RFC 4193-proceduren i stedet for at opfinde et præfiks, som en anden organisation også kan bruge. Skriv resultatet ind i adresseplanen, før nogen enhed konfigureres, for et præfiks, som ingen har noteret, er et præfiks, som nogen vil genbruge.

Del præfikset op i roller

Eksemplet nedenfor bruger fd7c:2e91:4a00::/48, og tabellen er organiseret efter, hvor hver blok skrives, snarere end efter lokation. Betragt værdierne som et eksempel og generér dine egne, før du udruller noget.

LAN-blokkene er /64, fordi almindelig SLAAC forventer en 64-bit interface-identifikator. At dele et LAN i en mindre blok bryder den antagelse på de fleste værter, og driftsomkostningerne er ikke adressebesparelsen værd i en privat plan. Begge LAN-blokke kommer fra midten af /48 og efterlader det lave interval frit til senere lokationer.

Tunneladresserne er en administrativ spand, ikke et netværk på linket. Hvert interface får en enkelt /128 fra den, så ingen vært antager et delt undernet på tunnelen, og nabo-opdagelse kører ikke, hvor den ikke er nødvendig. Hold rollerne adskilte og registrer dem i organisationens adresseplan, så en senere lokation ikke genbruger en blok.

Giv hver router én tunneladresse

Tildel én /128 for hver router, og behold de eksisterende nøgler og endepunkter fra det fungerende hub. De tre værdier nedenfor adskiller sig kun i værtsdelen.

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

Denne /128 beskriver den enkelte adresse, der er tildelt det interface. Den siger intet om, hvor mange destinationer peeren må route, fordi tilgængelighed udtrykkes i AllowedIPs og ikke i interfacepræfikset.

Hver lokationsrouter skal også have en adresse i sin LAN-blok og en måde at distribuere den på, normalt routerannonceringer til SLAAC. WireGuard sender ikke disse annonceringer for dig, og det bygger ikke bro mellem de to LAN. Lokationsrouteren er en router i begge retninger.

Læg undernets ejerskab i AllowedIPs

Hub'ets peer-post for Lokation A ejer A's tunneladresse og A's LAN, og det par er hele ejerskabserklæringen. Intet andet i det peer-afsnit behøver at beskrive lokationen.

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

Peer-posten for Lokation B ejer det matchende par, og symmetri betyder her mere end korthed. Læs de to linjer sammen, så bliver ejerskabsopdelingen synlig med ét blik.

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

Det er to separate peer-afsnit, ikke to lister, der konkurrerer om én peer. WireGuard bruger AllowedIPs i begge retninger: det vælger peeren for en udgående destination, og det afviser en indgående pakke, hvis kilde ikke matcher det interval, der er tildelt den peer, som dekrypterede den. At give hele /48 til begge peere ville deaktivere den anden kontrol og sløre, hvilken lokation der ejer hvilken blok. Den forskel er det, der gør en forkert kildeadresse synlig i stedet for stiltiende accepteret.

Hver lokation behøver kun de destinationer, der kan nås via dens hub-peer: Lokation A opsummerer hub-adressen, Lokation B's tunneladresse og B's LAN, og Lokation B opsummerer det modsatte sæt. Listerne er asymmetriske med vilje, fordi hver router ser en anden side af topologien. Skriv begge ud fra adresseplanen i stedet for fra den anden lokations konfiguration, for det er sådan et forældet interval overlever en omnummerering.

Med wg-quick opretter disse intervaller også ruter. Med systemd-networkd eller en manuel opsætning skal du selv tilføje de tilsvarende ruter; ellers bærer tunnelen pakker, som kernen aldrig sender ind i den.

Fuldfør videresendelsen, og test begge retninger

Aktivér IPv6-videresendelse på hub'et og på begge lokationsroutere, og tillad de nødvendige tjenester mellem lokationerne i videresendelsespolitikken. Hold ICMPv6 Packet Too Big-beskeder brugbare, fordi at droppe dem bryder path-MTU-opdagelsen og giver store overførselsstop, der ligner applikationsfejl. Et hub, der videresender uden firewall-tilladelsen, dropper pakken mellem routing og tunnel. Den fejltilstand er værd at kende, fordi tunnelen forbliver oppe, og kun nogle flows dør.

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

Test fra en vært i Lokation A til en vært i Lokation B og derefter i den modsatte retning. En ping til hub'ets tunneladresse øver kun det første hop og vil lykkes, selv når LAN-ruterne er forkerte. Vært-til-vært-flowet er det, der beviser planen.

Den ydre WireGuard-forbindelse kan køre over IPv4, mens den indre trafik er IPv6, og den uafhængighed er nyttig under migrering. Hvis der senere tilføjes global IPv6-udgang, skal udbyderens tildeling, valg af kildeadresse og returnering genovervejes som et nyt designtrin; den private plan ovenfor forbliver gyldig for trafik mellem lokationer.