La sortida IPv6 mor després de reiniciar OpenVPN: comproveu la propietat del prefix
IPv6 mor després de recrear el túnel. Decidiu qui posseeix el prefix delegat, les adreces dels clients i la ruta de retorn abans de reiniciar res.
IPv6 deixa de passar trànsit en el moment que OpenVPN es reinicia, i IPv4 continua funcionant. La interfície del túnel s’ha recreat, i alguna altra cosa que gestionava el seu estat IPv6 ha perdut l’adreça o la ruta que fa arribar el prefix. Hi intervenen tres peces d’estat separades, i cada una té un propietari diferent: el prefix delegat del proveïdor i la seva vida útil, les adreces lliurades als clients VPN, i la ruta ascendent que retorna aquest prefix de client al servidor. Identifiqueu el propietari de cada peça abans de tocar cap dimoni, perquè reiniciar el que no toca amaga el problema durant un dia i el torna a la propera reconnexió.
Tres peces d’estat IPv6, tres propietaris
| 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 |
Una adreça d’àmbit global dins del túnel no n’hi ha prou tota sola. Els encaminadors ascendents encara han d’enviar aquest prefix cap al servidor VPN, i no ho faran pel fet que el servidor tingui una adreça d’aquell prefix.
Per això també és arriscat copiar un /64 públic dins d’un pool de túnel. Un prefix encaminat al servidor no és el mateix que un prefix que l’ascendent tracta com a on-link, i el descobriment de veïns no omplirà aquest buit.
Llegiu l’estat del servidor abans de canviar res
Captureu l’estat dues vegades, una mentre IPv6 funciona i una després del reinici, i compareu-los. Les vistes de només lectura són suficients i no costen res durant una finestra de manteniment:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingBusqueu tres diferències concretes: una ruta que ha desaparegut, una adreça que ha passat a una vida útil obsoleta o no vàlida, i un prefix que ha canviat després d’una redelegació mentre la configuració VPN encara anuncia el vell.
Si l’adreça ha desaparegut però el prefix no ha canviat, el dimoni que l’assigna ha deixat de gestionar la interfície. Si el prefix ha canviat però les adreces no, la configuració del client és obsoleta. Els dos errors semblen idèntics des d’un navegador i no tenen res en comú.
Decidiu si dhcpcd ha de gestionar el túnel
dhcpcd pot descobrir interfícies i delegar parts d’un prefix DHCPv6 a interfícies descendents, i la seva configuració pot anomenar explícitament els objectius de delegació. Sense un objectiu explícit, el seu comportament documentat pot implicar altres interfícies, i així és com un túnel acaba amb una adreça que ningú havia planificat.
Dues condicions us haurien d’empenyer a deixar que OpenVPN posseeixi l’adreçament estàtic del túnel: el servidor empeny adreces fixes a la seva configuració, i el nom del túnel canvia en reconectar. Si es compleixen totes dues, excloeu el túnel del dimoni de delegació deliberadament, amb un comentari que digui per què.
Si, en canvi, la delegació al túnel és deliberada, implementeu el tractament del canvi de prefix. Això vol dir reaccionar quan el prefix delegat o la seva vida útil canvien, actualitzar el prefix de client anunciat pel servidor i tornar a afegir la ruta. Excloure la interfície en aquest disseny elimina l’únic component que coneix el prefix nou.
Reiniciar dhcpcd pot semblar que arregla les coses perquè recrea estat, però també renova o retira configuració per a interfícies en què no pensàveu. Aquesta recuperació no el converteix en un requisit després de cada reinici de VPN. També reinicia els comptadors que feíeu servir com a prova. Preferiu una recàrrega dirigida de la interfície que heu canviat realment.
Valideu IPv6 per separat del NAT d’IPv4
Confirmeu que el reenviament està activat i que la ruta ascendent apunta al prefix de client real, i després feu una connexió IPv6 permesa nova. Reviseu també la taula de rutes IPv6 del mateix client, perquè un client que mostra una adreça pública no demostra que la seva petició hagi passat pel túnel.
L’emmascarament IPv4 resol un altre problema: el camí de retorn per a fonts privades. No fa res per a un prefix IPv6 retirat, i afegir-lo no farà tornar IPv6.
Acabeu amb el registre de propietat: quin component delega el prefix, quin assigna les adreces dels clients, quin manté la ruta de retorn i què passa amb cada un en reconectar. Quatre línies en un runbook estalvien a la propera persona haver de reiniciar tres dimonis per trobar el que importava.