Dous propietarios, un enderezo: IP duplicadas nunha ponte TAP

Un cliente Windows conserva 10.8.0.2 e funciona ata que cambia a orde de arranque; entón o mesmo enderezo notifícase como conflito e nada do cliente cambiou. Un segundo host no mesmo segmento ponteado reclama o mesmo valor, e a máquina que remata de configurarse a última adoita perder. Ambos cren que son os seus donos, e o perdedor deixa en silencio de usar un enderezo que se lle dixo que usase. Tratar isto como un problema de temporización é o que fai que se repita en cada reinicio.

Lea as probas do conflito antes de tocar unha ponte

Windows informa dun conflito de enderezo xunto co enderezo de hardware do outro reclamante. Ese enderezo de hardware é o dato útil, porque apunta a unha interface nun host, mentres que o nome mostrado do evento non di nada sobre onde vive o duplicado. Anote o enderezo de hardware antes de cambiar nada.

A detección de duplicados baseada en ARP sonda os propietarios competidores antes de usar un enderezo e segue vixiando despois. Por iso un host que estaba ausente mentres configuraba a rede aínda pode causar un conflito unha hora despois. A sonda non é unha comprobación única no arranque. Unha máquina que aparece despois pode tomar un enderezo que estivo en uso tranquilo todo o día, e por iso o fallo lese como unha carreira e non como un erro de configuración.

Un evento de conflito por si só non di que configuración creou a outra reclamación, e borrar enderezos de forma experimental destrúe a correspondencia que cho diría. O sentido da proba é converter un enderezo de hardware nunha interface que poida inspeccionar. Buscar no inventario polo nome da máquina adoita levalo ao host equivocado.

Inventaríe todas as reclamacións do segmento

Unha instalación TAP ponteada une segmentos Ethernet que antes estaban separados, así que enderezos que eran únicos dentro das súas propias redes poden chocar en canto as tramas comparten unha ligazón. Por iso esta clase de fallo existe nunha VPN e non existe nas redes encamiñadas que substituíu. Enumere todos os propietarios posibles en lugar do primeiro que sospeite.

Percorra a lista nesta orde: os enderezos de cada dispositivo de ponte e dos seus portos membros, o OpenVPN e calquera asignación fixa por cliente, e calquera servidor DHCP que cubra o segmento ponteado. Despois faga coincidir o enderezo de hardware do informe de conflito coas interfaces que atopou.

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

O grupo e o rango DHCP son os dous propietarios que a xente esquece. Imprima ambos os rangos xuntos e busque un solapamento antes de facer calquera outra cousa. Un enderezo de ponte asignado a man e un grupo que entrega o mesmo valor chocarán tarde ou cedo, e o choque parece aleatorio ata que ambos os rangos se imprimen un ao lado do outro.

Numere as pontes só onde necesiten unha identidade

Nunha ponte de host normal, o dispositivo de ponte leva a configuración de terceiro nivel do host e os membros Ethernet e TAP actúan como portos. Dar a cada membro o seu propio enderezo, ou copiar un script de instalación a varias máquinas sen cambiar o enderezo, é como un só segmento acaba con tres propietarios do mesmo valor. Os membros non necesitan identidades propias para reenviar tramas. Necesitan exactamente unha identidade por host que deba ser alcanzable nese segmento.

Unha ponte que só conmuta tramas non necesita ningunha dirección nese segmento. Deixala sen numerar elimina toda unha clase de colisión, sempre que o host conserve unha ruta de xestión que verificase. Confirme o acceso primeiro, quite o enderezo segundo e comprobe a alcanzabilidade terceiro.

Se o enderezo que vai borrar é a única ruta cara á máquina, borralo como experimento é unha interrupción autoinflixida e non un diagnóstico. Verifique a ruta fóra de banda antes de probar nada.

Faga que a corrección sobreviva a un reinicio

Cambiar unha interface en vivo arranxa o arranque actual e nada máis. O que sexa que recrea o enderezo no arranque restaurará o conflito no seguinte reinicio, e vostede concluirá que a corrección non funcionou cando en realidade nunca foi persistente. Anote que ficheiro cambiou, para que o seguinte reinicio confirme unha decisión en lugar de revelar unha sorpresa.

Atope o propietario desa configuración: un perfil do xestor de rede, un ficheiro por interface, unha definición de contedor ou VM, ou un fragmento de cloud-init. Cámbieo alí e despois reinicie deliberadamente un host afectado para confirmar que o valor novo é o que volve. Un reinicio é a única proba que demostra a persistencia.

Reserve os enderezos de ponte dentro do rango DHCP como exclusións, ou móvaos fóra del. Unha reserva que só existe nunha folla de cálculo non é unha exclusión, e o asignador non a lerá.

Demostre iso con todos os clientes en liña

Unha soa conexión correcta non demostra nada, porque o síntoma orixinal só aparecía cando cambiaba a orde. Levante todos os clientes previstos, varíe a orde de arranque e repita tras unha reconexión. Despois reinicie o host que adoita perder a carreira e confirme que o enderezo sobrevive.

Para unha confirmación directa, sondee se hai un propietario duplicado antes de asignar o enderezo e vixíe a táboa de veciños despois. Se nada responde á sonda e o enderezo segue sendo de propiedade única durante un ciclo completo de reinicio, o conflito está resolto e non só oculto. Os comandos seguintes realizan ambas as comprobacións no dispositivo de ponte. RFC 5227 describe o comportamento de sonda e anuncio que exercen estas ferramentas, e é a referencia que se debe citar cando alguén propón desactivar a detección.

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

Unha sonda que non recibe resposta é o resultado esperado nun segmento limpo. Unha sonda que atrae unha resposta dálle o enderezo de hardware do propietario restante, a mesma proba que o evento de Windows lle deu ao principio. Garde esa saída co rexistro de cambios, porque é a única proba de que o enderezo se mantén de forma única.