Pianificare IPv6 per un concentratore WireGuard a due sedi: prefisso, peer, rotte

Due LAN, un concentratore WireGuard e un piano di indirizzi IPv6 che deve rispondere a tre domande distinte: quale prefisso, quale indirizzo appartiene a ogni router e quale peer possiede quale sottorete. Un errore su una di esse produce un tunnel che fa la stretta di mano e non instrada nulla. Il piano seguente percorre un progetto privato a due sedi in quest’ordine. Deliberatamente non fornisce accesso a Internet tramite IPv6.

Decidete a cosa serve il prefisso

Un prefisso locale univoco da fd00::/8 è la scelta naturale quando l’obiettivo è la raggiungibilità privata tra sedi. Resta stabile indipendentemente da quale provider serve ogni sede e non viene annunciato nella tabella di routing globale, quindi non può far trapelare la numerazione interna su Internet.

La stessa proprietà è il limite. Un ULA non offre alcun percorso di ritorno pubblico, perché nessun provider a monte sa instradarlo verso il vostro gateway. Se il requisito include l’uscita Internet tramite IPv6, vi serve un’assegnazione da un provider che la instradi verso di voi, e questa è una decisione progettuale separata con la propria dimensione del prefisso.

Non date per scontato che ogni distribuzione necessiti di un /48. RFC 6177 si è allontanato da un’unica dimensione obbligatoria per la sede terminale, e la dimensione corretta dipende dal numero di reti che gestirete. Generate l’ULA con la procedura RFC 4193 invece di inventare un prefisso che anche un’altra organizzazione potrebbe usare. Scrivete il risultato nel piano degli indirizzi prima di configurare qualsiasi dispositivo, perché un prefisso che nessuno ha registrato è un prefisso che qualcuno riutilizzerà.

Dividete il prefisso in ruoli

L’esempio seguente usa fd7c:2e91:4a00::/48, e la tabella è organizzata per dove viene scritto ogni blocco, non per sede. Trattate i valori come un esempio e generate i vostri prima di distribuire qualsiasi cosa.

I blocchi LAN sono /64 perché lo SLAAC ordinario prevede un identificatore di interfaccia a 64 bit. Dividere una LAN in un blocco più piccolo rompe questa ipotesi sulla maggior parte degli host, e il costo operativo non vale il risparmio di indirizzi in un piano privato. Entrambi i blocchi LAN provengono dal centro del /48, lasciando libero l’intervallo basso per sedi successive.

Gli indirizzi del tunnel sono una riserva amministrativa, non una rete sul collegamento. Ogni interfaccia ne riceve una singola /128, così nessun host presuppone una sottorete condivisa sul tunnel e la scoperta dei vicini non gira dove non serve. Mantenete i ruoli disgiunti e registrateli nel piano degli indirizzi dell’organizzazione perché una sede successiva non riutilizzi un blocco.

Date a ogni router un indirizzo del tunnel

Assegnate una /128 per router e conservate le chiavi e gli endpoint esistenti del concentratore funzionante. I tre valori seguenti differiscono solo nella parte host.

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

Questa /128 descrive l’unico indirizzo assegnato a quell’interfaccia. Non dice nulla su quante destinazioni il peer può instradare, perché la raggiungibilità si esprime in AllowedIPs e non nel prefisso dell’interfaccia.

Ogni router di sede ha bisogno anche di un indirizzo nel proprio blocco LAN e di un modo per distribuirlo, di solito annunci del router per lo SLAAC. WireGuard non invia quegli annunci al posto vostro e non collega le due LAN. Il router di sede è un router in entrambe le direzioni.

Mettete la proprietà della sottorete in AllowedIPs

La voce peer del concentratore per la Sede A possiede l’indirizzo del tunnel di A e la LAN di A, e quella coppia è l’intera dichiarazione di proprietà. Nient’altro in quella sezione peer deve descrivere la sede.

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

La voce peer per la Sede B possiede la coppia corrispondente, e qui la simmetria conta più della brevità. Leggete le due righe insieme e la divisione di proprietà diventa visibile a colpo d’occhio.

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

Sono due sezioni peer separate, non due elenchi che competono per un solo peer. WireGuard usa AllowedIPs in entrambe le direzioni: sceglie il peer per una destinazione in uscita e rifiuta un pacchetto in ingresso la cui origine non corrisponde all’intervallo assegnato al peer che l’ha decifrato. Dare tutto il /48 a entrambi i peer disattiverebbe quel secondo controllo e confonderebbe quale sede possiede quale blocco. È questa distinzione che rende visibile un indirizzo di origine errato invece di accettarlo in silenzio.

Ogni sede ha bisogno solo delle destinazioni raggiungibili tramite il proprio peer del concentratore: la Sede A elenca l’indirizzo del concentratore, l’indirizzo del tunnel della Sede B e la LAN di B, e la Sede B elenca l’insieme reciproco. Gli elenchi sono asimmetrici di proposito, perché ogni router vede un lato diverso della topologia. Scrivete entrambi dal piano degli indirizzi e non dalla configurazione dell’altra sede, perché è così che un intervallo obsoleto sopravvive a una rinumerazione.

Con wg-quick, questi intervalli creano anche rotte. Con systemd-networkd o una configurazione manuale, aggiungete voi le rotte equivalenti; altrimenti il tunnel trasporta pacchetti che il kernel non vi invia mai.

Completate l’inoltro e provate entrambe le direzioni

Abilitate l’inoltro IPv6 sul concentratore e su entrambi i router di sede, e consentite i servizi necessari tra le sedi nella politica di inoltro. Mantenete utilizzabili i messaggi ICMPv6 Packet Too Big, perché scartarli rompe la scoperta dell’MTU del percorso e produce blocchi nei trasferimenti grandi che sembrano guasti applicativi. Un concentratore che inoltra senza il permesso del firewall scarta il pacchetto tra l’instradamento e il tunnel. Vale la pena conoscere questa modalità di guasto, perché il tunnel resta attivo e muoiono solo alcuni flussi.

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

Provate da un host della Sede A a un host della Sede B e poi nella direzione opposta. Un ping all’indirizzo del tunnel del concentratore esercita solo il primo salto e passerà anche quando le rotte LAN sono sbagliate. È il flusso host-to-host che dimostra il piano.

La connessione WireGuard esterna può passare su IPv4 mentre il traffico interno è IPv6, e questa indipendenza è utile durante la migrazione. Se in seguito si aggiunge l’uscita IPv6 globale, riesaminate l’assegnazione del provider, la selezione dell’indirizzo di origine e l’instradamento di ritorno come nuovo passo di progettazione; il piano privato sopra resta valido per il traffico tra sedi.