Comment construire un test WireGuard à deux pairs qui prouve un seul chemin

Un test WireGuard qui transporte une route par défaut, un préfixe LAN, du DNS et une exception de pare-feu ne peut pas vous dire lequel a cassé. Réduisez-le à deux pairs, une paire d’adresses et un seul service autorisé, et la panne n’a plus où se cacher. La base ennuyeuse, c’est le diagnostic. Construisez-la d’abord ; elle prend quinze minutes et vous épargne l’après-midi que vous passeriez sinon à deviner.

Ce que la base prouve est plus étroit que ce que la plupart des gens attendent. Elle prouve que deux identités sont d’accord, que l’UDP atteint le port d’écoute et qu’une destination autorisée transporte une requête. Le forwarding, le NAT, les routes LAN et le DNS sont des fonctions séparées à ajouter ensuite, une à la fois.

Clés, adresses et l’unique endpoint

Générez une paire de clés sur chaque système et ne déplacez entre eux que les moitiés publiques. wg genkey | tee privatekey | wg pubkey > publickey est la commande documentée d’une seule ligne, et elle laisse la clé privée dans un fichier que vous pouvez ensuite protéger. Choisissez des adresses de tunnel dans une plage qui n’apparaît dans aucune autre configuration que vous possédez, par exemple 10.99.0.1/24 et 10.99.0.2/24. Notez quelle adresse appartient à quelle machine, car chaque vérification ultérieure dépend de cette correspondance.

Les clés privées ne voyagent jamais. Si un test a besoin d’en copier une de l’autre côté, le test a déjà mal tourné. Quand les deux systèmes sont derrière un NAT, au moins l’un a besoin d’un port UDP joignable pendant que l’autre porte un Endpoint qui pointe vers lui, et l’adresse publique et le port appartiennent à vos notes plutôt qu’à vos suppositions sur 51820.

Une redirection de port qui mappe un port externe différent fonctionne bien tant que l’Endpoint correspond. Les écarts ici produisent du silence plutôt que des erreurs, et c’est pourquoi ils valent d’être vérifiés sur papier avant de déboguer sur le câble.

Les champs qui appartiennent à wg et ceux qui n’y appartiennent pas

L’ensemble des champs essentiels est petit : PrivateKey et ListenPort sous Interface, PublicKey, AllowedIPs et Endpoint sous Peer. Address et DNS appartiennent à wg-quick et non à wg lui-même, et cette distinction mord dès que la même configuration passe dans un autre outil.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs remplit deux tâches à la fois. Il sélectionne quelles destinations entrent dans le tunnel, et il autorise le pair à utiliser ces adresses sources à l’arrivée. C’est pourquoi l’entrée miroir de l’autre côté doit nommer exactement l’adresse de votre tunnel ; un /32 pour le mauvais pair se lit comme un problème de routage et se comporte comme un problème d’autorisation. Le démarrage rapide WireGuard montre la même forme à deux pairs avec la formulation canonique si vous voulez comparer les noms de champs.

Lire la poignée de main plutôt que l’icône

Montez l’interface par ce qui la possède, puis lisez l’état plutôt qu’un voyant. wg show affiche la dernière poignée de main par pair avec les compteurs d’octets, et une poignée de main dans les dernières minutes signifie que les clés, l’endpoint et le chemin UDP fonctionnent tous. Un compteur qui ne monte que dans un sens est sa propre réponse, et ce n’est pas la même panne qu’une poignée de main qui n’a jamais lieu.

Les deux pannes impliquent des enquêtes différentes. L’absence totale de poignée de main pointe vers une divergence de clés, un Endpoint erroné, de l’UDP bloqué ou un pare-feu qui jette la poignée de main elle-même. Une poignée de main qui réussit alors que les données ne vont nulle part pointe vers AllowedIPs, un service qui n’écoute pas sur l’adresse du tunnel, ou un pare-feu d’hôte qui accepte le port pour le LAN mais pas pour l’interface du tunnel. Ce sont deux moitiés différentes du système, et la base les sépare avant que vous ne commenciez à changer des règles.

Prouver un service autorisé, puis l’inverse

Faites une requête vers l’adresse de tunnel de l’autre pair sur un service censé répondre, et choisissez mieux que ping. Une réponse ICMP absente peut être du filtrage d’hôte et non une panne du tunnel, donc un ping silencieux ne prouve aucune direction. Une connexion TCP vers un port que vous savez ouvert, ou une requête qui renvoie des données, vous donne une réponse interprétable.

Exécutez la direction inverse comme un test séparé avec son propre résultat, car les deux directions ont des entrées de pare-feu et d’AllowedIPs séparées et peuvent échouer indépendamment. Si la poignée de main fonctionne et que la requête non, le problème se situe dans le chemin de données et non dans le tunnel : AllowedIPs, le service à l’écoute ou un pare-feu d’hôte. Corrigez cela avant d’ajouter du forwarding, du NAT ou du DNS, sinon vous passerez l’après-midi à déboguer une fonction qui n’était jamais en cause.

Garder la base comme référence

Enregistrez la topologie qui fonctionne et la source du profil à un endroit d’où vous pouvez restaurer, et gardez-les hors de tout répertoire qui se synchronise avec un service public. Ajoutez ensuite une fonction à la fois, en répétant la requête d’origine après chacune : forwarding, NAT, une route LAN, et seulement ensuite le DNS. Chaque ajout qui casse le test est désormais identifiable, car rien d’autre n’a bougé.

Une base qui ne fait que rendre une icône verte ne vous a rien dit sur l’ajout qui a causé la panne suivante. Gardez l’unique chemin autorisé en fonctionnement comme référence, et chaque changement ultérieur est mesuré par rapport à lui.