Corriger un conflit d'adresse IP locale après s'être connecté à un VPN

Chacun de ces signalements sonne pareil et veut dire autre chose : l'ordinateur portable se plaint d'un conflit d'adresses, mais seulement parfois, et surtout pendant que le VPN est actif. Trois pannes distinctes produisent ce message : un vrai doublon sur votre propre lien, un chevauchement où le réseau distant utilise votre plage LAN et rien n'est dupliqué, et un tunnel qui a donné une adresse à deux pairs. La réparation diffère dans chaque cas, et la mauvaise déplace le symptôme au lieu de le supprimer. Décidez donc du cas qui est le vôtre avant de modifier quoi que ce soit.

Trois pannes qui partagent un message d'erreur

Un doublon signifie que deux machines du même segment revendiquent une adresse. Le noyau le remarque parce que la réponse à sa propre sonde vient d'une autre MAC, et ce qui se passe ensuite dépend de la pile : Linux le journalise, Windows désactive l'interface et écrit une entrée dans le journal système, et un client DHCP peut refuser l'offre.

Un chevauchement ne duplique aucune adresse. Votre LAN est 192.168.1.0/24, le réseau du bureau est aussi 192.168.1.0/24, et maintenant la route vers le bureau pointe vers des adresses qui sont aussi votre imprimante et votre NAS. Au sens ARP, rien n'est en conflit ; le paquet va simplement au mauvais appareil sur l'un des deux réseaux.

Une collision de pool est la faute du tunnel lui-même. Deux pairs ont été configurés avec ou ont reçu la même adresse de tunnel, donc le serveur ne peut pas les distinguer lorsqu'il envoie le trafic de retour. L'un des deux clients voit une poignée de main qui fonctionne et aucune donnée, ce qui se lit comme un problème de routage et n'en est pas un.

Test 1 : le doublon est-il sur votre propre segment ?

Commencez par lister ce que votre machine possède réellement, pas ce dont vous vous souvenez l'avoir configurée. Une adresse d'adaptateur VPN est privée au tunnel et n'est pas la même que l'adresse que voient les sites web, donc une sortie publique partagée n'est pas un conflit.

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Sous Windows, les mêmes informations viennent de ipconfig /all et Get-NetIPAddress, avec le cache des voisins dans arp -a. Si l'adresse contestée est sur l'adaptateur physique et que la plainte apparaît sans VPN en marche, le VPN est spectateur et vous devriez cesser de le diagnostiquer.

Pour prouver un doublon plutôt que deviner, sondez l'adresse depuis un appareil qui ne la possède pas. arping -D envoie la sonde avec une adresse source nulle, donc une réponse d'une MAC inattendue prouve qu'un autre hôte répond déjà pour cette adresse.

sudo arping -D -I eth0 -c 3 192.168.1.50

Cherchez ensuite le propriétaire via l'administrateur réseau au lieu de choisir vous-même une autre adresse. Les attributions statiques qui ne vivent que dans les notes de quelqu'un, les imprimantes à adresse fixe et les réservations sur le serveur DHCP sont les coupables habituels, et un appareil éteint possède toujours son bail.

Test 2 : les deux réseaux se chevauchent-ils ?

Comparez le préfixe que le tunnel vous donne avec les préfixes de vos propres interfaces. Si la plage distante est égale à votre LAN ou la contient, la panne est un chevauchement, et l'indice est qu'un hôte joignable sans le VPN disparaît, ou que votre propre imprimante répond sur une adresse du bureau.

ip route get 192.168.1.10
ip -br addr show

La recherche de route vous dit quelle interface le noyau utiliserait, et cette réponse est tout le diagnostic. Si elle indique le tunnel pour une adresse qui appartient à votre imprimante locale, vous avez un chevauchement et aucun renouvellement de bail n'y changera rien.

