Dos propietarios, una dirección: IP duplicadas en un puente TAP

Un cliente Windows conserva 10.8.0.2 y funciona hasta que cambia el orden de arranque; entonces la misma dirección se notifica como conflicto y nada del cliente ha cambiado. Un segundo host en el mismo segmento puenteado reclama el mismo valor, y la máquina que termina de configurarse la última suele perder. Ambos creen ser sus dueños, y el perdedor deja en silencio de usar una dirección que se le dijo que usara. Tratar esto como un problema de temporización es lo que hace que se repita en cada reinicio.

Lea las pruebas del conflicto antes de tocar un puente

Windows informa de un conflicto de dirección junto con la dirección de hardware del otro reclamante. Esa dirección de hardware es el dato útil, porque apunta a una interfaz en un host, mientras que el nombre mostrado del evento no dice nada sobre dónde vive el duplicado. Anote la dirección de hardware antes de cambiar nada.

La detección de duplicados basada en ARP sondea a los propietarios competidores antes de usar una dirección y sigue vigilando después. Por eso un host que estaba ausente mientras configuraba la red puede provocar un conflicto una hora más tarde. El sondeo no es una comprobación única al arrancar. Una máquina que aparece después puede tomar una dirección que estuvo en uso tranquilo todo el día, y por eso el fallo se lee como una carrera y no como un error de configuración.

Un evento de conflicto por sí solo no dice qué configuración creó la otra reclamación, y borrar direcciones de forma experimental destruye la correspondencia que se lo habría dicho. El objetivo de la prueba es convertir una dirección de hardware en una interfaz que pueda inspeccionar. Buscar en el inventario por nombre de máquina suele llevarle al host equivocado.

Inventaríe todas las reclamaciones del segmento

Una instalación TAP puenteada une segmentos Ethernet que antes estaban separados, así que direcciones que eran únicas dentro de sus propias redes pueden chocar en cuanto las tramas comparten un enlace. Por eso esta clase de fallo existe en una VPN y no existe en las redes enrutadas que sustituyó. Enumere todos los propietarios posibles en lugar del primero que sospeche.

Recorra la lista en este orden: las direcciones de cada dispositivo de puente y de sus puertos miembros, el OpenVPN y cualquier asignación fija por cliente, y cualquier servidor DHCP que cubra el segmento puenteado. Después haga coincidir la dirección de hardware del informe de conflicto con las interfaces que encontró.

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

El grupo y el rango DHCP son los dos propietarios que la gente olvida. Imprima ambos rangos juntos y busque un solapamiento antes de hacer cualquier otra cosa. Una dirección de puente asignada a mano y un grupo que entrega el mismo valor chocarán tarde o temprano, y el choque parece aleatorio hasta que ambos rangos se imprimen uno al lado del otro.

Numere los puentes solo donde necesiten una identidad

En un puente de host normal, el dispositivo de puente lleva la configuración de tercer nivel del host y los miembros Ethernet y TAP actúan como puertos. Dar a cada miembro su propia dirección, o copiar un script de instalación en varias máquinas sin cambiar la dirección, es como un solo segmento acaba con tres propietarios del mismo valor. Los miembros no necesitan identidades propias para reenviar tramas. Necesitan exactamente una identidad por host que deba ser alcanzable en ese segmento.

Un puente que solo conmuta tramas no necesita ninguna dirección en ese segmento. Dejarlo sin numerar elimina toda una clase de colisión, siempre que el host conserve una ruta de gestión que haya verificado. Confirme el acceso primero, quite la dirección segundo y compruebe la alcanzabilidad tercero.

Si la dirección que va a borrar es la única ruta hacia la máquina, borrarla como experimento es una interrupción autoinfligida y no un diagnóstico. Verifique la ruta fuera de banda antes de probar nada.

Haga que la corrección sobreviva a un reinicio

Cambiar una interfaz en vivo arregla el arranque actual y nada más. Lo que sea que recrea la dirección al arrancar restaurará el conflicto en el siguiente reinicio, y usted concluirá que la corrección no funcionó cuando en realidad nunca fue persistente. Anote qué archivo cambió, para que el siguiente reinicio confirme una decisión en lugar de revelar una sorpresa.

Encuentre el propietario de esa configuración: un perfil del gestor de red, un archivo por interfaz, una definición de contenedor o VM, o un fragmento de cloud-init. Cámbielo allí y luego reinicie deliberadamente un host afectado para confirmar que el valor nuevo es el que vuelve. Un reinicio es la única prueba que demuestra la persistencia.

Reserve las direcciones de puente dentro del rango DHCP como exclusiones, o muévalas fuera de él. Una reserva que solo existe en una hoja de cálculo no es una exclusión, y el asignador no la leerá.

Demuéstrelo con todos los clientes en línea

Una sola conexión correcta no demuestra nada, porque el síntoma original solo aparecía cuando cambiaba el orden. Levante todos los clientes previstos, varíe el orden de arranque y repita tras una reconexión. Luego reinicie el host que solía perder la carrera y confirme que la dirección sobrevive.

Para una confirmación directa, sondee si hay un propietario duplicado antes de asignar la dirección y vigile la tabla de vecinos después. Si nada responde al sondeo y la dirección sigue siendo de propiedad única durante un ciclo completo de reinicio, el conflicto está resuelto y no solo oculto. Los comandos siguientes realizan ambas comprobaciones en el dispositivo de puente. RFC 5227 describe el comportamiento de sondeo y anuncio que ejercen estas herramientas, y es la referencia que se debe citar cuando alguien propone desactivar la detección.

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

Un sondeo que no recibe respuesta es el resultado esperado en un segmento limpio. Un sondeo que atrae una respuesta le da la dirección de hardware del propietario restante, la misma prueba que el evento de Windows le dio al principio. Guarde esa salida con el registro de cambios, porque es la única prueba de que la dirección se mantiene de forma única.