IPv6 attraverso un tunnel OpenVPN: percorso nel router di casa

Il portatile ha un indirizzo IPv6, il tunnel è attivo su IPv4 e, ciononostante, ogni test IPv6 fallisce. O peggio: il test riesce e il traffico è uscito dal percorso del provider senza mai entrare nel tunnel. Entrambi gli esiti rimandano a una decisione mancante: nessuno ha dato al router un prefisso che potesse instradare verso i client. Percorrere il cammino dal client verso l’esterno scopre quale pezzo manca.

Parti da dove si trova il client

Guarda il client prima di toccare il server. ip -6 addr dovrebbe mostrare un indirizzo di tunnel dal pool, e ip -6 route dovrebbe mostrare il prefisso spinto che punta al dispositivo di tunnel. Quando l’indirizzo c’è ma la rotta no, manca il push o il client l’ha ignorato. Quando non c’è nessuno dei due, il server non ha assegnato proprio nulla.

Poi controlla cosa crede il client del mondo esterno. Una rotta predefinita sul tunnel rivendica tutto il traffico IPv6, mentre una rotta per 2000::/3 rivendica solo l’unicast globale. Entrambe possono essere corrette e rispondono a domande diverse sulle perdite.

Un client senza alcuna rotta predefinita IPv6 fallisce ogni test pubblico mentre il tunnel stesso è perfettamente sano. È un buco di politica, non un tunnel rotto.

Controlla il pool che il server può davvero instradare

Un server può assegnare solo da un prefisso che controlla davvero. Se il provider delega un /56, riserva un /64 al tunnel e lascia il resto alla LAN. Dove il provider consegna un solo /64 sulla WAN e non instrada altro, lascia in pace il prefisso della LAN e dai al tunnel un intervallo locale unico, accettando che i client non avranno un’uscita globale.

Il pool e il push vanno insieme. server-ipv6 2001:db8:80:10::/64 assegna indirizzi e push "route-ipv6 2000::/3" dice ai client cosa inviare nel tunnel. Spingere 2000::/3 copre l’unicast globale e lascia gli intervalli link-local e multicast fuori dal tunnel.

Scrivi il prefisso scelto nel registro di distribuzione. Chi la prossima volta cambierà la consegna del provider deve sapere quale /64 il tunnel occupa già.

Attiva l’inoltro per la seconda famiglia

L’inoltro IPv4 non implica l’inoltro IPv6. Imposta net.ipv6.conf.all.forwarding=1 e rispecchia tutto ciò che la politica FORWARD di IPv4 già permette. Su un router la cui catena FORWARD scarta per impostazione predefinita, un insieme di regole assente sembra esattamente un tunnel morto.

La stretta di mano riesce, il client riceve un indirizzo e non torna nulla. Aggiungi regole per entrambe le direzioni e per il tratto WAN, perché un tunnel che raggiunge la LAN ma non Internet fallisce il terzo test. Dopo un tentativo fallito guarda i contatori della catena, perché una regola che non ha mai corrisposto è un problema diverso da una che ha corrisposto e scartato.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Un effetto collaterale coglie chi finisce per dare la colpa al tunnel. Attivare l’inoltro fa sì che il kernel salti la configurazione dell’indirizzo tramite Router Advertisement, salvo diversa indicazione, e una rotta predefinita appresa così sparisce con essa. O appunta una rotta predefinita esplicita sull’interfaccia WAN, oppure imposta lì accept_ra a 2 di proposito. Dopo l’uno o l’altro cambiamento, conferma che il router abbia ancora un percorso IPv6 utilizzabile verso l’esterno prima di ritestare i client.

Rispondi alla scoperta dei vicini quando l’upstream non instrada

L’apparecchiatura a monte a volte tratta il /64 delegato come appartenente al proprio collegamento e rifiuta di instradare qualsiasi sottoprefisso verso la scatola VPN. Quando succede, qualcosa deve rispondere alle richieste dei vicini per ogni indirizzo di client singolarmente.

OpenVPN espone l’indirizzo assegnato a un hook client-connect, così le voci possono seguire il pool reale invece di una lista mantenuta a mano. L’hook aggiunge ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, e un hook client-disconnect corrispondente lo rimuove. Senza quella rimozione la tabella proxy invecchia e un client successivo può ereditare una voce per un indirizzo che non ha mai ricevuto. Conferma lo stato con ip -6 neigh show proxy.

Tratta il proxying come una soluzione tampone. Una rotta statica per il /64 del tunnel puntata al router sopravvive ai cambi di client e non richiede alcun hook di shell privilegiato.

Segui il percorso verso l’esterno, salto dopo salto

Prova verso l’esterno in tre passi: prima l’indirizzo di tunnel del router, poi un host della LAN e terzo una destinazione pubblica con traceroute6. Il pool è dimostrato dal primo, l’inoltro e il firewall della LAN dal secondo, e il percorso di ritorno attraverso l’upstream dal terzo. Ogni fallimento restringe la ricerca a un solo dispositivo invece di riaprire tutto il progetto.

Tieni d’occhio l’MTU del tunnel, perché i router IPv6 lungo il percorso non frammenteranno per te. Un MTU troppo grande si manifesta come errore packet-too-big e TLS bloccato invece che come fallimento netto. Impostalo esplicitamente e prova con un carico vicino al limite.