IPv6-planering för ett WireGuard-nav med två platser: prefix, peeringar, rutter

Två LAN, ett WireGuard-nav och en IPv6-adressplan som måste svara på tre separata frågor: vilket prefix, vilken adress som hör till varje router och vilken peer som äger vilket subnät. Ett fel svar ger en tunnel som gör handskakning och inte routar något. Planen nedan går igenom en privat design med två platser i den ordningen. Den ger medvetet ingen internetåtkomst via IPv6.

Bestäm vad prefixet ska användas till

Ett unikt lokalt prefix från fd00::/8 är det naturliga valet när målet är privat nåbarhet mellan platser. Det förblir stabilt oavsett vilken leverantör som betjänar varje plats, och det annonseras inte i den globala routingtabellen, så det kan inte läcka din interna numrering till internet.

Samma egenskap är begränsningen. En ULA ger ingen offentlig returväg, eftersom ingen uppströmsleverantör vet att den ska routas till din gateway. Om kravet omfattar internetutgång via IPv6 behöver du en tilldelning från en leverantör som routar den till dig, och det är ett eget designbeslut med sin egen prefixstorlek.

Anta inte att varje utrullning behöver ett /48. RFC 6177 rörde sig bort från en enda obligatorisk storlek för slutplatsen, och rätt storlek följer antalet nätverk du kommer att drifta. Generera ULA:n med RFC 4193-proceduren i stället för att hitta på ett prefix som en annan organisation också kan använda. Skriv resultatet i adressplanen innan någon enhet konfigureras, för ett prefix som ingen har antecknat är ett prefix som någon kommer att återanvända.

Dela upp prefixet i roller

Exemplet nedan använder fd7c:2e91:4a00::/48, och tabellen är ordnad efter var varje block skrivs, inte efter plats. Behandla värdena som ett exempel och generera dina egna innan du rullar ut något.

LAN-blocken är /64 eftersom vanlig SLAAC förväntar sig en 64-bitars gränssnittsidentifierare. Att dela ett LAN i ett mindre block bryter det antagandet på de flesta värdar, och driftskostnaden är inte adressbesparingen värd i en privat plan. Båda LAN-blocken kommer från mitten av /48 och lämnar det låga intervallet fritt för senare platser.

Tunneladresserna är ett administrativt förråd, inte ett nätverk på länken. Varje gränssnitt får en enda /128 därifrån, så ingen värd antar ett delat subnät på tunneln och grannupptäckt körs inte där den inte behövs. Håll rollerna åtskilda och registrera dem i organisationens adressplan så att en senare plats inte återanvänder ett block.

Ge varje router en tunneladress

Tilldela en /128 per router och behåll de befintliga nycklarna och slutpunkterna för navet som fungerar. De tre värdena nedan skiljer sig bara i värddelen.

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

Denna /128 beskriver den enda adress som tilldelats det gränssnittet. Den säger ingenting om hur många destinationer peeren får routa, eftersom nåbarhet uttrycks i AllowedIPs och inte i gränssnittets prefix.

Varje platsrouter behöver också en adress i sitt LAN-block och ett sätt att distribuera den, vanligtvis routerannonsering för SLAAC. WireGuard skickar inte dessa annonseringar åt dig och bryggar inte de två LAN:en. Platsroutern är en router i båda riktningarna.

Lägg subnätets ägarskap i AllowedIPs

Navets peer-post för Plats A äger A:s tunneladress och A:s LAN, och det paret är hela ägandeförklaringen. Inget annat i det peer-avsnittet behöver beskriva platsen.

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

Peer-posten för Plats B äger motsvarande par, och symmetri betyder mer här än korthet. Läs de två raderna tillsammans och ägandefördelningen blir synlig med en blick.

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

Det här är två separata peer-avsnitt, inte två listor som konkurrerar om en peer. WireGuard använder AllowedIPs i båda riktningarna: det väljer peeren för en utgående destination och det avvisar ett inkommande paket vars källa inte matchar det intervall som tilldelats peeren som dekrypterade det. Att ge hela /48 till båda peerarna skulle stänga av den andra kontrollen och göra det otydligt vilken plats som äger vilket block. Just den skillnaden gör en felaktig källadress synlig i stället för tyst accepterad.

Varje plats behöver bara de destinationer som nås via dess nav-peer: Plats A listar navets adress, Plats B:s tunneladress och B:s LAN, och Plats B listar den omvända mängden. Listorna är asymmetriska med avsikt, eftersom varje router ser en annan sida av topologin. Skriv båda från adressplanen och inte från den andra platsens konfiguration, för det är så ett inaktuellt intervall överlever en omnumrering.

Med wg-quick skapar dessa intervall också rutter. Med systemd-networkd eller manuell konfiguration måste du lägga till motsvarande rutter själv; annars bär tunneln paket som kärnan aldrig skickar in i den.

Slutför vidarebefordran och testa båda riktningarna

Aktivera IPv6-vidarebefordran på navet och på båda platsrouterna, och tillåt de nödvändiga tjänsterna mellan platserna i vidarebefordringspolicyn. Håll ICMPv6 Packet Too Big-meddelanden användbara, eftersom att släppa dem bryter path-MTU-upptäckten och ger stora överföringsstopp som ser ut som applikationsfel. Ett nav som vidarebefordrar utan brandväggstillståndet släpper paketet mellan routning och tunnel. Det felet är värt att känna till, eftersom tunneln håller sig uppe och bara några flöden dör.

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

Testa från en värd på Plats A till en värd på Plats B och sedan i motsatt riktning. En ping till navets tunneladress övar bara första hoppet och lyckas även när LAN-rutterna är fel. Värd-till-värd-flödet är det som bevisar planen.

Den yttre WireGuard-anslutningen kan gå över IPv4 medan den inre trafiken är IPv6, och det oberoendet är användbart under migrering. Om global IPv6-utgång läggs till senare, se över leverantörstilldelningen, valet av källadress och returroutningen som ett nytt designsteg; den privata planen ovan förblir giltig för trafik mellan platser.