Beplanning van IPv6 vir 'n WireGuard-hub met twee terreine: voorvoegsel, eweknieë, roetes

Twee LAN's, een WireGuard-hub en 'n IPv6-adresplan wat drie afsonderlike vrae moet beantwoord: watter voorvoegsel, watter adres aan elke router behoort, en watter eweknie watter subnet besit. As een van hulle verkeerd is, kry jy 'n tonnel wat 'n handskud doen en niks routeer nie. Die plan hieronder werk 'n private twee-terrein-ontwerp in daardie volgorde deur. Dit voorsien doelbewus nie IPv6-internettoegang nie.

Bepaal waarvoor die voorvoegsel dien

'n Unieke-plaaslike voorvoegsel uit fd00::/8 is die natuurlike keuse wanneer die doel private bereikbaarheid tussen terreine is. Dit bly stabiel ongeag watter ISP elke ligging bedien, en dit word nie aan die globale roeteertabel geadverteer nie, so dit kan nie jou interne nommering na die internet laat lek nie.

Dieselfde eienskap is die beperking. 'n ULA gee geen openbare terugpad nie, want geen opstroom weet om dit na jou gateway te routeer nie. As die vereiste IPv6-internetuitgang insluit, het jy 'n toekenning van 'n verskaffer wat dit na jou toe routeer, en dit is 'n aparte ontwerpbesluit met sy eie voorvoegselgrootte.

Moenie aanneem elke ontplooiing het 'n /48 nodig nie. RFC 6177 het wegbeweeg van 'n enkele verpligte grootte vir eindpersele, en die regte grootte volg die aantal netwerke wat jy sal bedryf. Genereer die ULA met die RFC 4193-prosedure eerder as om 'n voorvoegsel te bedink wat 'n ander organisasie ook mag gebruik. Skryf die resultaat in die adresplan voordat enige toestel opgestel word, want 'n voorvoegsel wat niemand opgeteken het nie, is 'n voorvoegsel wat iemand sal hergebruik.

Verdeel die voorvoegsel in rolle

Die voorbeeld hieronder gebruik fd7c:2e91:4a00::/48, en die tabel is georganiseer volgens waar elke blok geskryf word eerder as volgens terrein. Behandel die waardes as 'n voorbeeld en genereer jou eie voordat jy iets ontplooi.

Die LAN-blokke is /64 omdat gewone SLAAC 'n 64-bis koppelvlakidentifiseerder verwag. Om 'n LAN in 'n kleiner blok te verdeel, breek daardie aanname op die meeste hosts, en die bedryfskoste is nie die adresbesparing in 'n private plan werd nie. Albei LAN-blokke kom uit die middel van die /48, wat die lae reeks vir latere terreine vrylaat.

Die tonneladresse is 'n administratiewe emmer, nie 'n on-link-netwerk nie. Elke koppelvlak kry 'n enkele /128 daaruit, so geen host aanvaar 'n gedeelde subnet op die tonnel nie en geen buurontdekking loop waar dit nie nodig is nie. Hou die rolle disjunk en teken dit in die organisasie se adresplan op sodat 'n latere terrein nie 'n blok hergebruik nie.

Gee elke router een tonneladres

Wys een /128 per router toe en behou die bestaande sleutels en eindpunte van die werkende hub. Die drie waardes hieronder verskil net in die gasheerdeel.

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

Die /128 beskryf die enkele adres wat aan daardie koppelvlak toegewys is. Dit sê niks oor hoeveel bestemmings die eweknie mag routeer nie, want bereikbaarheid word in AllowedIPs uitgedruk eerder as in die koppelvlakvoorvoegsel.

Elke terreinrouter het ook 'n adres in sy LAN-blok nodig en 'n manier om dit te versprei, gewoonlik routeradvertensies vir SLAAC. WireGuard stuur nie daardie advertensies vir jou nie, en dit oorbrug nie die twee LAN's nie. Die terreinrouter is 'n router in albei rigtings.

Plaas subnet-eienaarskap in AllowedIPs

Die hub se eweknie-inskrywing vir Terrein A besit A se tonneladres en A se LAN, en daardie paring is die hele eienaarskapverklaring. Niks anders in daardie eweknie-afdeling hoef die terrein te beskryf nie.

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

Die eweknie-inskrywing vir Terrein B besit die passende paar, en simmetrie hier is belangriker as beknoptheid. Lees die twee reëls saam en die eienaarskapverdeling word met 'n oogopslag sigbaar.

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

Dit is twee aparte eweknie-afdelings, nie twee lyste wat om een eweknie meeding nie. WireGuard gebruik AllowedIPs in albei rigtings: dit kies die eweknie vir 'n uitgaande bestemming, en dit verwerp 'n inkomende pakket wie se bron nie ooreenstem met die reeks wat aan die eweknie toegewys is wat dit ontsif het nie. Om die hele /48 aan albei eweknieë te gee, sou daardie tweede kontrole uitskakel en verduister watter terrein watter blok besit. Daardie onderskeid is wat 'n verkeerde bronadres sigbaar maak eerder as om dit stilweg te aanvaar.

Elke terrein het net die bestemmings nodig wat deur sy hub-eweknie bereikbaar is: Terrein A lys die hub-adres, Terrein B se tonneladres en B se LAN, en Terrein B lys die wederkerige stel. Die lyste is doelbewus asimmetries, want elke router sien 'n ander kant van die topologie. Skryf albei uit die adresplan eerder as uit die ander terrein se konfigurasie, want dit is hoe 'n verouderde reeks 'n hernommering oorleef.

Met wg-quick skep hierdie reekse ook roetes. Met systemd-networkd of 'n handmatige opstelling, voeg die ekwivalente roetes self by; anders dra die tonnel pakkette wat die kern nooit daarin stuur nie.

Voltooi aanstuur en toets albei rigtings

Aktiveer IPv6-aanstuur op die hub en op albei terreinrouters, en laat die vereiste interdienstes in die aanstuurbeleid toe. Hou ICMPv6 Packet Too Big-boodskappe bruikbaar, want om hulle te laat val, breek pad-MTU-ontdekking en veroorsaak groot-oordragstilstande wat soos toepfoute lyk. 'n Hub wat aanstuur sonder die firewalltoelating, laat die pakket tussen routering en die tonnel val. Daardie foutmodus is die moeite werd om te ken, want die tonnel bly op en net sommige vloeie sterf.

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

Toets van 'n gasheer in Terrein A na 'n gasheer in Terrein B en dan in die teenoorgestelde rigting. 'n Ping na die hub se tonneladres oefen net die eerste sprong en sal slaag selfs wanneer die LAN-roetes verkeerd is. Die gasheer-tot-gasheer-vloei is die een wat die plan bewys.

Die buitenste WireGuard-verbinding kan oor IPv4 loop terwyl die binneste verkeer IPv6 is, en daardie onafhanklikheid is nuttig tydens migrasie. As globale IPv6-uitgang later bygevoeg word, hersien die verskaffer-toekenning, bronadreskeuse en terugroetering as 'n nuwe ontwerpstap; die private plan hierbo bly geldig vir terrein-tot-terrein-verkeer.