IPv6 plannen voor een WireGuard-hub met twee locaties: prefix, peers, routes

Twee LAN's, één WireGuard-hub en een IPv6-adresplan dat drie afzonderlijke vragen moet beantwoorden: welke prefix, welk adres bij elke router hoort en welke peer welk subnet bezit. Eén fout antwoord levert een tunnel op die een handshake doet en niets routeert. Het plan hieronder doorloopt in die volgorde een privéontwerp met twee locaties. Het biedt bewust geen internettoegang via IPv6.

Bepaal waarvoor de prefix dient

Een unieke lokale prefix uit fd00::/8 is de natuurlijke keuze wanneer het doel private bereikbaarheid tussen locaties is. Die blijft stabiel ongeacht welke provider elke locatie bedient, en wordt niet in de globale routingtabel aangekondigd, dus hij kan uw interne nummering niet naar het internet laten lekken.

Dezelfde eigenschap is de beperking. Een ULA geeft geen openbare terugweg, omdat geen enkele upstream weet dat hij naar uw gateway gerouteerd moet worden. Als de eis een internetuitgang via IPv6 omvat, hebt u nodig een toewijzing van een provider die hem naar u routeert, en dat is een aparte ontwerpbeslissing met zijn eigen prefixgrootte.

Ga er niet van uit dat elke uitrol een /48 nodig heeft. RFC 6177 bewoog weg van één verplichte eindlocatiegrootte, en de juiste grootte volgt het aantal netwerken dat u beheert. Genereer de ULA met de RFC 4193-procedure in plaats van een prefix te verzinnen die een andere organisatie ook zou kunnen gebruiken. Schrijf het resultaat in het adresplan voordat een apparaat wordt geconfigureerd, want een prefix die niemand vastlegde is een prefix die iemand hergebruikt.

Verdeel de prefix in rollen

Het voorbeeld hieronder gebruikt fd7c:2e91:4a00::/48, en de tabel is geordend naar waar elk blok wordt geschreven, niet naar locatie. Behandel de waarden als voorbeeld en genereer de uwe voordat u iets uitrolt.

De LAN-blokken zijn /64 omdat gewone SLAAC een 64-bits interface-identificatie verwacht. Een LAN in een kleiner blok splitsen breekt die aanname op de meeste hosts, en de operationele kosten wegen niet op tegen de adresbesparing in een privéplan. Beide LAN-blokken komen uit het midden van de /48 en laten het lage bereik vrij voor latere locaties.

De tunneladressen zijn een administratieve voorraad, geen netwerk op de link. Elke interface krijgt er één /128 uit, zodat geen host een gedeeld subnet op de tunnel veronderstelt en buurdetectie niet draait waar die niet nodig is. Houd de rollen gescheiden en leg ze vast in het adresplan van de organisatie, zodat een latere locatie geen blok hergebruikt.

Geef elke router één tunneladres

Wijs één /128 per router toe en behoud de bestaande sleutels en eindpunten van de werkende hub. De drie waarden hieronder verschillen alleen in het hostdeel.

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

Deze /128 beschrijft het enige adres dat aan die interface is toegewezen. Hij zegt niets over hoeveel bestemmingen de peer mag routeren, omdat bereikbaarheid in AllowedIPs wordt uitgedrukt en niet in de interfaceprefix.

Elke locatierouter heeft ook een adres in zijn LAN-blok nodig en een manier om dat te verspreiden, meestal routeraankondigingen voor SLAAC. WireGuard verstuurt die aankondigingen niet voor u en overbrugt de twee LAN's niet. De locatierouter is een router in beide richtingen.

Zet het eigendom van het subnet in AllowedIPs

De peer-regel van de hub voor locatie A bezit het tunneladres van A en het LAN van A, en dat paar is de volledige eigendomsverklaring. Niets anders in dat peer-gedeelte hoeft de locatie te beschrijven.

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

De peer-regel voor locatie B bezit het bijpassende paar, en symmetrie weegt hier zwaarder dan beknoptheid. Lees de twee regels samen en de eigendomsverdeling wordt in één oogopslag zichtbaar.

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

Dit zijn twee afzonderlijke peer-gedeelten, niet twee lijsten die om één peer concurreren. WireGuard gebruikt AllowedIPs in beide richtingen: het kiest de peer voor een uitgaande bestemming en het verwerpt een inkomend pakket waarvan de bron niet overeenkomt met het bereik dat is toegewezen aan de peer die het heeft ontsleuteld. Als u beide peers de hele /48 geeft, wordt die tweede controle uitgeschakeld en wordt het wazig welke locatie welk blok bezit. Juist dat onderscheid maakt een verkeerd bronadres zichtbaar in plaats van stil geaccepteerd.

Elke locatie heeft alleen de bestemmingen nodig die via zijn hub-peer bereikbaar zijn: locatie A noemt het hubadres, het tunneladres van locatie B en het LAN van B, en locatie B noemt de omgekeerde set. De lijsten zijn met opzet asymmetrisch, omdat elke router een andere kant van de topologie ziet. Schrijf beide vanuit het adresplan en niet vanuit de configuratie van de andere locatie, want zo overleeft een verouderd bereik een hernummering.

Met wg-quick maken deze bereiken ook routes aan. Met systemd-networkd of een handmatige opzet moet u de equivalente routes zelf toevoegen; anders draagt de tunnel pakketten die de kernel er nooit in stuurt.

Rond de doorsturing af en test beide richtingen

Schakel IPv6-doorsturing in op de hub en op beide locatierouters, en sta de vereiste diensten tussen locaties toe in het doorstuurbeleid. Houd ICMPv6 Packet Too Big-berichten bruikbaar, want ze weggooien breekt de path-MTU-detectie en veroorzaakt stagnatie bij grote overdrachten die op applicatiefouten lijken. Een hub die doorstuurt zonder de firewalls toestemming laat het pakket tussen routing en tunnel vallen. Die faalmodus is de moeite van het kennen waard, want de tunnel blijft overeind en alleen sommige stromen sterven.

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

Test van een host op locatie A naar een host op locatie B en dan in de tegenovergestelde richting. Een ping naar het tunneladres van de hub oefent alleen de eerste hop en slaagt ook wanneer de LAN-routes verkeerd zijn. De host-naar-host-stroom is degene die het plan bewijst.

De buitenste WireGuard-verbinding kan over IPv4 lopen terwijl het interne verkeer IPv6 is, en die onafhankelijkheid is nuttig tijdens een migratie. Als later een wereldwijde IPv6-uitgang wordt toegevoegd, heroverweeg dan de providertoewijzing, de keuze van het bronadres en de terugroutering als een nieuwe ontwerpstap; het privéplan hierboven blijft geldig voor verkeer tussen locaties.