L'adaptateur OpenVPN clignote sous Windows ? Vérifiez s'il y a une IP en double

Sous Windows, un adaptateur OpenVPN qui prend une adresse, la lâche et recommence toutes les quelques secondes n'est généralement pas un bug DHCP. On demande à l'adaptateur d'utiliser une adresse à laquelle autre chose répond déjà, alors Windows la marque comme inutilisable et le client repart de zéro. Le journal du client reste silencieux parce que le conflit se règle en dessous, dans la pile réseau du système d'exploitation lui-même.

Cette distinction compte, car chaque étape de dépannage visant la configuration du tunnel passera à côté d'une adresse en double côté serveur.

Commencez par le journal des événements Windows, pas par le journal du client

Windows consigne les conflits d'adresses dans le journal système, avec les identifiants d'événement 4198 et 4199. Le premier signale un conflit détecté pour une adresse, le second signale qu'une interface n'a pas pu utiliser l'adresse avec laquelle elle était configurée. Aucun des deux ne mentionne OpenVPN, et c'est précisément pourquoi ils passent facilement inaperçus.

Extrayez les événements récents et comparez leurs horodatages au cycle de renouvellement de l'adaptateur : Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Un conflit toutes les quinze secondes correspond à un client qui réessaie la même adresse face à un propriétaire qui continue d'y répondre. Un conflit unique au moment de la connexion indique plutôt une collision ponctuelle. Dans tous les cas, la question suivante est de savoir qui d'autre détient l'adresse.

Trois dispositions placent deux hôtes sur une même adresse

Demandez au serveur qui, selon lui, détient l'adresse, puis demandez au réseau qui y répond. grep -H ifconfig-push /etc/openvpn/ccd/* liste chaque adresse de tunnel épinglée et le certificat auquel elle appartient. ip -4 neigh show dev tap0 montre ce que le pont a appris au niveau deux. Comparer ces deux listes trouve la plupart des doublons en moins d'une minute.

Trois dispositions expliquent presque tous les cas : une entrée client-config-dir épingle une adresse pour deux certificats, un segment tap ponté donne à une machine une adresse qu'un autre hôte possède déjà statiquement, ou un fichier de bail obsolète renvoie une adresse qu'un client encore connecté croit posséder. Le troisième cas est le plus sournois, car ifconfig-pool-persist réutilise délibérément des adresses pour les clients connus.

Rendez l'adresse unique au lieu de la disputer

L'ordre de démarrage ne décide que du gagnant du jour, alors traitez comme temporaire toute correction fondée sur la séquence de redémarrage. Donnez à chaque client sa propre ligne ifconfig-push, ou allouez des adresses statiques dans une plage qu'aucune interface de pont ou de serveur ne touche. Vérifiez aussi la liste des clients pour des noms communs en double, car duplicate-cn permet à deux sessions de partager une identité et donc une adresse épinglée. Si un appareil ponté a vraiment besoin d'une adresse fixe, déplacez-le vers son propre sous-réseau ou réservez-la dans le pool à un endroit que le serveur consigne.

Ne supprimez le fichier persist qu'après avoir su quels baux il contient, sinon la prochaine reconnexion redistribuera les mêmes adresses.

Redémarrez dans le bon ordre et confirmez un seul propriétaire par adresse

Appliquez le changement sur le serveur d'abord, puis reconnectez les clients, pour que chaque participant s'enregistre contre le pool corrigé. Redémarrer d'abord les clients les laisse avec des adresses que le serveur croit encore prises. Après le redémarrage, lisez le fichier d'état et confirmez que chaque nom commun apparaît une fois avec une adresse. Deux entrées pour un nom signifient qu'une ancienne session ne s'est jamais fermée, pas que le pool est cassé.

Si un client ne parvient toujours pas à garder son adresse, vérifiez si une interface de pont sur le même hôte la porte. Un pont qui a hérité d'une adresse d'un appareil fournisseur répondra ARP pour elle même lorsque le serveur VPN a déjà remis cette adresse à un client.

Observez sur un cycle de renouvellement complet avant de fermer le ticket

Une seule lecture propre ne prouve rien. Surveillez l'adaptateur au moins dix minutes et forcez une reconnexion au milieu : Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. L'adresse devrait survivre à la reconnexion et rester dans un état préféré.

Relancez ensuite la requête d'événements de la première étape et confirmez qu'elle ne renvoie rien de nouveau. Un journal silencieux sur une reconnexion est la preuve que le conflit a disparu, tandis qu'un journal silencieux après une seule connexion signifie seulement que la course n'a pas encore eu lieu. Enfin, testez la ressource pour laquelle le tunnel existe, car un pont qui a perdu son adresse peut casser un chemin fournisseur alors que le VPN lui-même semble sain.

Consignez la plage du pool, chaque adresse épinglée et l'hôte qui la possède dans les notes du serveur. La prochaine collision se repère alors en quelques minutes au lieu de demander tout un après-midi pour être redécouverte.