Por que a súa interface VPN non deixa de saír da súa zona de firewalld

Engade tun0 á zona correcta, a aplicación comeza a funcionar e a corrección evapórase na seguinte reconexión. Executar o mesmo comando outra vez funciona, o que fai parecer que firewalld o esqueceu. Non o esqueceu; algo cun dereito máis forte sobre esa interface reasignouna.

A zona sobrevive ata que a interface se volve crear

A asignación dunha zona de firewalld a unha interface é unha vinculación, e as vinculacións están ligadas ao obxecto da interface tal como existe agora. Un cliente VPN que destrúe o dispositivo e o volve crear produce un obxecto novo, e o novo parte do que di o compoñente que asigna. Por iso o síntoma repítese en cada reconexión e non en cada paquete.

A mesma lóxica explica o comportamento ao reiniciar: as vinculacións en tempo de execución non sobreviven a un reinicio, e as vinculacións permanentes só se aplican a dispositivos que firewalld cre que posúe.

Antes de cambiar nada, aclare que compoñente asigna a zona.

Lea tres cousas antes de cambiar nada

Anote a zona que ten agora a interface, as zonas activas coas súas interfaces e a lista permanente de interfaces da zona que pretende. Execute esas consultas antes do cambio, despois dunha reconexión e despois dun reinicio. Comparar os tres resultados dille se a vinculación se substitúe, se ignora ou só se aplica tarde. Se a lista permanente xa nomea o dispositivo mentres a zona en tempo de execución non coincide, algo está a pasar por riba da súa edición.

Anote tamén o nome real do dispositivo en cada paso, porque un túnel que hoxe aterra en tun0 mañá pode aterrar en tun1.

Unha vinculación gardada a un nome xenérico non é unha comprobación de identidade, e dous minutos de anotacións aforran unha hora de conxecturas.

Cando NetworkManager é o dono da conexión

Se NetworkManager xestiona a conexión VPN, o seu perfil leva a zona e pásalla a firewalld cando a conexión se activa. Entón pode ignorarse unha vinculación permanente de interface de firewalld para o mesmo dispositivo, porque NetworkManager é o dono. Fixe a zona na conexión e confirme que edita o perfil VPN e non unha conexión física non relacionada ou un rexistro temporal.

Cambiar esa propiedade pode afectar de inmediato unha conexión activa.

Manteña dispoñible unha ruta de administración e lea a política da zona de destino antes de aplicala. Editar o campo ZONE dun ficheiro ifcfg só é correcto alí onde ese ficheiro segue a ser a fonte de configuración.

Cando firewalld é o dono da vinculación

Para un túnel independente cun nome de interface deliberadamente estable, un cambio permanente de interface é a ferramenta correcta. Aplíqueo mediante a recarga ou o ciclo de vida que use o seu despregamento, e despois inspeccione o estado en tempo de execución, porque unha edición só permanente describe a intención e non o que está activo. Ambos poden discrepar todo o tempo que tarda unha recarga.

Se o nome da interface é dinámico, manteña a asignación durante o ciclo de vida da conexión en lugar de competir co túnel que reclame o nome primeiro.

Non bote a interface a trusted só para que a aplicación funcione.

Probe a recarga, a reconexión e o reinicio

Un cambio só está rematado cando sobrevive ás tres probas.

Recargue primeiro, porque alí desaparecen as edicións só en tempo de execución. Logo reconecte o túnel, porque alí unha interface substituída perde a súa vinculación. Logo reinicie, porque alí finalmente se manifesta un desaxuste de dono. Anote a zona en cada etapa e compárea coa intención que escribiu, e sinale que paso produciu a diferenza.

Se a zona é correcta e a aplicación segue fallando, o problema son as regras da zona ou unha clasificación por orixe, non a pertenza. A documentación de firewalld sobre conexións e interfaces é a referencia de como debe funcionar a propiedade.

Escriba o dono, o valor e o resultado esperado no runbook, e a próxima reasignación será explicable.