Dividere il vostro /64 non instrada IPv6 verso i client VPN

Il client mostra un indirizzo IPv6 globale, la stretta di mano è completata e nulla torna da internet. L'impostazione del pool sembra corretta perché lo è; l'indirizzo è valido e il tunnel lo trasporta. Ciò che fallisce è la consegna, e la consegna dipende da una decisione presa a monte del server VPN che nessuna configurazione lato client può influenzare.

Il mito: una parte del vostro /64 è già raggiungibile

La storia è accattivante: il server ha un /64 pubblico, tagliatelo a metà, date l'altra metà al pool VPN e quei client sono ora su internet. Dividere il prefisso alloca davvero indirizzi senza collisioni. Non cambia però come la rete upstream decide dove deve andare un pacchetto diretto a uno di quegli indirizzi.

IPv6 non ha uno strato di traduzione predefinito su cui appoggiarsi, quindi il percorso di ritorno deve esistere come instradamento o come consegna a livello di collegamento. Un pacchetto indirizzato all'indirizzo del tunnel di un client arriva al router upstream, e quel router prende una decisione di inoltro dalla propria tabella. Se la tabella punta al collegamento fisico, il pacchetto va lì, qualunque cosa creda il vostro server VPN.

Questo è l'intero guasto: la direzione di andata funziona perché il vostro server la invia, e la direzione di ritorno muore a un salto di distanza perché l'upstream non ha mai saputo che il client esiste.

Che cosa richiede davvero la consegna sul collegamento

Quando l'upstream considera l'intero /64 sul collegamento fisico, risolve ogni indirizzo di destinazione con la scoperta dei vicini. Invia una richiesta su quel collegamento e si aspetta che il proprietario dell'indirizzo risponda. Un client VPN dietro un tunnel non è su quel collegamento e non può rispondere, quindi la richiesta resta senza risposta e il pacchetto viene scartato.

Ritagliare un /65 non cambia questa aspettativa. L'upstream tratta ancora l'intervallo come sul collegamento, perché l'unica cosa che gli farebbe cambiare idea è una rotta o un proxy che risponde per conto del client. Nessuno dei due compare perché avete modificato una configurazione VPN. È proprio questo divario a spiegare perché un pool può funzionare perfettamente tra i suoi client e restare comunque irraggiungibile da ogni altro luogo.

La scoperta dei vicini tramite proxy è il meccanismo che può collegare i due mondi. Il gateway risponde alle richieste per gli indirizzi client specifici che possiede e inoltra il traffico nel tunnel. Funziona, e deve essere limitato esattamente a quegli indirizzi con un ciclo di vita che segue il pool, perché rispondere per un indirizzo che non servite più trasforma il traffico di qualcun altro in un buco nero. Alcuni upstream non accetteranno risposte proxy che non si aspettavano, quindi questo progetto necessita anche dell'accordo del provider.

Che cosa richiede la consegna instradata

Il progetto più pulito è un'assegnazione che l'upstream instrada davvero verso il vostro gateway. Può essere un prefisso delegato o una rotta statica per un blocco più piccolo, e il requisito è lo stesso in entrambi i casi: la tabella dell'upstream deve puntare al vostro server per l'intervallo client. Allora il traffico di ritorno arriva al gateway e il gateway lo inoltra nel tunnel.

La consegna instradata elimina del tutto la questione della scoperta dei vicini, ed è per questo che vale la pena chiederla al provider prima di costruire qualcosa di ingegnoso. Chiedete la rotta per iscritto e confermate che il salto successivo è l'indirizzo che l'upstream può realmente raggiungere.

Entrambi i progetti necessitano ancora dell'inoltro IPv6 abilitato sul gateway e di regole del firewall che consentano il flusso inoltrato in entrambe le direzioni. La consegna è un prerequisito, non un sostituto, per il resto del percorso. Una rotta funzionante con l'inoltro disattivato produce esattamente lo stesso silenzio di una rotta mancante, quindi verificate entrambe prima di riprogettare qualcosa.

Due rotte indipendenti da azzeccare

Il prefisso del pool e la rotta predefinita del client sono impostazioni separate, e confonderle produce connettività parziale che sembra un tunnel rotto. Il pool dice al server quali indirizzi assegnare. Le rotte del client decidono verso quali destinazioni il client invia traffico nel tunnel, se ne invia.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Il prefisso qui sopra è spazio di documentazione, e il reindirizzamento vale solo per IPv6, che è esattamente ciò che spesso vuole un deployment dual-stack mentre la consegna IPv6 è ancora in fase di correzione. Un reindirizzamento IPv4 non stabilisce copertura IPv6, e nessuna delle due impostazioni implica l'altra.

Mantenete funzionante il traffico di controllo da cui dipende IPv6 con qualunque politica applicate. I messaggi Packet Too Big sono la vittima classica di un firewall che consente solo TCP e UDP, e scartarli produce connessioni che si stabiliscono e poi si bloccano sui trasferimenti più grandi.

Gli annunci del router sono la terza parte mobile. Se il gateway inizia ad annunciare sul collegamento ascendente, può cambiare ciò che client e vicini credono sui prefissi sul collegamento, e questo può annullare silenziosamente il progetto che avete appena documentato.

Documentate il progetto perché una ricostruzione lo riproduca

Annotate tre oggetti separatamente: l'assegnazione del client, la rotta di destinazione del client e il metodo di consegna dell'upstream per l'assegnazione. Un lettore che ha tutti e tre può ricostruire il deployment; un lettore che ha solo l'impostazione del pool riprodurrà il bug originale.

Poi provate esplicitamente la direzione di ritorno, con un pacchetto che deve tornare dall'esterno. Il manuale di openvpn(8) copre le opzioni server-ipv6 e redirect, e la conferma di instradamento del vostro provider copre la metà che il manuale non può.