Poignée de main oui, internet non : que corriger d’abord sous Windows 11

Sous Windows 11, des poignées de main récentes côtoient souvent des navigateurs qui n’ouvrent rien. La poignée de main prouve seulement que l’échange UDP avec le pair s’est terminé. Elle ne dit rien de la route installée par Windows, du résolveur qu’il utilise, ni de si la sortie transmet quoi que ce soit.

Quatre conditions décident laquelle de ces couches a échoué. Les parcourir dans l’ordre prend quelques minutes, alors que réécrire les clés prend plus longtemps et ne change rien.

Déterminez la couche avant de toucher aux clés

Parcourez trois destinations, dans cet ordre. Commencez par une adresse côté tunnel, puis une IP publique en chiffres, et terminez par un nom d’hôte. Là où la séquence casse, la couche est nommée. Un échec à la première étape est du routage, à la deuxième c’est du transfert ou du NAT, et à la troisième c’est de la résolution de noms.

Cet ordre est toute la méthode. Il empêche qu’une panne DNS soit diagnostiquée comme un tunnel cassé, qui est le faux pas le plus courant ici.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Si l’heure de la poignée de main est vide

Quand l’heure de la poignée de main est vide, l’échange chiffré ne s’est jamais terminé. La panne se situe donc avant le routage. Regardez d’abord l’adresse du point de terminaison et le port, puis si le réseau filtre l’UDP. Un hébergeur qui jette le trafic WireGuard produit exactement cela, et un client qui a copié un point de terminaison depuis un ancien profil aussi.

Des octets qui sortent sans qu’aucun n’entre sont un autre cas. Cela désigne du NAT ou un pare-feu qui renvoie le trafic au mauvais endroit.

Si la route perd face à l’adaptateur physique

Pour un tunnel complet, la section du pair doit couvrir les destinations que vous comptez utiliser. Windows conserve parfois la route par défaut de l’adaptateur physique même avec une règle générale configurée. Découper la règle générale en 0.0.0.0/1 plus 128.0.0.0/1 crée deux préfixes plus spécifiques qui gagnent la recherche. Le découpage est un contournement documenté, pas une préférence.

Confirmez avec route print ou une recherche d’adresse publique. L’interface choisie devrait être l’adaptateur du tunnel. Si le physique gagne encore, corrigez les plages du pair avant de toucher au serveur.

Si les adresses fonctionnent et les noms échouent

WireGuard transporte des paquets IP et n’a aucune opinion sur le DNS. Placez une ligne DNS = dans la section d’interface, ou configurez l’adaptateur via Windows. Sans elle, un ping par adresse réussit alors que chaque nom d’hôte échoue, et les utilisateurs le signalent comme une absence d’internet.

Vérifiez quels serveurs Windows utilise réellement après la connexion. Un résolveur resté sur l’adaptateur physique explique un échec partiel, où certains noms se résolvent et d’autres non. Nettoyez-le au lieu d’en ajouter un second par-dessus.

Si la machine Windows est la sortie

Internet Connection Sharing réécrit l’adressage lorsqu’il est activé, ce qui peut déplacer l’adaptateur partagé vers une autre plage. Un client qui pointe encore vers l’adresse d’origine cesse alors de fonctionner. Les valeurs de registre ScopeAddress et StandaloneDHCPAddress contrôlent cette plage, et le réglage peut revenir après un redémarrage.

Deux autres conflits propres à Windows méritent un coup d’œil. Le service Routing and Remote Access peut gêner le tunnel. Un programme d’installation conçu pour la mauvaise architecture échoue avec un message qui ne mentionne jamais l’architecture.

Corrigez la couche désignée par le test, puis relancez les trois mêmes destinations. Un changement qui répare le test du nom d’hôte mais casse l’adresse du tunnel a été appliqué à la mauvaise couche.