WireGuard AllowedIPs : la route que NetworkManager n’a jamais ajoutée

Le compteur de poignées de main se met à jour, l’interface conserve son adresse, et un ping vers l’autre côté ne va nulle part. Cette combinaison déroute, car une poignée de main qui fonctionne ressemble à la preuve que le tunnel est prêt. Elle ne l’est pas : un tunnel peut être entièrement négocié et n’avoir malgré tout aucune route qui y achemine le trafic, et ce sont deux tâches distinctes accomplies par deux morceaux d’état distincts. Le correctif dépend entièrement de laquelle des deux manque, donc la première étape est de le découvrir.

wg-quick fait les deux sans qu’on le lui demande. La prise en charge de WireGuard intégrée à NetworkManager installe aussi des routes de pairs par défaut, ce qui réduit les suspects à une option désactivée, à une autre table de routage ou à une configuration importée par autre chose.

Confirmez le tunnel avant de courir après la route

wg show affiche l’interface, le pair, le point de terminaison et l’âge de la dernière poignée de main, et ip addr show confirme que l’adresse est présente. Une poignée de main récente signifie que les clés, le point de terminaison et le chemin UDP fonctionnent. Tout ce qui est cassé se situe en aval : routage, filtrage ou résolution de noms.

Demandez ensuite au noyau ce qu’il ferait avec une destination réelle plutôt qu’hypothétique : ip route get 10.42.7.9. La réponse nomme l’interface de sortie et l’adresse source que le paquet porterait. Quand elle nomme l’adaptateur physique, le paquet n’entre jamais dans le tunnel, aussi saine que paraisse la poignée de main.

AllowedIPs est à la fois un filtre et une liste de routes

Les préfixes d’AllowedIPs font deux choses. Ils choisissent quel pair transporte une destination sortante, et ils valident l’adresse source des paquets entrants, ce qui est la frontière du routage par clé cryptographique. Dans wg-quick, ils pilotent aussi l’installation automatique des routes, et c’est ce comportement supplémentaire qui explique pourquoi la même configuration fonctionne depuis un terminal et pas depuis un client de bureau.

Dans le cas derrière cet article, le profil a été importé via un greffon tiers plutôt que par la prise en charge intégrée, et l’interface est montée sans la route de préfixe. Lister la table le montre immédiatement : ip route show ne contient que la route connectée de l’adresse de l’interface, et rien pour la plage distante.

Demandez si les routes de pairs sont activées

Lisez le réglage avant de modifier quoi que ce soit : nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Quand peer-routes affiche no, la réparation prise en charge est nmcli connection modify work-wg wireguard.peer-routes yes, suivie d’une reconnexion. Ajouter plutôt une route statique fonctionne jusqu’à la prochaine activation puis disparaît discrètement. Cette disparition est l’indice : une route qui revient comme un mystère chaque matin n’est pas installée par le profil.

Si l’option est déjà activée, vérifiez si le préfixe vit dans une autre table avec ip route show table all | grep 10. Une route dans une table autre que la table principale ne manque pas, elle est simplement invisible pour une recherche qui ne consulte que la table principale. Corrigez le routage par politiques au lieu d’empiler une entrée en double par-dessus.

Ajoutez le préfixe à la connexion, pas au système en cours d’exécution

Dans l’éditeur de connexions, la page WireGuard contient le pair et ses AllowedIPs, et la page IPv4 contient des routes supplémentaires. Une route ajoutée là survit aux reconnexions parce qu’elle appartient au profil. En ligne de commande, l’équivalent consiste à ajouter une route à la connexion sous la forme à passerelle vide, puis à descendre et remonter la connexion pour que le changement s’applique.

Choisissez le préfixe le plus étroit qui couvre les hôtes dont vous avez besoin. Copier l’exemple /8 du fournisseur peut avaler des plages locales qui s’y trouvent par hasard, et les pannes qui en résultent ressemblent à un tunnel cassé plutôt qu’à une route trop large.

Le tunnel divisé est décidé par la liste de préfixes

Il n’existe pas d’interrupteur de tunnel divisé ; la liste de préfixes est la décision. Un pair avec une plage pour le LAN du bureau et une pour un réseau de laboratoire envoie exactement ces destinations par le tunnel et laisse tout le reste tranquille. Un seul hôte a besoin d’un /32, et des plages qui se chevauchent sur deux sites ont besoin de préfixes d’hôte jusqu’à ce que quelqu’un renumérote un sous-réseau.

Choisir de n’envoyer rien par le tunnel pousse la même décision à sa limite : une liste minimale maintient la liaison active tandis que le trafic ordinaire suit son chemin habituel. Écrivez l’intention, sinon le prochain lecteur prendra la liste courte pour un oubli et l’étendra obligeamment.

Un seul propriétaire pour la table de routage

wg-quick et NetworkManager croient tous deux posséder les routes de l’interface. Importez une configuration écrite pour wg-quick puis démarrez aussi le service wg-quick, et vous obtenez des entrées dupliquées ou contradictoires dont le comportement dépend de laquelle a tourné en dernier. Choisissez un seul propriétaire et retirez l’autre : si NetworkManager gère la connexion, désactivez l’unité wg-quick pour cette interface, et n’ajoutez jamais un second profil pour le même appareil.

Quand la division doit suivre un adaptateur physique plutôt qu’une destination, vous êtes passé au routage par politiques, et le routage par politiques a lui aussi besoin d’un seul auteur. Vérifiez en répétant ip route get, puis en atteignant un hôte à l’intérieur du préfixe distant avec quelque chose qui affiche l’adresse source qu’il a choisie. Vérifiez IPv6 et DNS séparément si le profil porte l’un ou l’autre.