La poignée de main WireGuard fonctionne, le service non

La poignée de main aboutit, le client affiche un compteur de transfert récent, et pourtant une requête vers un service du même serveur échoue. Cette combinaison déroute, car le tunnel fonctionne de manière démontrable. Ce qui n'est pas démontré, c'est la livraison locale : le paquet a atteint l'hôte, et l'hôte doit encore l'accepter sur la bonne socket et le transmettre à un processus autorisé à répondre. Passez ces trois points de contrôle dans l'ordre.

Arrêtez-vous au premier qui ne tient pas, et n'ajoutez pas de règles pour les autres.

La poignée de main ne prouve que le tunnel

La poignée de main de WireGuard établit des clés entre pairs et autorise le trafic pour les plages que chaque pair a listées. Elle ne dit rien des processus qui écoutent sur le serveur, ni si le pare-feu de l'hôte accepte les paquets adressés à l'une de ses propres adresses.

C'est cette dernière distinction qui est le plus souvent manquée : le trafic vers l'hôte lui-même est de l'entrée locale, tandis que le trafic qui traverse l'hôte vers ailleurs est du transfert. Ils sont traités par des chaînes de pare-feu différentes et par des réglages différents. Vérifier la mauvaise chaîne coûte un après-midi et renvoie des compteurs qui semblent inoffensifs.

Lisez l'écoute et la route

Sur le client, confirmez que l'adresse du tunnel du serveur est routée dans le tunnel. Sur le serveur, confirmez qu'une socket existe sur l'adresse utilisée par le client, et que le processus derrière est bien celui que vous vouliez.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Une écoute sur 127.0.0.1 ne répondra jamais à une requête adressée à 10.66.0.1, quoi que permette le pare-feu. Une écoute sur l'adresse générique le fera, sauf si une règle la bloque. La liste des sockets tranche donc la moitié des cas avant même qu'une règle soit examinée. Le port et l'adresse décident ensemble si une requête peut aboutir.

Comparez l'adresse utilisée par le client avec celle que le serveur possède réellement sur l'interface du tunnel. Une configuration périmée d'un côté comme de l'autre produit une requête correctement routée vers un pair qui n'a pas cette adresse.

Appliquez des règles pour l'entrée locale, pas pour le transfert

Si le paquet arrive et que la socket existe, la frontière restante est la politique d'entrée. Une règle qui autorise le transfert n'autorise pas la livraison locale, et une règle limitée à une interface peut ne pas correspondre au nom d'interface de tunnel attendu.

Testez avec un seul port autorisé vers le service visé plutôt qu'en ouvrant l'hôte. Vérifiez ensuite l'autorisation propre à l'application : une liste d'autorisés, une exigence de compte ou un lien vers un nom d'hôte précis peuvent rejeter une requête que le réseau a livrée avec succès.

Laissez les contrôles de certificat en place. Une identité de certificat inattendue est une information sur l'hôte qui a répondu, pas un obstacle à contourner. Cliquer pour passer masque le seul indice qui identifie le mauvais service.

Séparez les échecs de nom, de taille et d'identité

Un service qui fonctionne par adresse mais échoue par nom est un problème DNS, et le correctif relève de la configuration du résolveur poussée au client, pas du pare-feu. Un service qui répond aux petites requêtes mais bloque sur les réponses plus grosses indique la taille des paquets et le MTU, ce qui est une enquête entièrement différente.

Une erreur HTTPS nommant le mauvais hôte signifie généralement que la requête a atteint un autre service, souvent parce qu'un mandataire ou une autre écoute possède ce port. Lisez le sujet du certificat et comparez-le à l'hôte que vous vouliez joindre. Cette comparaison ne coûte rien et termine souvent l'enquête.

Notez quel point de contrôle a échoué : socket, règle d'entrée ou politique de l'application. Cette seule ligne distingue une panne réseau d'une décision d'autorisation. Elle évite aussi que la personne suivante ouvre des ports qui n'ont jamais été le problème.