Comment démarrer un tunnel WireGuard comme service systemd

Vous avez un profil WireGuard dans /etc/wireguard/wg0.conf et vous voulez qu’il soit actif sans taper wg-quick up à la main après chaque redémarrage. Le modèle systemd fourni par le paquet fait exactement cela: [email protected] lance wg-quick pour le profil nommé wg0. Il installe aussi les adresses, les routes, le DNS et tous les hooks que le profil déclare, ce qui va au-delà du simple chargement d’une clé dans le noyau. Vérifiez que le modèle existe sur votre système avant de partir du principe qu’il y est.

Le reste de ce parcours suit l’ordre dans lequel vous le feriez réellement.

Trouver l’unité et le profil qu’elle lit

Listez les fichiers d’unité avec systemctl list-unit-files 'wg-quick*'. Sur les distributions qui l’empaquettent, vous verrez [email protected], le nom d’instance étant repris du profil. L’instance se résout en /etc/wireguard/<name>.conf, donc wg-quick@wg0 ne lit que wg0.conf. Si la liste est vide, le paquet d’outils n’est pas installé et aucune activation n’y changera rien.

Gardez le profil en mode 600 et la propriété de root. Il contient une clé privée, et l’unité tournera volontiers avec de pires permissions si vous le laissez faire.

Le monter et lire le journal

Démarrez l’instance avec systemctl start wg-quick@wg0, puis vérifiez systemctl status wg-quick@wg0 et journalctl -u wg-quick@wg0 -b. Une unité qui démarre et s’arrête aussitôt a généralement une erreur de profil, et le journal nomme la ligne. Confirmez avec wg show que l’interface existe et que la dernière poignée de main est récente. Le manuel de wg-quick énumère ce que le script fait au-delà de l’interface elle-même.

Une interface configurée sans poignée de main est un problème de chemin ou de clé, pas un problème de service.

Garder un seul gestionnaire aux commandes

Si NetworkManager ou un autre client possède déjà le tunnel, démarrer l’unité systemd crée un second propriétaire pour la même interface, les mêmes routes et le même DNS. Les symptômes sont déroutants: le tunnel monte, puis les routes disparaissent, ou le DNS revient en arrière au bout de quelques secondes. Choisissez un gestionnaire et désactivez l’autre pour ce profil. Le journal montre généralement la reprise comme des changements de routes ou de résolveur juste après que l’unité signale un succès.

Deux gestionnaires ne partagent pas la propriété. Ils s’écrasent l’un l’autre.

Tester l’arrêt, le redémarrage et le démarrage

Exécutez systemctl stop wg-quick@wg0 et confirmez que l’interface a disparu et que les routes ont été supprimées. Redémarrez-la ensuite et vérifiez que les routes reviennent, car les bugs de démontage se manifestent par des routes résiduelles plutôt que par des démarrages ratés. Enfin activez-la au démarrage avec systemctl enable --now wg-quick@wg0 et redémarrez une fois.

Au démarrage, le nom du point de terminaison doit être résolu avant que l’unité ne s’exécute. Si le DNS n’est pas encore actif, l’unité échoue et reste en échec jusqu’à ce que vous la démarriez à la main.

Noter le propriétaire

Notez quel profil l’unité lit, quel gestionnaire possède l’interface et d’où vient le fichier. Quand quelqu’un importera plus tard le même tunnel dans un client de bureau, cette note fait la différence entre une migration et deux déploiements qui se disputent une adresse. Notez aussi le nom de l’interface, car deux profils aux noms proches sont la source habituelle de confusion.

Un tunnel à deux propriétaires fonctionne jusqu’au premier redémarrage, puis devient un mystère. C’est pourquoi la note appartient au dépôt et non à un fil de discussion.