Corregeix un conflicte d'adreça IP local després de connectar-te a una VPN

Tots aquests informes sonen igual i signifiquen una cosa diferent: l'ordinador portàtil es queixa d'un conflicte d'adreces, però només de vegades, i sobretot mentre la VPN està activa. Tres errors separats produeixen aquest missatge: un duplicat real al teu propi enllaç, una superposició on la xarxa remota fa servir el teu rang de LAN i no es duplica res, i un túnel que va donar una adreça a dos parells. La reparació difereix en cada cas, i la incorrecta mou el símptoma en lloc d'eliminar-lo. Per tant, decideix quin cas tens abans de modificar res.

Tres errors que comparteixen un missatge d'error

Un duplicat vol dir que dues màquines del mateix segment reclamen una adreça. El nucli se n'adona perquè la resposta a la seva pròpia sonda arriba d'un MAC diferent, i el que passa després depèn de la pila: Linux ho registra, Windows desactiva la interfície i escriu una entrada al registre del sistema, i un client DHCP pot rebutjar l'oferta.

Una superposició no duplica cap adreça. La teva LAN és 192.168.1.0/24, la xarxa de l'oficina també és 192.168.1.0/24, i ara la ruta cap a l'oficina apunta a adreces que també són la teva impressora i el teu NAS. En el sentit ARP no hi ha cap conflicte; el paquet simplement va al dispositiu equivocat en una de les dues xarxes.

Una col·lisió al pool és culpa del mateix túnel. Dos parells es van configurar amb la mateixa adreça de túnel o la van rebre, així que el servidor no els pot distingir quan envia trànsit de tornada. Un dels dos clients veu un handshake que funciona i cap dada, cosa que es llegeix com un problema d'encaminament i no ho és.

Prova 1: el duplicat és al teu propi segment?

Comença llistant el que la teva màquina té realment, no el que recordes haver configurat. Una adreça d'adaptador VPN és privada del túnel i no és la mateixa que l'adreça que veuen els llocs web, així que una sortida pública compartida no és cap conflicte.

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

A Windows la mateixa informació surt de ipconfig /all i Get-NetIPAddress, amb la memòria cau de veïns a arp -a. Si l'adreça en disputa és a l'adaptador físic i la queixa apareix sense la VPN en marxa, la VPN és un espectador i hauries de deixar de diagnosticar-la.

Per demostrar un duplicat en lloc d'endevinar, sondeja l'adreça des d'un dispositiu que no la posseeix. arping -D envia la sonda amb una adreça d'origen zero, així que una resposta d'un MAC inesperat demostra que un altre host ja respon per aquesta adreça.

sudo arping -D -I eth0 -c 3 192.168.1.50

Després troba el propietari a través de l'administrador de xarxa en lloc de triar tu una altra adreça. Les assignacions estàtiques que només viuen a les notes d'algú, les impressores amb adreça fixa i les reserves al servidor DHCP són els culpables habituals, i un dispositiu apagat encara posseeix el seu arrendament.

Prova 2: se superposen les dues xarxes?

Compara el prefix que et dona el túnel amb els prefixos de les teves interfícies. Si el rang remot és igual o conté la teva LAN, la fallada és una superposició, i la pista és que un host accessible sense la VPN s'apaga, o que la teva impressora respon en una adreça de l'oficina.

ip route get 192.168.1.10
ip -br addr show

La consulta de ruta et diu quina interfície faria servir el nucli, i aquesta resposta és tot el diagnòstic. Si diu el túnel per a una adreça que pertany a la teva impressora local, tens una superposició i cap renovació d'arrendament ho canviarà.

Hi ha tres sortides honestes, i normalment només una està disponible per a tu. El costat remot pot emmascarar el trànsit de la subxarxa superposada, així que el teu client només veu l'adreça de túnel del servidor. El túnel pot portar un prefix remot més estret que no xoca amb la teva LAN. O el client pot encaminar per adreça d'origen amb regles de política, cosa que funciona però és fràgil i difícil de passar a un company.

Renumerar la xarxa de l'oficina poques vegades és decisió teva. Renumerar la teva pròpia LAN per evitar la col·lisió és un canvi més gran del que la majoria espera quan hi ha impressores, càmeres i hosts estàtics.

Prova 3: el túnel va donar una adreça dues vegades?

WireGuard no té cap pool d'adreces. Cada parell s'identifica per la seva clau pública i pels prefixos a AllowedIPs, així que un duplicat apareix quan la mateixa adreça de túnel s'escriu en dues entrades de parell o el mateix parell de claus s'instal·la en dues màquines.

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

Els comptadors de trànsit són la columna útil aquí: un parell que mostra un handshake recent però cap transferència o està mal adreçat o queda a l'ombra d'una altra entrada que reclama el mateix prefix. Posa un prefix exactament en un parell i dona a cada dispositiu el seu propi parell de claus.

OpenVPN sí que té un pool, i la col·lisió habitual és un perfil de client compartit amb una línia --ifconfig fixa copiada a una segona màquina. Llavors tots dos clients demanen la mateixa adreça de túnel, i el servidor accepta la sessió que processa primer. L'esgotament del pool amb --duplicate-cn produeix un resultat similar quan diverses sessions d'un certificat competeixen per una entrada.

Per a aquest cas llegeix el registre del servidor en lloc del registre del client. El servidor sap quina sessió va reclamar quina adreça, i les adreces repetides allà es veuen com avisos que mai arriben al client.

Repara a l'origen i torna a comprovar els dos dispositius

L'ordre importa. Corregeix primer un duplicat de LAN, perquè un client que no pot mantenir una adreça tampoc no pot mantenir un túnel. Després corregeix l'aprovisionament al costat de la VPN, perquè una edició al costat del client d'una assignació del pool es desfà a la propera connexió. Finalment, tracta les identitats duplicades: parells de claus separats a WireGuard, certificats separats o almenys perfils separats a OpenVPN.

Al client la part mecànica és curta. Allibera i renova un arrendament DHCP, o demana que es canviï l'adreça al servidor per a una reserva. No escriguis una adreça aleatòria que sembli lliure.

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

Després verifica des de tots dos extrems, no des d'un. Confirma la passarel·la, després el servei que realment necessites, després reconnecta i repeteix. Si hi havia dos dispositius implicats, comprova'ls tots dos: moure una adreça deixa l'altre amb entrades de veïns obsoletes o un arrendament antic que reapareix més tard.

Què no has de fer pel camí

No silenciïs el símptoma. La detecció d'adreces duplicades és el que t'impedeix agafar una adreça que ja s'usa, i desactivar-la converteix un conflicte visible en pèrdua de paquets intermitent que és molt més difícil de rastrejar. El mateix s'aplica a acceptar un avís de certificat d'un host inesperat: això no és cap problema d'adreça i passar-lo per alt amaga una fallada diferent.

Tampoc no canviïs pel teu compte l'adreçament d'una xarxa gestionada. Registra la configuració original, pregunta al propietari quan l'adreça s'assigna de manera centralitzada, i mantingues el canvi prou petit per revertir-lo. Les regles RFC 5227 de detecció de conflictes d'adreces expliquen què demostra una sonda correcta, cosa que val la pena saber abans de qualificar un conflicte de real.