Pourquoi votre interface VPN quitte sans cesse sa zone firewalld

Vous ajoutez tun0 à la bonne zone, l’application se met à fonctionner, et la correction s’évapore à la reconnexion suivante. Relancer la même commande fonctionne, ce qui donne l’impression que firewalld a oublié. Il n’a pas oublié ; quelque chose de plus fort sur cette interface l’a réassignée.

La zone survit jusqu’à ce que l’interface soit recréée

L’attribution d’une zone firewalld à une interface est une liaison, et les liaisons sont liées à l’objet interface tel qu’il existe maintenant. Un client VPN qui détruit l’appareil et le recrée produit un nouvel objet, et le nouveau part de ce que dit le composant qui attribue. C’est pourquoi le symptôme se répète à chaque reconnexion et non à chaque paquet.

La même logique explique le comportement au redémarrage : les liaisons d’exécution ne survivent pas à un redémarrage, et les liaisons permanentes ne s’appliquent qu’aux appareils que firewalld croit posséder.

Avant de changer quoi que ce soit, déterminez quel composant attribue la zone.

Lisez trois choses avant de changer quoi que ce soit

Notez la zone que l’interface possède actuellement, les zones actives avec leurs interfaces, et la liste permanente d’interfaces de la zone visée. Exécutez ces requêtes avant le changement, après une reconnexion et après un redémarrage. Comparer les trois résultats vous dit si la liaison est remplacée, ignorée ou simplement appliquée tard. Si la liste permanente nomme déjà l’appareil alors que la zone d’exécution n’est pas d’accord, quelque chose outrepasse votre modification.

Notez aussi le nom réel de l’appareil à chaque étape, car un tunnel qui atterrit aujourd’hui sur tun0 peut atterrir demain sur tun1.

Une liaison enregistrée vers un nom générique n’est pas un contrôle d’identité, et deux minutes de relevé épargnent une heure de suppositions.

Quand NetworkManager possède la connexion

Si NetworkManager gère la connexion VPN, son profil porte la zone et la transmet à firewalld lorsque la connexion s’active. Une liaison d’interface permanente de firewalld pour le même appareil peut alors être ignorée, car NetworkManager est le propriétaire. Définissez la zone sur la connexion, et confirmez que vous modifiez le profil VPN et non une connexion physique sans rapport ou un enregistrement temporaire.

Modifier cette propriété peut affecter immédiatement une connexion active.

Gardez un chemin d’administration disponible et lisez la politique de la zone de destination avant de l’appliquer. Modifier le champ ZONE d’un fichier ifcfg n’est correct que là où ce fichier est encore la source de configuration.

Quand firewalld possède la liaison

Pour un tunnel autonome doté d’un nom d’interface volontairement stable, une modification permanente de l’interface est le bon outil. Appliquez-la via le rechargement ou le cycle de vie qu’utilise votre déploiement, puis inspectez l’état d’exécution, car une modification seulement permanente décrit l’intention et non ce qui est actif. Les deux peuvent diverger aussi longtemps que dure un rechargement.

Si le nom de l’interface est dynamique, maintenez l’attribution pendant le cycle de vie de la connexion au lieu de courir après le tunnel qui revendique le nom en premier.

Ne jetez pas l’interface dans trusted juste pour faire fonctionner l’application.

Testez le rechargement, la reconnexion et le redémarrage

Une modification n’est terminée que lorsqu’elle survit aux trois.

Rechargez d’abord, car c’est là que disparaissent les modifications d’exécution seulement. Reconnectez ensuite le tunnel, car c’est là qu’une interface remplacée perd sa liaison. Redémarrez ensuite, car c’est là qu’un désaccord de propriétaire finit par apparaître. Notez la zone à chaque étape et comparez-la à l’intention que vous avez écrite, et indiquez quelle étape a produit la différence.

Si la zone est correcte et que l’application échoue encore, le problème vient des règles de la zone ou d’une classification par source, et non de l’appartenance. La documentation firewalld sur les connexions et les interfaces est la référence pour la façon dont la propriété est censée fonctionner.

Écrivez le propriétaire, la valeur et le résultat attendu dans le runbook, et la prochaine réattribution sera explicable.