Corrixir un conflito de enderezo IP local tras conectarse a unha VPN

Cada un destes informes soa igual e significa algo distinto: o portátil quéixase dun conflito de enderezos, pero só ás veces, e sobre todo mentres a VPN está activa. Tres fallos distintos producen esa mensaxe: un duplicado real na túa propia ligazón, un solapamento onde a rede remota usa o teu rango de LAN e non se duplica nada, e un túnel que deu un enderezo a dous pares. A reparación difire en cada caso, e a equivocada traslada o síntoma en lugar de eliminalo. Así que decide que caso tes antes de tocar nada.

Tres fallos que comparten unha mensaxe de erro

Un duplicado significa que dúas máquinas do mesmo segmento reclaman un enderezo. O núcleo nótao porque a resposta á súa propia sonda chega desde un MAC distinto, e o que pasa despois depende da pila: Linux rexístrao, Windows desactiva a interface e escribe unha entrada no rexistro do sistema, e un cliente DHCP pode rexeitar a oferta.

Un solapamento non duplica ningún enderezo. A túa LAN é 192.168.1.0/24, a rede da oficina tamén é 192.168.1.0/24, e agora a ruta cara á oficina apunta a enderezos que tamén son a túa impresora e o teu NAS. No sentido ARP nada está en conflito; o paquete simplemente vai ao dispositivo equivocado nunha das dúas redes.

Unha colisión no pool é culpa do propio túnel. Dous pares configuráronse con ou recibiron o mesmo enderezo de túnel, así que o servidor non pode distinguilos cando envía tráfico de volta. Un dos dous clientes ve un handshake que funciona e ningún dato, o que se le como un problema de encamiñamento e non o é.

Proba 1: está o duplicado no teu propio segmento?

Comeza listando o que a túa máquina ten realmente, non o que recordas ter configurado. Un enderezo de adaptador VPN é privado do túnel e non é o mesmo que o enderezo que ven os sitios web, así que unha saída pública compartida non é un conflito.

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

En Windows a mesma información sae de ipconfig /all e Get-NetIPAddress, coa caché de veciños en arp -a. Se o enderezo en disputa está no adaptador físico e a queixa aparece sen a VPN en marcha, a VPN é un espectador e deberías deixar de diagnosticala.

Para demostrar un duplicado en vez de adiviñar, sonda o enderezo desde un dispositivo que non o posúe. arping -D envía a sonda cun enderezo de orixe cero, así que unha resposta dun MAC inesperado demostra que outro host xa responde por ese enderezo.

sudo arping -D -I eth0 -c 3 192.168.1.50

Despois atopa o propietario a través do administrador de rede en lugar de escoller ti outro enderezo. As asignacións estáticas que só viven nas notas de alguén, as impresoras con enderezo fixo e as reservas no servidor DHCP son os culpables habituais, e un dispositivo apagado segue posuíndo a súa concesión.

Proba 2: solápanse as dúas redes?

Compara o prefixo que che dá o túnel cos prefixos das túas propias interfaces. Se o rango remoto é igual ou contén a túa LAN, o fallo é un solapamento, e a pista é que un host accesible sen a VPN se apaga, ou que a túa propia impresora responde nun enderezo da oficina.

ip route get 192.168.1.10
ip -br addr show

A consulta de ruta diche que interface usaría o núcleo, e esa resposta é todo o diagnóstico. Se di o túnel para un enderezo que pertence á túa impresora local, tes un solapamento e ningunha renovación de concesión o cambiará.

Hai tres saídas honestas, e normalmente só unha está dispoñible para ti. O lado remoto pode enmascarar o tráfico da subrede solapada, así que o teu cliente só ve o enderezo de túnel do servidor. O túnel pode levar un prefixo remoto máis estreito que non choca coa túa LAN. Ou o cliente pode encamiñar por enderezo de orixe con regras de política, o que funciona pero é fráxil e difícil de pasar a un compañeiro.

Renumerar a rede da oficina raramente é decisión túa. Renumerar a túa propia LAN para evitar a colisión é un cambio maior do que a maioría espera en canto entran impresoras, cámaras e hosts estáticos.

Proba 3: deu o túnel un enderezo dúas veces?

WireGuard non ten pool de enderezos. Cada par identifícase pola súa clave pública e polos prefixos en AllowedIPs, así que un duplicado aparece cando o mesmo enderezo de túnel se escribe en dúas entradas de par ou o mesmo par de claves se instala en dúas máquinas.

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

Os contadores de tráfico son a columna útil aquí: un par que mostra un handshake recente pero ningunha transferencia ou está mal enderezado ou queda á sombra doutra entrada que reclama o mesmo prefixo. Pon un prefixo exactamente nun par e dálle a cada dispositivo o seu propio par de claves.

OpenVPN si ten un pool, e a colisión habitual é un perfil de cliente compartido cunha liña --ifconfig fixa copiada a unha segunda máquina. Entón ambos clientes piden o mesmo enderezo de túnel, e o servidor acepta a sesión que procesa primeiro. O esgotamento do pool con --duplicate-cn produce un resultado similar cando varias sesións dun certificado compiten por unha entrada.

Para isto le o rexistro do servidor en lugar do rexistro do cliente. O servidor sabe que sesión reclamou que enderezo, e os enderezos repetidos alí vense como avisos que nunca chegan ao cliente.

Repara na orixe e logo comproba de novo os dous dispositivos

A orde importa. Corrixe primeiro un duplicado de LAN, porque un cliente que non pode manter un enderezo tampouco pode manter un túnel. Despois corrixe o aprovisionamento do lado da VPN, porque unha edición do lado do cliente sobre unha asignación do pool desfacerse na seguinte conexión. Por último, ocúpate das identidades duplicadas: pares de claves separados en WireGuard, certificados separados ou polo menos perfís separados en OpenVPN.

No cliente a parte mecánica é curta. Libera e renova unha concesión DHCP, ou pide que se cambie o enderezo no servidor para unha reserva. Non escribas un enderezo aleatorio que pareza libre.

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

Despois verifica desde ambos extremos, non desde un. Confirma a pasarela, despois o servizo que realmente necesitas, despois reconecta e repite. Se había dous dispositivos implicados, comproba ambos: mover un enderezo deixa o outro con entradas de veciños obsoletas ou unha concesión antiga que reaparece máis tarde.

Que non facer polo camiño

Non silencies o síntoma. A detección de enderezos duplicados é o que che impide coller un enderezo que xa está en uso, e desactivala converte un conflito visible en perda de paquetes intermitente que é moito máis difícil de rastrexar. O mesmo se aplica a aceptar un aviso de certificado dun host inesperado: iso non é ningún problema de enderezo, e pasalo por alto agocha outro fallo.

Tampouco cambies pola túa conta o enderezamento dunha rede xestionada. Rexistra a configuración orixinal, pregunta ao propietario cando o enderezo se asigna de forma centralizada, e mantén o cambio o bastante pequeno para revertelo. As regras RFC 5227 de detección de conflitos de enderezos explican que demostra unha sonda correcta, algo que paga a pena saber antes de cualificar un conflito de real.