Il existe trois sorties honnêtes, et une seule vous est généralement accessible. Le côté distant peut masquer le trafic du sous-réseau qui se chevauche, si bien que votre client ne voit que l'adresse de tunnel du serveur. Le tunnel peut transporter un préfixe distant plus étroit qui n'entre pas en collision avec votre LAN. Ou le client peut router par adresse source avec des règles de politique, ce qui fonctionne mais reste fragile et difficile à transmettre à un collègue.

Renuméroter le réseau du bureau est rarement votre décision. Renuméroter votre propre LAN pour éviter la collision est un changement plus important que la plupart des gens ne l'imaginent dès que des imprimantes, des caméras et des hôtes statiques entrent en jeu.

Test 3 : le tunnel a-t-il distribué une adresse deux fois ?

WireGuard n'a pas de pool d'adresses. Chaque pair est identifié par sa clé publique et par les préfixes dans AllowedIPs, donc un doublon apparaît lorsque la même adresse de tunnel est écrite dans deux entrées de pair ou que la même paire de clés est installée sur deux machines.

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

Les compteurs de trafic sont la colonne utile ici : un pair qui affiche une poignée de main récente mais aucun transfert est soit mal adressé, soit masqué par une autre entrée qui revendique le même préfixe. Mettez un préfixe sur exactement un pair et donnez à chaque appareil sa propre paire de clés.

OpenVPN a bien un pool, et la collision courante est un profil client partagé avec une ligne --ifconfig fixe copiée sur une seconde machine. Les deux clients demandent alors la même adresse de tunnel, et le serveur accepte la session qu'il traite en premier. L'épuisement du pool avec --duplicate-cn produit un résultat similaire lorsque plusieurs sessions d'un même certificat se disputent une entrée.

Pour ce cas, lisez le journal du serveur plutôt que celui du client. Le serveur sait quelle session a pris quelle adresse, et les adresses répétées y apparaissent comme des avertissements qui n'atteignent jamais le client.

Réparez à la source, puis revérifiez les deux appareils

L'ordre compte. Corrigez d'abord un doublon de LAN, car un client qui ne peut pas garder une adresse ne peut pas garder un tunnel non plus. Corrigez ensuite l'approvisionnement côté VPN, car une modification côté client d'une attribution de pool est annulée à la prochaine connexion. Enfin, traitez les identités dupliquées : des paires de clés séparées sous WireGuard, des certificats séparés ou au moins des profils séparés sous OpenVPN.

Côté client, la partie mécanique est courte. Libérez et renouvelez un bail DHCP, ou demandez que l'adresse soit changée sur le serveur pour une réservation. Ne saisissez pas une adresse aléatoire qui semble libre.

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

Vérifiez ensuite des deux côtés, pas d'un seul. Confirmez la passerelle, puis le service dont vous avez réellement besoin, puis reconnectez-vous et répétez. Si deux appareils étaient impliqués, vérifiez les deux : déplacer une adresse laisse l'autre avec des entrées de voisins obsolètes ou un ancien bail qui réapparaît plus tard.

Ce qu'il ne faut pas faire en chemin

Ne faites pas taire le symptôme. La détection des adresses dupliquées est ce qui vous empêche de prendre une adresse déjà utilisée, et la désactiver transforme un conflit visible en perte de paquets intermittente, bien plus difficile à tracer. Il en va de même pour l'acceptation d'un avertissement de certificat provenant d'un hôte inattendu : ce n'est pas du tout un problème d'adresse, et cliquer dessus masque une autre panne.

Ne modifiez pas non plus l'adressage d'un réseau géré de votre propre chef. Notez le réglage d'origine, demandez au propriétaire lorsque l'adresse est attribuée de façon centralisée, et gardez la modification assez petite pour être annulée. Les règles RFC 5227 de détection des conflits d'adresses expliquent ce que prouve une sonde correcte, ce qu'il vaut la peine de savoir avant de qualifier un conflit de réel.