Dos propietaris, una adreça: IP duplicades en un pont TAP

Un client Windows manté 10.8.0.2 i funciona fins que canvia l'ordre d'arrencada; llavors la mateixa adreça es notifica com a conflicte i res del client no ha canviat. Un segon amfitrió al mateix segment pontitzat reclama el mateix valor, i la màquina que acaba de configurar-se l'última sol perdre. Tots dos creuen que en són propietaris, i el perdedor deixa silenciosament d'usar una adreça que se li havia dit que usés. Tractar-ho com un problema de temporització és el que fa que es repeteixi a cada reinici.

Llegiu les proves del conflicte abans de tocar cap pont

Windows informa d'un conflicte d'adreça juntament amb l'adreça de maquinari de l'altre reclamant. Aquesta adreça de maquinari és la dada útil, perquè correspon a una interfície en un amfitrió, mentre que el nom mostrat de l'esdeveniment no diu res sobre on viu el duplicat. Anoteu l'adreça de maquinari abans de canviar res.

La detecció de duplicats basada en ARP sondeja propietaris competidors abans que s'usi una adreça i continua vigilant després. Per això un amfitrió que era absent mentre configurau la xarxa encara pot causar un conflicte una hora més tard. La sonda no és una comprovació única a l'arrencada. Una màquina que apareix després pot prendre una adreça que ha estat en ús tranquil tot el dia, i per això la fallada es llegeix com una cursa i no com un error de configuració.

Un esdeveniment de conflicte per si sol no diu quina configuració va crear l'altra reclamació, i esborrar adreces experimentalment destrueix la correspondència que us ho hauria dit. El sentit de la prova és convertir una adreça de maquinari en una interfície que pugueu inspeccionar. Cercar a l'inventari pel nom de la màquina sol portar-vos a l'amfitrió equivocat.

Inventorieu cada reclamació del segment

Una instal·lació TAP pontitzada uneix segments Ethernet que abans eren separats, així que adreces que eren úniques dins de les seves xarxes poden xocar quan les trames comparteixen un enllaç. Per això aquesta classe de fallada existeix en una VPN i no existeix a les xarxes encaminades que va substituir. Enumerau tots els propietaris possibles en lloc del primer que sospiteu.

Recorreu la llista en aquest ordre: les adreces de cada dispositiu de pont i dels seus ports membres, el OpenVPN i qualsevol assignació fixa per client, i qualsevol servidor DHCP que cobreixi el segment pontitzat. Després feu coincidir l'adreça de maquinari de l'informe de conflicte amb les interfícies que heu trobat.

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

El pool i el rang DHCP són els dos propietaris que la gent oblida. Imprimiu tots dos rangs junts i busqueu un solapament abans de fer res més. Una adreça de pont assignada a mà i un pool que lliura el mateix valor xocaran tard o d'hora, i el xoc sembla aleatori fins que tots dos rangs s'imprimeixen costat a costat.

Numereu els ponts només on necessitin una identitat

En un pont d'amfitrió normal, el dispositiu de pont porta la configuració de tercer nivell de l'amfitrió i els membres Ethernet i TAP actuen com a ports. Donar a cada membre la seva pròpia adreça, o copiar un script de configuració a diverses màquines sense canviar l'adreça, és com un sol segment acaba amb tres propietaris del mateix valor. Els membres no necessiten identitats pròpies per reenviar trames. Necessiten exactament una identitat per amfitrió que hagi de ser abastable en aquest segment.

Un pont que només commuta trames no necessita cap adreça en aquest segment. Deixar-lo sense numerar elimina tota una classe de col·lisió, sempre que l'amfitrió encara tingui un camí de gestió que hàgiu verificat. Confirmeu l'accés primer, traieu l'adreça segon i comproveu l'abastabilitat tercer.

Si l'adreça que esteu a punt d'esborrar és l'única ruta cap a la màquina, esborrar-la com a experiment és una interrupció autoinfligida i no un diagnòstic. Verifiqueu el camí fora de banda abans de provar res.

Feu que la correcció sobrevisqui a un reinici

Canviar una interfície en directe arregla l'arrencada actual i res més. Tot el que recreï l'adreça a l'arrencada restaurarà el conflicte al proper reinici, i concloureu que la correcció no ha funcionat quan en realitat mai no va ser persistent. Anoteu quin fitxer heu canviat, perquè el proper reinici confirmi una decisió en lloc de revelar una sorpresa.

Trobeu el propietari d'aquesta configuració: un perfil de gestor de xarxa, un fitxer per interfície, una definició de contenidor o VM, o un fragment de cloud-init. Canvieu-lo allà, i després reinicieu deliberadament un amfitrió afectat per confirmar que el valor nou és el que torna. Un reinici és l'única prova que demostra la persistència.

Reserveu les adreces de pont dins del rang DHCP com a exclusions, o moveu-les fora. Una reserva que només existeix en un full de càlcul no és una exclusió, i l'assignador no la llegirà.

Demostreu-ho amb tots els clients en línia

Una connexió reeixida no demostra res, perquè el símptoma original només apareixia quan canviava l'ordre. Aixequeu tots els clients previstos, variegeu l'ordre d'arrencada i repetiu després d'una reconnexió. Després reinicieu l'amfitrió que solia perdre la cursa i confirmeu que l'adreça sobreviu.

Per a una confirmació directa, sondegeu si hi ha un propietari duplicat abans d'assignar l'adreça i vigileu la taula de veïns després. Si res no respon a la sonda i l'adreça es manté en propietat única durant un cicle complet de reinici, el conflicte està resolt i no només amagat. Les ordres següents fan les dues comprovacions al dispositiu de pont. RFC 5227 descriu el comportament de sonda i anunci que exerceixen aquestes eines, i és la referència a citar quan algú proposa desactivar la detecció.

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

Una sonda que no rep resposta és el resultat esperat en un segment net. Una sonda que atrau una resposta us dóna l'adreça de maquinari del propietari restant, la mateixa prova que l'esdeveniment de Windows us va donar al principi. Guardeu aquesta sortida amb el registre de canvis, perquè és l'única prova que l'adreça es manté de manera única.