Corregir un conflicto de dirección IP local tras conectarse a una VPN

Cada uno de estos informes suena igual y significa algo distinto: el portátil se queja de un conflicto de direcciones, pero solo a veces, y sobre todo mientras la VPN está activa. Tres fallos distintos producen ese mensaje: un duplicado real en tu propio enlace, un solapamiento donde la red remota usa tu rango de LAN y no se duplica nada, y un túnel que entregó una dirección a dos pares. La reparación difiere en cada caso, y la equivocada traslada el síntoma en lugar de eliminarlo. Así que decide qué caso tienes antes de tocar nada.

Tres fallos que comparten un mensaje de error

Un duplicado significa que dos máquinas del mismo segmento reclaman una dirección. El núcleo lo nota porque la respuesta a su propia sonda llega desde un MAC distinto, y lo que pasa después depende de la pila: Linux lo registra, Windows desactiva la interfaz y escribe una entrada en el registro del sistema, y un cliente DHCP puede rechazar la oferta.

Un solapamiento no duplica ninguna dirección. Tu LAN es 192.168.1.0/24, la red de la oficina también es 192.168.1.0/24, y ahora la ruta hacia la oficina apunta a direcciones que también son tu impresora y tu NAS. En el sentido de ARP nada está en conflicto; el paquete simplemente va al dispositivo equivocado en una de las dos redes.

Una colisión en el pool es culpa del propio túnel. Dos pares se configuraron con o recibieron la misma dirección de túnel, así que el servidor no puede distinguirlos cuando envía tráfico de vuelta. Uno de los dos clientes ve un handshake que funciona y ningún dato, lo que se lee como un problema de enrutamiento y no lo es.

Prueba 1: ¿está el duplicado en tu propio segmento?

Empieza listando lo que tu máquina tiene realmente, no lo que recuerdas haber configurado. Una dirección de adaptador VPN es privada del túnel y no es la misma que la dirección que ven los sitios web, así que una salida pública compartida no es un conflicto.

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

En Windows la misma información sale de ipconfig /all y Get-NetIPAddress, con la caché de vecinos en arp -a. Si la dirección en disputa está en el adaptador físico y la queja aparece sin la VPN en marcha, la VPN es un espectador y deberías dejar de diagnosticarla.

Para demostrar un duplicado en vez de adivinar, sondea la dirección desde un dispositivo que no la posee. arping -D envía la sonda con una dirección de origen cero, así que una respuesta de un MAC inesperado demuestra que otro host ya responde por esa dirección.

sudo arping -D -I eth0 -c 3 192.168.1.50

Luego busca al propietario a través del administrador de red en lugar de elegir tú otra dirección. Las asignaciones estáticas que solo viven en las notas de alguien, las impresoras con dirección fija y las reservas del servidor DHCP son los culpables habituales, y un dispositivo apagado sigue poseyendo su concesión.

Prueba 2: ¿se solapan las dos redes?

Compara el prefijo que te da el túnel con los prefijos de tus propias interfaces. Si el rango remoto es igual o contiene tu LAN, el fallo es un solapamiento, y la pista es que un host accesible sin la VPN se apaga, o que tu propia impresora responde en una dirección de oficina.

ip route get 192.168.1.10
ip -br addr show

La consulta de ruta te dice qué interfaz usaría el núcleo, y esa respuesta es todo el diagnóstico. Si dice el túnel para una dirección que pertenece a tu impresora local, tienes un solapamiento y ninguna renovación de concesión lo cambiará.

Hay tres salidas honestas, y normalmente solo una está disponible para ti. El lado remoto puede enmascarar el tráfico de la subred solapada, así que tu cliente solo ve la dirección de túnel del servidor. El túnel puede llevar un prefijo remoto más estrecho que no choque con tu LAN. O el cliente puede enrutar por dirección de origen con reglas de política, lo que funciona pero es frágil y difícil de pasar a un compañero.

Renumerar la red de la oficina rara vez es decisión tuya. Renumerar tu propia LAN para evitar la colisión es un cambio mayor de lo que la mayoría espera en cuanto entran impresoras, cámaras y hosts estáticos.

Prueba 3: ¿entregó el túnel una dirección dos veces?

WireGuard no tiene pool de direcciones. Cada par se identifica por su clave pública y por los prefijos en AllowedIPs, así que un duplicado aparece cuando la misma dirección de túnel se escribe en dos entradas de par o el mismo par de claves se instala en dos máquinas.

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

Los contadores de tráfico son la columna útil aquí: un par que muestra un handshake reciente pero ninguna transferencia o está mal direccionado o queda a la sombra de otra entrada que reclama el mismo prefijo. Pon un prefijo en exactamente un par y da a cada dispositivo su propio par de claves.

OpenVPN sí tiene un pool, y la colisión habitual es un perfil de cliente compartido con una línea --ifconfig fija copiada a una segunda máquina. Entonces ambos clientes piden la misma dirección de túnel, y el servidor acepta la sesión que procesa primero. El agotamiento del pool con --duplicate-cn produce un resultado similar cuando varias sesiones de un certificado compiten por una entrada.

Para esto lee el registro del servidor en lugar del registro del cliente. El servidor sabe qué sesión reclamó qué dirección, y las direcciones repetidas allí se ven como avisos que nunca llegan al cliente.

Repara en el origen y vuelve a comprobar ambos dispositivos

El orden importa. Corrige primero un duplicado de LAN, porque un cliente que no puede mantener una dirección tampoco puede mantener un túnel. Luego corrige el aprovisionamiento del lado de la VPN, porque una edición del lado del cliente sobre una asignación del pool se deshace en la siguiente conexión. Por último, ocúpate de las identidades duplicadas: pares de claves separados en WireGuard, certificados separados o al menos perfiles separados en OpenVPN.

En el cliente la parte mecánica es corta. Libera y renueva una concesión DHCP, o pide que se cambie la dirección en el servidor para una reserva. No escribas una dirección aleatoria que parezca libre.

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

Luego verifica desde ambos extremos, no desde uno. Confirma la puerta de enlace, luego el servicio que realmente necesitas, luego vuelve a conectar y repite. Si había dos dispositivos implicados, comprueba ambos: mover una dirección deja al otro con entradas de vecinos obsoletas o una concesión antigua que reaparece más tarde.

Qué no hacer por el camino

No silencies el síntoma. La detección de direcciones duplicadas es lo que te impide tomar una dirección que ya está en uso, y desactivarla convierte un conflicto visible en pérdida de paquetes intermitente que es mucho más difícil de rastrear. Lo mismo se aplica a aceptar un aviso de certificado de un host inesperado: eso no es ningún problema de dirección, y pasar de largo oculta otro fallo.

Tampoco cambies por tu cuenta el direccionamiento de una red gestionada. Registra la configuración original, pregunta al propietario cuando la dirección se asigna de forma centralizada, y mantén el cambio lo bastante pequeño para revertirlo. Las reglas de detección de conflictos de direcciones de RFC 5227 explican qué demuestra una sonda correcta, algo que conviene saber antes de llamar real a un conflicto.