Mantenga estable la política de nftables mientras llega la interfaz VPN

Los túneles son desechables; la política no debería serlo. En una puerta de enlace Linux, una regla de nftables que coincide con la interfaz del túnel por nombre se puede cargar una vez y sigue aplicándose cada vez que esa interfaz aparece. La interfaz sigue teniendo un ciclo de vida: se crea, desaparece, y las rutas y traducciones a su alrededor siguen su propio calendario. Separar esos propietarios es lo que mantiene el acceso estable durante una reconexión.

Una coincidencia por nombre sobrevive a la interfaz

nftables ofrece coincidencias numéricas por índice de interfaz y las coincidencias dinámicas por nombre iifname y oifname. Las reglas que usan esos nombres se cargan limpiamente incluso cuando el dispositivo del túnel aún no se ha creado, que es justo lo que necesita un conjunto de reglas al arrancar. Deja de coincidir si la interfaz se renombra y se reanuda cuando una interfaz nueva toma ese nombre. Un índice numérico carece de esa propiedad, por eso la forma con nombre es la opción habitual para un túnel.

El nombre es una clave de coincidencia, no una prueba de quién está al otro lado. La autenticación del par sigue siendo tarea de la VPN.

Lea la cadena antes de añadir reglas

Mire qué contiene ahora el conjunto de reglas y dónde quedaría una regla nueva, porque el orden decide el resultado.

nft list ruleset
nft -c -f /etc/nftables.conf

El listado muestra cadenas, reglas y handles, y el modo de comprobación valida un archivo candidato sin cargarlo. Un permiso solo para el túnel colocado después de una aceptación anterior para el mismo flujo no cambia nada, porque gana la primera regla que coincide. Por eso una regla tardía puede parecer correcta y no tener ningún efecto. Lea la cadena en orden y confirme que la denegación del tráfico del cliente hacia el enlace ascendente sigue precediendo a cualquier cosa más amplia.

Las rutas, la traducción y los flujos tienen otros propietarios

La presencia de la interfaz no crea rutas y no autentica al par. Eso corresponde al gestor de la VPN, mientras que la traducción tiene un tercer ciclo de vida.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

El listado de conntrack muestra los flujos existentes con sus valores originales y traducidos, y el listado de rutas muestra lo que el gestor instaló para la interfaz. Las reglas NAT establecen el estado de seguimiento de conexión en el primer paquete, así que un flujo establecido conserva su traducción incluso después de que cambie la regla. Por eso una regla que se actualiza y un flujo que usa la ruta nueva son afirmaciones distintas. Decida qué sesiones deben reconectarse y deje en paz los flujos no relacionados.

Acepte el arranque en frío, la pérdida y la recuperación

Pruebe la puerta de enlace con el túnel ausente al arrancar, luego presente y después tras una caída y un retorno. Confirme que el reenvío prohibido sigue denegado mientras falta el túnel, que un flujo permitido nuevo funciona una vez autenticado el par y que la recuperación no exige vaciar estado no relacionado. No borre toda la cadena POSTROUTING ni cada entrada de conntrack como acción de parada de un perfil, porque otros servicios las comparten. Anote qué componente cambió la interfaz, la ruta y la política, en lugar de solo que un gancho de arranque salió con cero.

Una política que sobrevive a una reconexión es aquella cuyos propietarios están nombrados y cuyas reglas se probaron con el túnel tanto caído como levantado. Un gancho que informa de éxito solo demuestra que el gancho se ejecutó.