A saída IPv6 morre tras reiniciar OpenVPN: comprobe a propiedade do prefixo
IPv6 morre cando se recrea o túnel. Decida quen posúe o prefixo delegado, os enderezos dos clientes e a ruta de retorno antes de reiniciar nada.
IPv6 deixa de pasar tráfico no momento en que OpenVPN se reinicia, e IPv4 segue funcionando. A interface do túnel recreouse, e algo máis que xestionaba o seu estado IPv6 perdeu o enderezo ou perdeu a ruta que fai alcanzable o prefixo. Hai tres pezas de estado separadas e cada unha ten un propietario distinto: o prefixo delegado do provedor e a súa vida útil, os enderezos entregados aos clientes VPN e a ruta ascendente que devolve ese prefixo de cliente ao servidor. Identifique o propietario de cada peza antes de tocar ningún demo, porque reiniciar o equivocado agocha o problema durante un día e devólveo na seguinte reconexión.
Tres pezas de estado IPv6, tres propietarios
| 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 enderezo con ámbito global dentro do túnel non abonda por si só. Os routers ascendentes seguen tendo que enviar ese prefixo de volta cara ao servidor VPN, e non o farán porque o servidor teña un enderezo del por casualidade.
Por iso tamén é arriscado copiar un /64 público nun conxunto de túnel. Un prefixo encamiñado ao servidor non é o mesmo que un prefixo que o ascendente trata como on-link, e o descubrimento de veciños non encherá ese oco.
Lea o estado do servidor antes de cambiar nada
Capture o estado dúas veces, unha mentres IPv6 funciona e outra despois do reinicio, e logo compare. As vistas de só lectura abondan e non custan nada durante unha ventá de mantemento:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingBusque tres diferenzas concretas: unha ruta que desapareceu, un enderezo que pasou a unha vida útil obsoleta ou non válida, e un prefixo que cambiou tras unha redelegación mentres a configuración VPN aínda anuncia o vello.
Se o enderezo desapareceu pero o prefixo non cambiou, o demo que o asigna deixou de xestionar a interface. Se o prefixo cambiou pero os enderezos non, a configuración do cliente está obsoleta. Os dous fallos vense idénticos desde un navegador e non teñen nada en común.
Decida se dhcpcd debe xestionar o túnel
dhcpcd pode descubrir interfaces e delegar partes dun prefixo DHCPv6 a interfaces descendentes, e a súa configuración pode nomear explicitamente os destinos de delegación. Sen un destino explícito, o seu comportamento documentado pode implicar outras interfaces, e así é como un túnel acaba cun enderezo que ninguén planificou.
Dúas condicións deberían empurrarlle a deixar que OpenVPN posúa o enderezamento estático do túnel: o servidor empurra enderezos fixos na súa configuración, e o nome do túnel cambia ao reconectar. Se se cumpren ambas, exclúa o túnel do demo de delegación a propósito, cun comentario que diga por que.
Se, en cambio, a delegación ao túnel é deliberada, implemente o tratamento do cambio de prefixo. Iso significa reaccionar cando o prefixo delegado ou a súa vida útil cambian, actualizar o prefixo de cliente que anuncia o servidor e volver engadir a ruta. Excluír a interface nese deseño elimina o único compoñente que coñece o prefixo novo.
Reiniciar dhcpcd pode parecer que arranxa as cousas porque recrea estado, pero tamén renova ou retira configuración de interfaces nas que non estaba pensando. Ese restablecemento non o converte nun requisito tras cada reinicio de VPN. Tamén reinicia os contadores que estaba usando como proba. Prefira unha recarga dirixida da interface que realmente cambiou.
Valide IPv6 por separado do NAT de IPv4
Confirme que o reenvío está activado e que a ruta ascendente apunta ao prefixo de cliente real, e logo faga unha conexión IPv6 permitida nova. Revise tamén a táboa de rutas IPv6 do propio cliente, porque un cliente que mostra un enderezo público non demostra que a súa petición usase o túnel.
A máscara IPv4 resolve outro problema: o camiño de retorno para fontes privadas. Non fai nada por un prefixo IPv6 retirado, e engadilo non devolverá IPv6.
Remate co rexistro de propiedade: que compoñente delega o prefixo, cal asigna os enderezos dos clientes, cal mantén a ruta de retorno e que lle acontece a cada un ao reconectar. Catro liñas nun runbook aforran á seguinte persoa reiniciar tres demos para atopar o que importaba.