Por qué su interfaz VPN no deja de salir de su zona de firewalld

Usted añade tun0 a la zona correcta, la aplicación empieza a funcionar y la corrección se evapora en la siguiente reconexión. Ejecutar el mismo comando otra vez funciona, lo que hace parecer que firewalld lo ha olvidado. No lo ha olvidado; algo con un derecho más fuerte sobre esa interfaz la ha reasignado.

La zona sobrevive hasta que la interfaz se vuelve a crear

La asignación de una zona de firewalld a una interfaz es una vinculación, y las vinculaciones están atadas al objeto de interfaz tal como existe ahora. Un cliente VPN que destruye el dispositivo y lo vuelve a crear produce un objeto nuevo, y el nuevo parte de lo que dice el componente que asigna. Por eso el síntoma se repite en cada reconexión y no en cada paquete.

La misma lógica explica el comportamiento al reiniciar: las vinculaciones en tiempo de ejecución no sobreviven a un reinicio, y las vinculaciones permanentes solo se aplican a dispositivos que firewalld cree que posee.

Antes de cambiar nada, averigüe qué componente asigna la zona.

Lea tres cosas antes de cambiar nada

Anote la zona que tiene ahora la interfaz, las zonas activas con sus interfaces y la lista permanente de interfaces de la zona que pretende usar. Ejecute esas consultas antes del cambio, después de una reconexión y después de un reinicio. Comparar los tres resultados le dice si la vinculación se sustituye, se ignora o solo se aplica tarde. Si la lista permanente ya nombra el dispositivo mientras la zona en tiempo de ejecución no coincide, algo está pasando por encima de su edición.

Anote también el nombre real del dispositivo en cada paso, porque un túnel que hoy aterriza en tun0 mañana puede aterrizar en tun1.

Una vinculación guardada a un nombre genérico no es una comprobación de identidad, y dos minutos de anotaciones ahorran una hora de conjeturas.

Cuando NetworkManager es el dueño de la conexión

Si NetworkManager gestiona la conexión VPN, su perfil lleva la zona y la pasa a firewalld cuando la conexión se activa. Entonces puede ignorarse una vinculación permanente de interfaz de firewalld para el mismo dispositivo, porque NetworkManager es el dueño. Fije la zona en la conexión y confirme que edita el perfil VPN y no una conexión física no relacionada o un registro temporal.

Cambiar esa propiedad puede afectar de inmediato a una conexión activa.

Mantenga disponible una ruta de administración y lea la política de la zona de destino antes de aplicarla. Editar el campo ZONE de un archivo ifcfg solo es correcto allí donde ese archivo sigue siendo la fuente de configuración.

Cuando firewalld es el dueño de la vinculación

Para un túnel independiente con un nombre de interfaz deliberadamente estable, un cambio permanente de interfaz es la herramienta correcta. Aplíquelo mediante la recarga o el ciclo de vida que use su despliegue, y luego inspeccione el estado en tiempo de ejecución, porque una edición solo permanente describe la intención y no lo que está activo. Ambos pueden discrepar todo el tiempo que tarda una recarga.

Si el nombre de la interfaz es dinámico, mantenga la asignación durante el ciclo de vida de la conexión en lugar de competir con el túnel que reclame el nombre primero.

No eche la interfaz a trusted solo para que la aplicación funcione.

Pruebe la recarga, la reconexión y el reinicio

Un cambio solo está terminado cuando sobrevive a las tres pruebas.

Recargue primero, porque allí desaparecen las ediciones solo en tiempo de ejecución. Luego reconecte el túnel, porque allí una interfaz sustituida pierde su vinculación. Luego reinicie, porque allí finalmente se manifiesta un desajuste de dueño. Anote la zona en cada etapa y compárela con la intención que escribió, y señale qué paso produjo la diferencia.

Si la zona es correcta y la aplicación sigue fallando, el problema son las reglas de la zona o una clasificación por origen, no la pertenencia. La documentación de firewalld sobre conexiones e interfaces es la referencia de cómo debe funcionar la propiedad.

Escriba el dueño, el valor y el resultado esperado en el runbook, y la próxima reasignación será explicable.