Planificarea IPv6 pentru un hub WireGuard cu două locații: prefix, parteneri, rute

Două LAN-uri, un hub WireGuard și un plan de adrese IPv6 care trebuie să răspundă la trei întrebări distincte: ce prefix, ce adresă aparține fiecărui router și care partener deține ce subrețea. O greșeală la oricare dintre ele produce un tunel care face strângerea de mână și nu rutează nimic. Planul de mai jos parcurge în această ordine un design privat cu două locații. În mod deliberat nu oferă acces la internet prin IPv6.

Decideți la ce folosește prefixul

Un prefix local unic din fd00::/8 este alegerea firească atunci când scopul este accesibilitatea privată între locații. Rămâne stabil indiferent de furnizorul care deservește fiecare locație și nu este anunțat în tabela de rutare globală, așa că nu poate scurge numerotarea internă în internet.

Aceeași proprietate este limitarea. O ULA nu oferă nicio cale de întoarcere publică, pentru că niciun furnizor superior nu știe să o ruteze către poarta dumneavoastră. Dacă cerința include ieșire la internet prin IPv6, aveți nevoie de o alocare de la un furnizor care o rutează către dumneavoastră, iar aceasta este o decizie de design separată, cu propria dimensiune a prefixului.

Nu presupuneți că fiecare implementare are nevoie de un /48. RFC 6177 s-a îndepărtat de o singură dimensiune obligatorie pentru locația finală, iar dimensiunea corectă depinde de numărul de rețele pe care le veți opera. Generați ULA cu procedura RFC 4193 în loc să inventați un prefix pe care l-ar putea folosi și altă organizație. Scrieți rezultatul în planul de adrese înainte de a configura orice dispozitiv, pentru că un prefix pe care nimeni nu l-a notat este un prefix pe care cineva îl va reutiliza.

Împărțiți prefixul în roluri

Exemplul de mai jos folosește fd7c:2e91:4a00::/48, iar tabelul este organizat după locul unde se scrie fiecare bloc, nu după locație. Tratați valorile ca pe un exemplu și generați-le pe ale dumneavoastră înainte de a implementa ceva.

Blocurile LAN sunt /64 pentru că SLAAC obișnuit așteaptă un identificator de interfață pe 64 de biți. Împărțirea unui LAN într-un bloc mai mic rupe această presupunere pe majoritatea gazdelor, iar costul operațional nu merită economisirea de adrese într-un plan privat. Ambele blocuri LAN provin din mijlocul /48, lăsând intervalul scăzut liber pentru locații ulterioare.

Adresele de tunel sunt un depozit administrativ, nu o rețea pe legătură. Fiecare interfață primește o singură /128 din el, așa că nicio gazdă nu presupune o subrețea partajată pe tunel și descoperirea vecinilor nu rulează unde nu este nevoie. Țineți rolurile disjuncte și înregistrați-le în planul de adrese al organizației, ca o locație ulterioară să nu reutilizeze un bloc.

Dați fiecărui router o adresă de tunel

Alocați o /128 pe router și păstrați cheile și punctele terminale existente ale hubului care funcționează. Cele trei valori de mai jos diferă doar în partea de gazdă.

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

Această /128 descrie unica adresă atribuită acelei interfețe. Nu spune nimic despre câte destinații poate ruta partenerul, pentru că accesibilitatea se exprimă în AllowedIPs, nu în prefixul interfeței.

Fiecare router de locație are nevoie și de o adresă în blocul său LAN și de o modalitate de a o distribui, de obicei anunțuri de router pentru SLAAC. WireGuard nu trimite acele anunțuri în locul dumneavoastră și nu puntează cele două LAN-uri. Routerul de locație este un router în ambele direcții.

Puneți proprietatea subrețelei în AllowedIPs

Intrarea de partener a hubului pentru Locația A deține adresa de tunel a A și LAN-ul A, iar acea pereche este întreaga declarație de proprietate. Nimic altceva din acea secțiune de partener nu trebuie să descrie locația.

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

Intrarea de partener pentru Locația B deține perechea corespunzătoare, iar simetria contează aici mai mult decât concizia. Citiți cele două linii împreună și împărțirea proprietății devine vizibilă dintr-o privire.

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

Acestea sunt două secțiuni de partener separate, nu două liste care concurează pentru un singur partener. WireGuard folosește AllowedIPs în ambele direcții: alege partenerul pentru o destinație de ieșire și respinge un pachet de intrare a cărui sursă nu corespunde intervalului atribuit partenerului care l-a decriptat. Dacă ați da întregul /48 ambilor parteneri, acea a doua verificare ar fi dezactivată și s-ar estompa care locație deține care bloc. Tocmai această distincție face ca o adresă de sursă greșită să fie vizibilă în loc să fie acceptată în tăcere.

Fiecare locație are nevoie doar de destinațiile accesibile prin partenerul său de hub: Locația A listează adresa hubului, adresa de tunel a Locației B și LAN-ul B, iar Locația B listează mulțimea inversă. Listele sunt asimetrice intenționat, pentru că fiecare router vede o altă latură a topologiei. Scrieți ambele din planul de adrese, nu din configurația celeilalte locații, pentru că astfel un interval învechit supraviețuiește unei renumerotări.

Cu wg-quick, aceste intervale creează și rute. Cu systemd-networkd sau o configurare manuală, adăugați singur rutele echivalente; altfel tunelul transportă pachete pe care nucleul nu le trimite niciodată în el.

Finalizați redirecționarea și testați ambele direcții

Activați redirecționarea IPv6 pe hub și pe ambii routere de locație și permiteți serviciile necesare între locații în politica de redirecționare. Păstrați mesajele ICMPv6 Packet Too Big utilizabile, pentru că eliminarea lor rupe descoperirea MTU a căii și produce blocaje la transferurile mari care arată ca defecte de aplicație. Un hub care redirecționează fără permisiunea paravanului aruncă pachetul între rutare și tunel. Acest mod de eșec merită cunoscut, pentru că tunelul rămâne activ și mor doar unele fluxuri.

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

Testați de la o gazdă din Locația A la o gazdă din Locația B și apoi în direcția opusă. Un ping către adresa de tunel a hubului exersează doar primul salt și va reuși chiar și când rutele LAN sunt greșite. Fluxul de la gazdă la gazdă este cel care dovedește planul.

Conexiunea WireGuard exterioară poate rula pe IPv4 în timp ce traficul interior este IPv6, iar această independență este utilă în timpul migrării. Dacă mai târziu se adaugă ieșire IPv6 globală, revedeți alocarea de la furnizor, selecția adresei de sursă și rutarea de retur ca un pas nou de design; planul privat de mai sus rămâne valabil pentru traficul între locații.