Por que sua interface VPN não para de sair da zona do firewalld

Você adiciona tun0 à zona correta, a aplicação começa a funcionar, e a correção evapora na próxima reconexão. Executar o mesmo comando de novo funciona, o que faz parecer que o firewalld esqueceu. Ele não esqueceu; algo com um direito mais forte sobre essa interface a reatribuiu.

A zona sobrevive até a interface ser recriada

A atribuição de uma zona do firewalld a uma interface é uma vinculação, e as vinculações estão presas ao objeto da interface como ele existe agora. Um cliente VPN que destrói o dispositivo e o recria produz um objeto novo, e o novo começa pelo que o componente que atribui diz. Por isso o sintoma se repete a cada reconexão e não a cada pacote.

A mesma lógica explica o comportamento na reinicialização: vinculações de execução não sobrevivem a um reinício, e vinculações permanentes só valem para dispositivos que o firewalld acredita possuir.

Antes de mudar qualquer coisa, descubra qual componente atribui a zona.

Leia três coisas antes de mudar qualquer coisa

Anote a zona que a interface tem agora, as zonas ativas com suas interfaces e a lista permanente de interfaces da zona que você pretende. Execute essas consultas antes da mudança, depois de uma reconexão e depois de uma reinicialização. Comparar os três resultados diz se a vinculação está sendo substituída, ignorada ou apenas aplicada tarde. Se a lista permanente já nomeia o dispositivo enquanto a zona de execução discorda, algo está passando por cima da sua edição.

Anote também o nome real do dispositivo em cada etapa, porque um túnel que hoje pousa em tun0 amanhã pode pousar em tun1.

Uma vinculação salva a um nome genérico não é verificação de identidade, e dois minutos de anotação economizam uma hora de suposição.

Quando o NetworkManager é dono da conexão

Se o NetworkManager gerencia a conexão VPN, o perfil dele carrega a zona e a passa ao firewalld quando a conexão se ativa. Uma vinculação permanente de interface no firewalld para o mesmo dispositivo pode então ser ignorada, porque o NetworkManager é o dono. Defina a zona na conexão, e confirme que você edita o perfil VPN e não uma conexão física não relacionada ou um registro temporário.

Mudar essa propriedade pode afetar uma conexão ativa imediatamente.

Mantenha um caminho de administração disponível e leia a política da zona de destino antes de aplicá-la. Editar o campo ZONE de um arquivo ifcfg só é correto onde esse arquivo ainda é a fonte de configuração.

Quando o firewalld é dono da vinculação

Para um túnel independente com um nome de interface deliberadamente estável, uma mudança permanente de interface é a ferramenta certa. Aplique-a pela recarga ou pelo ciclo de vida que seu deployment usa, e depois inspecione o estado de execução, porque uma edição só permanente descreve a intenção e não o que está ativo. Os dois podem discordar por todo o tempo que uma recarga leva.

Se o nome da interface é dinâmico, mantenha a atribuição ao longo do ciclo de vida da conexão em vez de correr atrás do túnel que reivindica o nome primeiro.

Não jogue a interface em trusted só para fazer a aplicação funcionar.

Teste a recarga, a reconexão e a reinicialização

Uma mudança só está concluída quando sobrevive às três.

Recarregue primeiro, porque é onde as edições só de execução desaparecem. Depois reconecte o túnel, porque é onde uma interface substituída perde sua vinculação. Depois reinicie, porque é onde um descompasso de dono finalmente aparece. Anote a zona em cada estágio e compare com a intenção que você escreveu, e registre qual etapa produziu a diferença.

Se a zona está correta e a aplicação ainda falha, o problema são as regras da zona ou uma classificação baseada em origem, não o pertencimento. A documentação do firewalld sobre conexões e interfaces é a referência de como a propriedade deve funcionar.

Escreva o dono, o valor e o resultado esperado no runbook, e a próxima reatribuição será explicável.