Deux propriétaires, une adresse : IP dupliquées sur un pont TAP

Un client Windows conserve 10.8.0.2 et fonctionne jusqu'à ce que l'ordre de démarrage change ; la même adresse est alors signalée comme un conflit alors que rien n'a changé sur le client. Un second hôte sur le même segment ponté revendique la même valeur, et la machine qui termine sa configuration en dernier perd généralement. Les deux croient la posséder, et le perdant cesse discrètement d'utiliser une adresse qu'on lui avait dit d'utiliser. C'est le fait de traiter cela comme un problème de timing qui le fait revenir à chaque redémarrage.

Lisez les preuves du conflit avant de toucher à un pont

Windows signale un conflit d'adresse avec l'adresse matérielle de l'autre demandeur. Cette adresse matérielle est le fait utile, car elle correspond à une interface sur un hôte, tandis que le nom affiché de l'événement ne dit rien sur l'endroit où se trouve le doublon. Notez l'adresse matérielle avant de changer quoi que ce soit.

La détection de doublons fondée sur ARP sonde les propriétaires concurrents avant qu'une adresse soit utilisée et continue de surveiller ensuite. C'est pourquoi un hôte absent pendant que vous configuriez le réseau peut encore provoquer un conflit une heure plus tard. La sonde n'est pas une vérification unique au démarrage. Une machine qui apparaît ensuite peut prendre une adresse utilisée tranquillement toute la journée, et c'est pourquoi la panne se lit comme une course plutôt que comme une erreur de configuration.

Un événement de conflit seul ne dit pas quelle configuration a créé l'autre revendication, et effacer des adresses à titre expérimental détruit la correspondance qui vous l'aurait dit. Le but de la preuve est de transformer une adresse matérielle en une interface que vous pouvez inspecter. Chercher dans l'inventaire par nom de machine vous envoie généralement au mauvais hôte.

Inventoriez chaque revendication du segment

Une installation TAP pontée réunit des segments Ethernet qui étaient séparés, si bien que des adresses uniques dans leurs propres réseaux peuvent entrer en collision dès que les trames partagent un lien. C'est pourquoi cette classe de panne existe sur un VPN et n'existe pas sur les réseaux routés qu'elle a remplacés. Énumérez tous les propriétaires possibles plutôt que le premier que vous soupçonnez.

Parcourez la liste dans cet ordre : les adresses de chaque périphérique de pont et de ses ports membres, le OpenVPN et toute attribution fixe par client, ainsi que tout serveur DHCP couvrant le segment ponté. Faites ensuite correspondre l'adresse matérielle du rapport de conflit aux interfaces trouvées.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

Le pool et la plage DHCP sont les deux propriétaires qu'on oublie. Imprimez les deux plages ensemble et cherchez un chevauchement avant de faire quoi que ce soit d'autre. Une adresse de pont attribuée à la main et un pool qui distribue la même valeur finiront par entrer en collision, et la collision semble aléatoire jusqu'à ce que les deux plages soient imprimées côte à côte.

Numérotez les ponts uniquement là où ils ont besoin d'une identité

Dans un pont d'hôte normal, le périphérique de pont porte la configuration de troisième couche de l'hôte et les membres Ethernet et TAP agissent comme des ports. Donner à chaque membre sa propre adresse, ou copier un script d'installation sur plusieurs machines sans changer l'adresse, voilà comment un seul segment finit avec trois propriétaires de la même valeur. Les membres n'ont pas besoin d'identités propres pour transmettre des trames. Il leur faut exactement une identité par hôte qui doit être joignable sur ce segment.

Un pont qui ne fait que commuter des trames n'a pas besoin d'adresse sur ce segment. Le laisser sans numéro supprime toute une classe de collision, à condition que l'hôte conserve un chemin de gestion que vous avez vérifié. Vérifiez l'accès d'abord, retirez l'adresse ensuite, et contrôlez la joignabilité en troisième.

Si l'adresse que vous êtes sur le point de supprimer est le seul chemin vers la machine, la supprimer à titre d'expérience est une panne auto-infligée et non un diagnostic. Vérifiez le chemin hors bande avant de tester quoi que ce soit.

Faites survivre la correction à un redémarrage

Modifier une interface en service corrige le démarrage en cours et rien d'autre. Tout ce qui recrée l'adresse au démarrage rétablira le conflit au redémarrage suivant, et vous conclurez que la correction n'a pas marché alors qu'en réalité elle n'a jamais été persistante. Notez quel fichier vous avez modifié, afin que le redémarrage suivant confirme une décision au lieu de révéler une surprise.

Trouvez le propriétaire de cette configuration : un profil de gestionnaire de réseau, un fichier par interface, une définition de conteneur ou de VM, ou un fragment cloud-init. Modifiez-la à cet endroit, puis redémarrez délibérément un hôte touché pour confirmer que la nouvelle valeur est bien celle qui revient. Un redémarrage est le seul test qui prouve la persistance.

Réservez les adresses du pont à l'intérieur de la plage DHCP comme exclusions, ou déplacez-les en dehors. Une réservation qui n'existe que dans un tableur n'est pas une exclusion, et l'attributaire ne la lira pas.

Prouvez-le avec tous les clients en ligne

Une seule connexion réussie ne prouve rien, car le symptôme d'origine n'apparaissait que lorsque l'ordre changeait. Démarrez tous les clients prévus, faites varier l'ordre de démarrage et répétez après une reconnexion. Redémarrez ensuite l'hôte qui perdait la course et confirmez que l'adresse survit.

Pour une confirmation directe, sondez la présence d'un propriétaire en double avant d'attribuer l'adresse et surveillez la table des voisins ensuite. Si rien ne répond à la sonde et que l'adresse reste détenue de façon unique pendant un cycle complet de redémarrage, le conflit est résolu et non simplement masqué. Les commandes ci-dessous effectuent les deux vérifications sur le périphérique de pont. RFC 5227 décrit le comportement de sonde et d'annonce que ces outils exercent, et c'est la référence à citer quand quelqu'un propose de désactiver la détection.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

Une sonde sans réponse est le résultat attendu sur un segment propre. Une sonde qui suscite une réponse vous donne l'adresse matérielle du propriétaire restant, la même preuve que l'événement Windows vous avait donnée au départ. Conservez cette sortie avec le journal des changements, car c'est la seule preuve que l'adresse est détenue de façon unique.