Paquet de pare-feu installé, règles disparues après le redémarrage

Le paquet s'est installé proprement, les règles ont été testées, et après le redémarrage suivant la passerelle était grande ouverte. Rien dans la transaction n'a échoué ; l'échec tenait à ce qu'on supposait persistant. Installer des outils de pare-feu, décider quelles règles doivent survivre et les restaurer au bon moment sont trois tâches distinctes.

Ce que le symptôme vous dit réellement

Un jeu de règles qui disparaît au redémarrage a l'un de trois responsables : rien ne l'a enregistré, autre chose l'a remplacé, ou il a été restauré avant que n'existe ce dont il dépend. Les deux premiers sont visibles dans la configuration ; le troisième n'apparaît que dans l'ordre. C'est pourquoi un redémarrage peut ressembler à une perte de données alors qu'il s'agit en réalité d'un problème de séquence.

Commencez par écrire ce qui était vrai avant le redémarrage : quel service détenait les règles, quel fichier ou base de données il lisait au démarrage, et si cette source avait déjà été écrite. Un jeu de règles actif que personne n'a enregistré est une explication valable et la plus fréquente.

Ne commencez pas par réinstaller le paquet.

Lisez l'outil de persistance avant de l'utiliser

Les outils Debian traitent la persistance comme un problème de greffons : chaque greffon sait écrire ses propres règles, et un enrobage les appelle. Son action d'enregistrement stocke tout ce qui est chargé à cet instant, et son action de démarrage recharge cet instantané. Rien dans l'une ou l'autre action ne vérifie ce qu'elle stocke.

C'est un instantané, pas une revue. Une autorisation oubliée d'une session de débogage, une expérimentation inachevée ou une règle permissive insérée par un autre assistant deviennent toutes permanentes aux côtés de la politique que vous vouliez conserver. Enregistrer un état et approuver un état sont deux activités différentes, et une seule exige du jugement. Lisez d'abord le jeu chargé, puis décidez quelles lignes méritent de survivre.

Enregistrez délibérément, après avoir lu ce qui est chargé.

Décidez ce qui doit survivre

Certaines règles appartiennent au cycle de vie d'une interface et devraient disparaître avec elle. D'autres doivent survivre au tunnel, et l'exemple le plus clair est une restriction qui interdit au trafic des clients de retomber sur l'interface physique lorsque le tunnel tombe. Ces deux catégories demandent des déclencheurs de restauration différents, pas un instantané partagé.

Écrivez le résultat attendu pour trois moments : démarrage, activation du VPN et perte du tunnel. Vérifiez ensuite si l'outil choisi peut exprimer chacun d'eux. Un paquet de persistance qui recharge un instantané statique couvre le premier et peut-être aucun des autres, car un instantané n'a aucune idée du moment où l'état du tunnel a changé. S'il ne peut pas les exprimer, la lacune appartient à un autre composant.

La politique, et non le paquet, décide de la réponse.

Vérifiez l'ordre de restauration

Restaurer le fichier n'est pas posséder le résultat. Un autre gestionnaire peut remplacer les règles, une autorisation antérieure peut les masquer, ou les clients peuvent commencer à envoyer avant que la restriction ne soit en place. Examinez le comportement au démarrage et à la reconnexion, pas seulement la présence d'un fichier enregistré.

systemctl status netfilter-persistent
iptables -S

Ne supposez pas qu'arrêter le service de persistance soit sans danger, car le paquet documente un vidage conditionnel à l'arrêt. Établissez la configuration réelle du service avant d'utiliser l'arrêt ou le redémarrage comme expérimentation sur une passerelle que vous administrez à distance. Une session console et un retour arrière documenté sont le minimum avant ce test.

L'ordre est une propriété du système en fonctionnement, pas du fichier sur le disque.

Acceptez trois résultats distincts

Consignez l'installation du paquet, le jeu de règles chargé et la politique appliquée comme des faits distincts. Un nom de paquet dans un fil d'assistance ne répond qu'au premier, et c'est celui qui compte rarement.

nft list ruleset

Testez ensuite une opération autorisée et un refus obligatoire.

Si le refus tient après un redémarrage et après la chute du tunnel, la politique survit. S'il ne tient que dans l'un de ces états, vous avez trouvé le problème d'ordre au lieu de le corriger.