La salida IPv6 muere tras reiniciar OpenVPN: compruebe la propiedad del prefijo
IPv6 muere cuando se recrea el túnel. Decida quién es dueño del prefijo delegado, de las direcciones de los clientes y de la ruta de retorno antes de reiniciar nada.
IPv6 deja de pasar tráfico en el momento en que OpenVPN se reinicia, e IPv4 sigue funcionando. La interfaz del túnel se recreó, y algo más que gestionaba su estado IPv6 perdió la dirección o perdió la ruta que hace alcanzable el prefijo. Hay tres piezas de estado separadas y cada una tiene un dueño distinto: el prefijo delegado del proveedor y su vida útil, las direcciones entregadas a los clientes VPN y la ruta ascendente que devuelve ese prefijo de cliente al servidor. Identifique al dueño de cada pieza antes de tocar ningún demonio, porque reiniciar el equivocado esconde el problema durante un día y lo devuelve en la siguiente reconexión.
Tres piezas de estado IPv6, tres dueños
| 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 dirección con ámbito global dentro del túnel no basta por sí sola. Los routers ascendentes siguen teniendo que enviar ese prefijo de vuelta hacia el servidor VPN, y no lo harán porque el servidor tenga una dirección de él por casualidad.
Por eso también es arriesgado copiar un /64 público en un grupo de túnel. Un prefijo enrutado al servidor no es lo mismo que un prefijo que el ascendente trata como on-link, y el descubrimiento de vecinos no llenará ese hueco.
Lea el estado del servidor antes de cambiar nada
Capture el estado dos veces, una mientras IPv6 funciona y otra después del reinicio, y luego compare. Las vistas de solo lectura bastan y no cuestan nada durante una ventana de mantenimiento:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingBusque tres diferencias concretas: una ruta que desapareció, una dirección que pasó a una vida útil obsoleta o no válida, y un prefijo que cambió tras una redelegación mientras la configuración VPN aún anuncia el viejo.
Si la dirección desapareció pero el prefijo no cambió, el demonio que la asigna dejó de gestionar la interfaz. Si el prefijo cambió pero las direcciones no, la configuración del cliente está obsoleta. Los dos fallos se ven idénticos desde un navegador y no tienen nada en común.
Decida si dhcpcd debe gestionar el túnel
dhcpcd puede descubrir interfaces y delegar partes de un prefijo DHCPv6 a interfaces descendentes, y su configuración puede nombrar explícitamente los destinos de delegación. Sin un destino explícito, su comportamiento documentado puede afectar a otras interfaces, y así es como un túnel acaba con una dirección que nadie planificó.
Dos condiciones deberían empujarle a dejar que OpenVPN sea dueño del direccionamiento estático del túnel: el servidor empuja direcciones fijas en su configuración, y el nombre del túnel cambia al reconectar. Si se cumplen ambas, excluya el túnel del demonio de delegación a propósito, con un comentario que diga por qué.
Si, en cambio, la delegación al túnel es deliberada, implemente el manejo del cambio de prefijo. Eso significa reaccionar cuando el prefijo delegado o su vida útil cambian, actualizar el prefijo de cliente que anuncia el servidor y volver a añadir la ruta. Excluir la interfaz en ese diseño elimina el único componente que conoce el prefijo nuevo.
Reiniciar dhcpcd puede parecer que arregla las cosas porque recrea estado, pero también renueva o retira configuración de interfaces en las que no estaba pensando. Esa recuperación no lo convierte en un requisito tras cada reinicio de VPN. También reinicia los contadores que estaba usando como prueba. Prefiera una recarga dirigida de la interfaz que realmente cambió.
Valide IPv6 por separado del NAT de IPv4
Confirme que el reenvío está activado y que la ruta ascendente apunta al prefijo de cliente real, y luego haga una conexión IPv6 permitida nueva. Revise también la tabla de rutas IPv6 del propio cliente, porque un cliente que muestra una dirección pública no demuestra que su petición usara el túnel.
El enmascaramiento IPv4 resuelve otro problema: el camino de retorno para fuentes privadas. No hace nada por un prefijo IPv6 retirado, y añadirlo no devolverá IPv6.
Cierre con el registro de propiedad: qué componente delega el prefijo, cuál asigna las direcciones de los clientes, cuál mantiene la ruta de retorno y qué le ocurre a cada uno al reconectar. Cuatro líneas en un runbook ahorran a la siguiente persona reiniciar tres demonios para encontrar el que importaba.