L’uscita IPv6 muore dopo un riavvio di OpenVPN: verificate la proprietà del prefisso
IPv6 muore dopo che il tunnel viene ricreato. Decidete chi possiede il prefisso delegato, gli indirizzi dei client e la rotta di ritorno prima di riavviare qualsiasi cosa.
IPv6 smette di far passare traffico nel momento in cui OpenVPN si riavvia, e IPv4 continua a funzionare. L’interfaccia del tunnel è stata ricreata, e qualcos’altro che gestiva il suo stato IPv6 ha perso l’indirizzo o la rotta che rende raggiungibile il prefisso. Sono coinvolti tre pezzi di stato separati, e ognuno ha un proprietario diverso: il prefisso delegato del provider e la sua durata, gli indirizzi assegnati ai client VPN e la rotta a monte che rimanda quel prefisso client al server. Identificate il proprietario di ciascuno prima di toccare un demone, perché riavviare quello sbagliato nasconde il problema per un giorno e lo riporta alla riconnessione successiva.
Tre pezzi di stato IPv6, tre proprietari
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
Un indirizzo con ambito globale dentro il tunnel non basta da solo. I router a monte devono comunque rimandare quel prefisso verso il server VPN, e non lo faranno perché il server ha per caso un indirizzo che ne deriva.
È anche per questo che copiare un /64 pubblico in un pool di tunnel è rischioso. Un prefisso instradato verso il server non è lo stesso di un prefisso che il monte tratta come on-link, e la scoperta dei vicini non colmerà questo vuoto.
Leggete lo stato del server prima di cambiare qualcosa
Catturate lo stato due volte, una mentre IPv6 funziona e una dopo il riavvio, poi confrontate. Le viste in sola lettura bastano e non costano nulla durante una finestra di manutenzione:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingCercate tre differenze precise: una rotta che è sparita, un indirizzo passato a una durata obsoleta o non valida, e un prefisso cambiato dopo una ridelegazione mentre la configurazione VPN annuncia ancora quello vecchio.
Se l’indirizzo è sparito ma il prefisso è invariato, il demone che lo assegna ha smesso di gestire l’interfaccia. Se il prefisso è cambiato ma gli indirizzi no, la configurazione del client è obsoleta. I due guasti sembrano identici dal browser e non hanno nulla in comune.
Decidete se dhcpcd deve gestire il tunnel
dhcpcd può scoprire interfacce e delegare parti di un prefisso DHCPv6 alle interfacce a valle, e la sua configurazione può nominare esplicitamente le destinazioni della delega. Senza una destinazione esplicita, il suo comportamento documentato può coinvolgere altre interfacce, ed è così che un tunnel finisce con un indirizzo che nessuno aveva pianificato.
Due condizioni dovrebbero spingervi a lasciare che OpenVPN possieda l’indirizzamento statico del tunnel: il server spinge indirizzi fissi nella sua configurazione, e il nome del tunnel cambia alla riconnessione. Se valgono entrambe, escludete il tunnel dal demone di delega deliberatamente, con un commento che spieghi perché.
Se invece la delega al tunnel è deliberata, implementate la gestione del cambio di prefisso. Significa reagire quando il prefisso delegato o la sua durata cambiano, aggiornare il prefisso client annunciato dal server e riaggiungere la rotta. Escludere l’interfaccia in quel progetto elimina l’unico componente che conosce il nuovo prefisso.
Riavviare dhcpcd può sembrare che sistemi le cose perché ricrea lo stato, ma rinnova o ritira anche la configurazione di interfacce a cui non pensavate. Quel recupero non lo rende un requisito dopo ogni riavvio VPN. Azzera anche i contatori che usavate come prova. Preferite un ricaricamento mirato dell’interfaccia che avete realmente modificato.
Validate IPv6 separatamente dal NAT IPv4
Confermate che l’inoltro è attivo e che la rotta a monte punta al prefisso client reale, poi stabilite una nuova connessione IPv6 consentita. Controllate anche la tabella di routing IPv6 del client stesso, perché un client che mostra un indirizzo pubblico non dimostra che la sua richiesta abbia usato il tunnel.
Il mascheramento IPv4 risolve un altro problema: il percorso di ritorno per sorgenti private. Non fa nulla per un prefisso IPv6 ritirato, e aggiungerlo non riporterà IPv6.
Chiudete con il registro di proprietà: quale componente delega il prefisso, quale assegna gli indirizzi dei client, quale detiene la rotta di ritorno, e cosa succede a ciascuno alla riconnessione. Quattro righe in un runbook risparmiano alla persona successiva il riavvio di tre demoni per trovare quello che contava.