dev tun sous Windows affiche toujours un adaptateur TAP. Est-ce une erreur ?

Le Gestionnaire de périphériques affiche un TAP-Windows Adapter V9 alors que le profil indique dev tun, et le tunnel fonctionne. Cette combinaison n'est pas une mauvaise configuration, et faire basculer le mode dans un sens puis dans l'autre n'y changera rien. Le nom de l'adaptateur reflète le pilote Windows chargé par le client, pas les paquets que le tunnel transporte. Lisez la ligne du pilote dans le journal du client avant de modifier quoi que ce soit.

Pourquoi un tunnel de couche 3 obtient un adaptateur Ethernet

Pendant la majeure partie de l'histoire Windows du client, aucun adaptateur virtuel de couche 3 utilisable n'existait. La seule option était le pilote TAP-Windows, qui présente une interface Ethernet. Le client émulait ensuite le comportement de couche 2 manquant pour que Windows puisse le configurer. C'est cette émulation qui explique pourquoi l'adaptateur ressemble encore à une carte réseau.

Deux parties de cette émulation sont visibles si l'on regarde : le client répond à l'ARP pour l'adresse du tunnel, et il sert un petit bail DHCP à la machine locale. Windows voit donc un adaptateur Ethernet normal avec une adresse MAC et un pilote NDIS, tandis que le tunnel lui-même transporte des paquets IP nus. Le costume Ethernet appartient au pilote, pas au mode du tunnel.

Cherchez la ligne du pilote au lieu de juger sur le nom

Deux adaptateurs peuvent partager un nom d'une version de pilote à l'autre, donc le nom seul ne peut pas vous dire ce qui a tourné. Le journal du client nomme le périphérique qu'il a ouvert, et sur les versions récentes il nomme aussi le pilote qu'il a sélectionné ; c'est la ligne à lire.

Vérifiez trois choses dans le journal, dans cet ordre : si le client a ouvert un adaptateur, quel pilote il signale, et s'il est retombé sur un autre après un échec. Une ligne de repli est facile à manquer parce que la connexion monte quand même, et le tunnel tourne alors sur le pilote plus ancien pendant que l'utilisateur croit que le nouveau est actif.

Passez au pilote de couche 3, et vérifiez ce qui doit être présent

Le pilote de couche 3 livré par le projet WireGuard est disponible depuis la version 2.5 du client, mais il est facultatif. Une seule directive le sélectionne :

windows-driver wintun

Le pilote doit être installé sur la machine, et les versions officielles en contiennent une copie signée. Livrez cette version signée si vous packagez le client vous-même, car un pilote compilé en privé entre en collision avec les copies qu'installent d'autres produits VPN. Ces collisions produisent des échecs lents à attribuer, et ils apparaissent généralement après l'arrivée d'un second client VPN sur la machine. Un pilote manquant, en revanche, laisse une ligne claire dans le journal.

Le pilote impose aussi des autorisations plus strictes, donc le client crée l'adaptateur via son service interactif exécuté sous un compte privilégié. Démarrez le client comme un simple processus utilisateur sans ce service et la directive peut échouer, ce qui laisse l'adaptateur précédemment installé visible et donne l'impression que le basculement a été ignoré.

Quand TAP reste la bonne réponse

Si le tunnel doit transporter des trames Ethernet, du trafic de diffusion ou des protocoles non IP, un adaptateur de couche 2 est requis et le pilote TAP découle de cette exigence. Une conception en pont sous Windows a la même contrainte, puisque l'interface doit rejoindre un domaine de couche 2.

La performance n'est pas une raison de préférer l'un à l'autre au niveau du nom de l'adaptateur. La version 2.6 ajoute un pilote de déport du canal de données qui déplace le traitement des paquets dans le noyau, et c'est l'option qui change les caractéristiques de débit. C'est une décision de capacité plutôt qu'une exigence pour se connecter, et elle dépend de la version et du paquet installé. Un profil qui fonctionne sans elle continue de fonctionner.

Nettoyez après le basculement

Supprimer l'ancien adaptateur compte autant que d'ajouter le nouveau. Une interface TAP résiduelle peut conserver une adresse et une route d'une session précédente, et ces entrées survivent à la connexion qui les a créées. Supprimez le périphérique obsolète dans le Gestionnaire de périphériques, puis reconnectez-vous et vérifiez que la table de routage ne le mentionne plus.

Si plusieurs produits VPN sont installés, notez quel paquet de pilotes chacun embarque avant de déboguer le profil. Deux clients installant des versions différentes du même pilote constituent un conflit qu'aucune modification de profil ne résoudra. Désinstallez le client inutilisé et redémarrez, puis cherchez des adaptateurs en double dans le Gestionnaire de périphériques. C'est seulement ensuite qu'il vaut la peine de comparer les lignes de journal entre les deux produits.