WireGuard : deux demi-routes face à 0.0.0.0/0 dans wg-quick

Deux préfixes /1 couvrent exactement les mêmes adresses IPv4 qu’un seul /0, et cette égalité ne tient qu’à l’intérieur de la liste des préfixes autorisés du pair. Elle cesse de tenir à l’instant où l’outil de configuration décide comment router, car Linux wg-quick traite un préfixe par défaut comme un cas particulier et non comme de l’arithmétique. La branche spéciale installe une table dédiée, deux règles de politique, une marque de socket et des réglages de chemin inverse qu’une paire de demi-routes ne reçoit jamais. Donc quand un proxy ou un navigateur cesse de fonctionner après la modification, les préfixes sont la partie la moins intéressante du changement.

La liste des préfixes n’est pas toute la configuration

AllowedIPs fait deux choses à la fois, et une seule concerne la couverture. Pour WireGuard lui-même, la liste est le routage par clé cryptographique : elle décide quelles destinations sont chiffrées vers un pair et quelles adresses source ce pair peut utiliser. Pour wg-quick, la même liste sert aussi de spécification de routes, et la route produite dépend de la branche que la liste rencontre. Une couverture identique avec deux formes de liste différentes ne dit donc rien d’un état d’hôte identique.

La configuration par défaut vous retire cette décision, car Table est automatique par défaut et l’outil choisit où atterrissent les routes. Un autre gestionnaire de réseau, un emballage de distribution ou une valeur Table personnalisée change à nouveau le résultat, et c’est pourquoi un conseil écrit pour un hôte peut sembler faux sur le suivant.

Ce que la branche par défaut ajoute au-delà d’une route

Une entrée /0 envoie wg-quick dans son chemin de route par défaut : une table de routage séparée reçoit la route par défaut, une règle de politique y envoie le trafic non marqué, une seconde règle maintient autoritaires les routes plus spécifiques de la table principale, et l’interface reçoit une marque de pare-feu appliquée à son propre socket. Cette marque est le garde-fou de boucle. Les datagrammes chiffrés qui transportent le trafic du tunnel sortent avec la marque posée, afin que la règle qui dirige tout le reste vers le tunnel n’avale pas les paquets de transport du tunnel lui-même.

Une paire d’entrées /1 emprunte au contraire le chemin de route ordinaire. Deux routes atterrissent dans la table configurée, et aucune de la machinerie environnante n’apparaît, non parce qu’elle serait inutile mais parce que ce chemin de code n’a jamais été emprunté.

Où les deux dispositions divergent

La divergence se manifeste d’abord comme une récursion. Avec les demi-routes dans la table principale, l’adresse de transport du pair lui-même tombe dans un préfixe du tunnel, si bien que le paquet censé porter le tunnel correspond à une route pointant vers l’intérieur du tunnel. Quelque chose doit l’exempter : une route d’hôte pour le point de terminaison courant, une marque appliquée à la main ou une règle propre à l’interface. Une route d’hôte fonctionne jusqu’à ce que l’adresse du point de terminaison change, ce qui arrive avec les points de terminaison basés sur DNS, les clients itinérants et les configurations à plusieurs pairs.

Deuxièmement, tout ce qui raisonne sur les marques change de comportement. Un proxy transparent qui redirige les connexions localement crée de nouveaux sockets dont les marques et les sources diffèrent du flux client d’origine, et les règles de politique générées par la branche par défaut faisaient partie de ce qui a trié ces flux. Lire la connexion sortante du proxy lui-même est un exercice différent de tester si la destination d’origine est joignable.

Lisez les règles et les marques avant de modifier

Capturez l’état actuel pendant que le tunnel est sain, puis de nouveau après le changement, et comparez les deux vidages plutôt que de raisonner à partir du fichier de configuration. Incluez les règles de politique, chaque table, la marque de l’interface et les points de terminaison enregistrés.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Si la première ligne de sortie a perdu la règle du trafic non marqué et que la table dédiée est vide, la branche par défaut ne s’exécute pas et aucune arithmétique de préfixes ne rétablira ses effets. Une marque nulle sur une interface qui en portait une auparavant est le même signal, visible dans une seule valeur.

Répétez la perte du tunnel avant de livrer

Si la disposition en demi-routes est le choix délibéré, elle doit fournir explicitement les pièces manquantes : un chemin de point de terminaison qui survit aux changements d’adresse, le comportement attendu quand le tunnel tombe et le traitement équivalent pour IPv6. Écrivez-les comme des exigences plutôt que de les découvrir pendant une panne. Puis répétez la défaillance, car un tunnel complet qui retombe silencieusement sur la liaison physique est pire qu’un tunnel qui cesse de fonctionner.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

La recherche de route devrait résoudre le point de terminaison par l’interface physique sans traverser le tunnel, et la descente de l’interface devrait laisser l’hôte dans l’état que le design promettait. Un proxy qui fonctionne après le remplacement prouve que l’état d’hôte généré importait ; il ne prouve pas que la prévention des boucles et le comportement à l’arrêt ont survécu à la modification.