Faire survivre la règle ip à une reconnexion avec systemd-networkd

Ajoutez une règle de politique avec ip rule : elle fonctionne jusqu'à ce que le lien disparaisse, et à ce moment elle n'est tout simplement plus là. Rien n'a échoué bruyamment : l'état du noyau a changé et aucun propriétaire de configuration ne savait que la règle était censée exister. C'est toute la différence entre une règle qui survit et une qui ne survit pas. Sur un hôte systemd-networkd, la solution est de donner un propriétaire à la règle plutôt que de relancer la commande après chaque reconnexion.

Une règle n'existe que si quelqu'un la possède

La politique de routage du noyau est un état, pas une configuration. Elle vit dans le système en marche, et tout ce qui démonte l'interface dont elle dépend peut l'emporter. Une commande de shell modifie cet état et ne laisse aucune trace de l'intention.

Les gestionnaires de réseau travaillent à l'inverse : ils lisent la configuration, l'appliquent et la réappliquent lorsqu'un événement de lien invalide l'état précédent. Une règle déclarée dans leur configuration est recréée, tandis qu'une règle ajoutée à côté d'eux est un objet étranger sans propriétaire.

Cette distinction porte un nom dans networkd, et il vaut la peine de le lire avant d'activer quoi que ce soit. Les règles étrangères sont supprimées par défaut dans les versions récentes, ce qui surprend ceux qui attendaient à ce que leurs entrées manuelles persistent.

Lisez la version avant de faire confiance à un réglage

Le comportement de propriété est contrôlé par un réglage de networkd.conf, et ce réglage n'existe pas dans les anciennes versions de systemd. Vérifiez la version installée avant de concevoir autour, car un hôte plus ancien se comporte différemment de la documentation que vous lisez.

Deux valeurs comptent. L'une décide si les règles non déclarées dans la configuration de networkd sont supprimées, et l'autre fait de même pour les routes. Les deux portent sur la propriété et non sur le contenu de la politique, et les deux choisissent par défaut le comportement le plus strict dans les versions actuelles. Les désactiver globalement maintient en vie chaque règle étrangère, ce qui est une décision bien plus large que de déclarer une politique VPN voulue.

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

Ce grep vous dit ce qui est défini localement et quel est le défaut du fournisseur. L'absence est aussi une information, car elle signifie que le défaut compilé s'applique. Notez ce défaut pour que la personne suivante n'ait pas à le redécouvrir.

Déclarez la règle et la table vers laquelle elle pointe

Une règle dans un fichier .network nomme une table, et c'est tout ce que fait un nom. Elle ne crée pas les routes à l'intérieur de cette table et ne vérifie pas qu'elles ont un sens. Déclarer la règle sans les routes produit une politique qui fait correspondre le trafic puis le rejette.

Déclarez les routes dans le même fichier, avec des sauts suivants joignables et la bonne table. Gardez la priorité dans la règle déclarée pour qu'elle atterrisse là où vous l'attendez dans la liste ordonnée. Une règle qui atteint la mauvaise table plus tôt que prévu modifie plus de trafic que le service que vous vouliez réparer. Lisez le fragment ci-dessous comme une forme et non comme un fichier complet, car la propriété de l'interface et le reste de la connexion doivent encore être présents.

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

Rechargez ensuite et relisez l'état du noyau plutôt que le fichier. Une configuration analysée proprement peut encore produire une règle que vous ne vouliez pas, et les deux vues ne concordent que lorsque la déclaration était complète.

Choisissez un seul propriétaire pour l'interface

Deux gestionnaires sur un tunnel produisent une bagarre qui ressemble à un défaut chez les deux. Importer une configuration wg-quick existante dans networkd est une migration et non un ajout, et faire tourner les deux laisse l'interface et ses règles sous deux propriétaires.

Faites la migration d'un seul passage : arrêtez l'ancienne unité, désactivez-la, déclarez l'interface et ses routes dans networkd, puis rechargez. Vérifiez que l'ancienne unité ne peut pas revenir au démarrage. Une unité résiduelle qui se réactive après un redémarrage écrase l'état que vous venez de déclarer. Conservez l'ancien fichier de configuration jusqu'à ce que le nouveau ait survécu à une reconnexion, puis retirez-le.

La propriété de la marque mérite le même soin : si une règle correspond à une marque de pare-feu, quelque chose doit poser cette marque. Une règle qui renvoie à une marque que personne ne pose est une configuration morte qui paraît délibérée.

Répétez les événements du cycle de vie

Une configuration ne vaut que par son comportement au fil des événements. Coupez le lien, remontez-le, redémarrez le service et renouvelez l'adresse. Après chacun, relisez la liste des règles et le contenu de la table.

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

Le résultat voulu est la même politique possédée recréée et l'état obsolète retiré, ce qui est plus durable que de rajouter une règle de shell après chaque reconnexion. Gardez une ligne dans le journal des changements qui nomme le fichier propriétaire de la règle et la version qui la prend en charge. L'ingénieur suivant pourra alors trouver la politique sans fouiller un historique de shell. Une règle que personne ne possède est une règle qui sera de nouveau perdue.