WireGuard fonctionne en données mobiles mais pas sur le même wifi

Le tunnel monte en données mobiles puis reste sur connexion à la maison, avec le même profil, la même clé de pair et aucun changement de configuration entre-temps. La différence tient au trajet : une requête depuis l’intérieur du LAN vers l’adresse publique du routeur n’est pas le même voyage qu’une requête qui arrive d’Internet. La plupart des passerelles domestiques soit n’implémentent pas le chemin de retour, soit ne le font que pour certains protocoles. Le symptôme ressemble alors à une clé cassée alors que rien dans la clé n’a bougé. Déterminez quel chemin a échoué avant de toucher à une clé, à une redirection de port ou à un profil client.

Une adresse, deux chemins différents

De l’extérieur, un paquet atteint l’adresse publique du routeur et une règle de redirection de port le remet à l’écouteur WireGuard sur l’hôte interne. De l’intérieur, le client compose la même adresse publique, si bien que le paquet quitte le client, arrive au routeur et doit être renvoyé vers le LAN. C’est à ce retour que les deux chemins divergent, car le routeur doit traduire un flux qui sort et rentre à la fois par la même interface. Beaucoup d’implémentations le jettent au lieu de le traduire, et le client attend alors une poignée de main qui n’a jamais été envoyée.

Ce comportement s’appelle généralement NAT loopback ou hairpinning, et il relève du routeur plutôt que de WireGuard ; RFC 4787 expose les cas de traduction dans lesquels une passerelle peut ou non le prendre en charge. WireGuard lui-même n’a pas d’avis sur le chemin, car il ne voit que les paquets qui atteignent son interface. Quand le routeur jette le flux, le démon ne reçoit jamais rien, le client signale un délai d’attente de poignée de main et le journal du serveur reste vide. Un journal vide est donc un indice sur l’endroit où le paquet s’est arrêté, pas une preuve que le serveur est hors service. C’est aussi pourquoi une réinstallation ne change rien.

L’inverse compte aussi : un journal du serveur qui montre une tentative de poignée de main depuis l’adresse du LAN prouve que le paquet est arrivé et que le chemin est bon, ce qui déplace l’enquête vers les clés et les adresses autorisées. Lisez le journal pour ce qu’il prouve, pas pour ce que vous espériez voir.

Reproduisez avant de changer quoi que ce soit

Testez depuis un réseau externe autorisé avec le même appareil et le même profil, puis répétez le test à l’intérieur du LAN sans rien modifier. Une poignée de main aboutie dehors et un client qui, dedans, ne quitte jamais l’appareil reproduisent la condition au lieu de la deviner. Les deux essais doivent utiliser le même profil, sinon la comparaison ne prouve rien.

Regardez ensuite vers quoi le nom du point de terminaison se résout pour cet appareil. Les trois commandes suivantes montrent aussi quelle adresse le client a réellement composée :

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

La première commande indique le point de terminaison que l’interface utilise en ce moment, et les deux autres montrent vers quoi le nom se résout sur cette machine. Un client qui compose une adresse publique alors qu’il se trouve sur le même réseau que le serveur emprunte le chemin hairpin. Un client qui compose l’adresse du LAN ne le fait pas, et une panne à cet endroit relève d’une autre enquête. Cette distinction décide si la section suivante s’applique ne serait-ce qu’un peu.

Façons prises en charge d’atteindre un serveur proche

L’arrangement le plus propre est une réponse à horizon divisé : le nom public se résout vers l’adresse publique pour Internet et vers l’adresse LAN du serveur pour les clients de l’intérieur. Le profil garde un seul nom de point de terminaison et le résolveur choisit le chemin. Cela exige la maîtrise de la réponse DNS interne, qu’un routeur domestique offre généralement et qu’une organisation peut organiser délibérément. Sans cette maîtrise, les choix restants sont une fonction du routeur ou un second profil.

La fonction du routeur est la réflexion : la passerelle traduit le flux de l’intérieur vers l’extérieur et le renvoie vers l’intérieur. Là où elle fonctionne, elle ne demande aucune modification du client, et là où elle ne fonctionne pas, aucun réglage du client ne la sauvera. Testez-la en surveillant le journal du serveur pendant une tentative interne plutôt qu’en lisant la liste des fonctions du routeur.

Modifier le profil vers une adresse privée est un diagnostic, pas une conception. Cela prouve que le serveur répond sur le LAN, et cela casse le même profil dès que l’ordinateur portable quitte la maison.

Gardez le profil utilisable hors de chez vous

Quel que soit le chemin choisi, laissez tranquille la vérification d’identité. L’adresse du point de terminaison n’est pas l’identité du pair, et un changement d’adresse ne justifie jamais d’accepter une clé publique étrangère qui répond par hasard. WireGuard authentifie par clé, donc un hôte erroné échoue à la poignée de main au lieu d’accorder l’accès à quelque chose d’inattendu.

Si l’adresse publique bouge, le DNS dynamique est ce qui garde le nom utile, et le comportement de rafraîchissement du client décide de la vitesse à laquelle le changement arrive. Testez-le depuis l’extérieur après un changement d’adresse, car le cas du LAN ne peut pas le valider. Surveillez un résolveur qui met en cache l’ancienne réponse au-delà de la durée de vie de l’enregistrement. Un nom qui pointe encore vers l’adresse précédente ressemble exactement à un serveur tombé.

Notez quel nom le profil utilise et vers quoi il se résout de chaque côté de la frontière. Un profil qui dépend d’une fonction du routeur que personne n’a consignée est un appel au support en attente de la prochaine mise à jour du micrologiciel. La note est aussi ce qui dit à la personne suivante si une panne interne est le cas hairpin connu ou quelque chose de nouveau.