Corrigir um conflito de endereço IP local depois de ligar a uma VPN

Todos estes relatórios soam igual e significam coisas diferentes: o portátil queixa-se de um conflito de endereço, mas só às vezes e sobretudo com a VPN ligada. Três falhas distintas produzem essa mensagem: uma duplicação verdadeira na sua própria ligação, uma sobreposição em que a rede remota usa o intervalo da sua LAN e nada está duplicado, e um túnel que entregou um endereço a dois peers. A reparação é diferente em cada caso, e a errada move o sintoma em vez de o remover. Por isso decida que caso tem antes de alterar o que quer que seja.

Três falhas que partilham uma mensagem de erro

Uma duplicação significa que duas máquinas no mesmo segmento reivindicam um endereço. O kernel nota-o porque a resposta à sua própria sonda vem de um MAC diferente, e o que acontece a seguir depende da pilha: o Linux registra-o no log, o Windows desativa a interface e escreve uma entrada no log do sistema, e um cliente DHCP pode recusar a oferta.

Uma sobreposição não duplica endereço nenhum. A sua LAN é 192.168.1.0/24, a rede do escritório também é 192.168.1.0/24, e agora a rota para o escritório aponta para endereços que são também a sua impressora e o seu NAS. Nada está em conflito no sentido ARP; o pacote vai simplesmente para o dispositivo errado numa das duas redes.

Uma colisão na pool é culpa do próprio túnel. Dois peers foram configurados com ou receberam o mesmo endereço de túnel, por isso o servidor não os consegue distinguir quando envia tráfego de retorno. Um dos dois clientes vê um handshake a funcionar e nenhum dado, o que parece um problema de encaminhamento e não é.

Teste 1: a duplicação está no seu próprio segmento?

Comece por listar o que a sua máquina tem de facto, não o que se lembra de ter configurado. O endereço de um adaptador VPN é privado do túnel e não é o mesmo endereço que os sites veem, por isso uma saída pública partilhada não é um conflito.

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

No Windows a mesma informação vem de ipconfig /all e Get-NetIPAddress, com a cache de vizinhos em arp -a. Se o endereço disputado está no adaptador físico e a queixa aparece sem a VPN em execução, a VPN é uma espectadora e deve parar de a diagnosticar.

Para provar uma duplicação em vez de adivinhar, sonda o endereço a partir de um dispositivo que não o possua. arping -D envia a sonda com um endereço de origem zero, por isso uma resposta de um MAC inesperado prova que outro host já responde por esse endereço.

sudo arping -D -I eth0 -c 3 192.168.1.50

Depois encontre o dono através do administrador de rede em vez de escolher outro endereço por si. Atribuições estáticas que só existem nas notas de alguém, impressoras com endereço fixo e reservas no servidor DHCP são os culpados habituais, e um dispositivo desligado continua a ser dono do seu lease.

Teste 2: as duas redes sobrepõem-se?

Compare o prefixo que o túnel lhe dá com os prefixos das suas próprias interfaces. Se o intervalo remoto for igual ao da sua LAN ou a contiver, a falha é sobreposição, e o sinal revelador é que um host alcançável sem a VPN fica escuro, ou que a sua própria impressora responde num endereço do escritório.

ip route get 192.168.1.10
ip -br addr show

A consulta de rota diz-lhe que interface o kernel usaria, e essa resposta é todo o diagnóstico. Se disser o túnel para um endereço que pertence à sua impressora local, tem uma sobreposição e nenhuma renovação de lease o muda.

Há três saídas honestas, e normalmente só uma está disponível para si. O lado remoto pode fazer masquerade do tráfego para a sub-rede sobreposta, para que o seu cliente só veja o endereço de túnel do servidor. O túnel pode transportar um prefixo remoto mais estreito que não colida com a sua LAN. Ou o cliente pode encaminhar por endereço de origem com regras de política, o que funciona mas é frágil e difícil de passar a um colega.

Renumerar a rede do escritório raramente é decisão sua. Renumerar a sua própria LAN para evitar a colisão é uma mudança maior do que a maioria das pessoas espera quando estão envolvidas impressoras, câmaras e hosts estáticos.

Teste 3: o túnel entregou um endereço duas vezes?

O WireGuard não tem pool de endereços. Cada peer é identificado pela sua chave pública e pelos prefixos em AllowedIPs, por isso uma duplicação aparece quando o mesmo endereço de túnel é escrito em duas entradas de peer ou o mesmo par de chaves é instalado em duas máquinas.

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

Os contadores de tráfego são a coluna útil aqui: um peer que mostra um handshake recente mas nenhuma transferência está mal endereçado ou a ser ofuscado por outra entrada que reivindica o mesmo prefixo. Ponha um prefixo em exatamente um peer e dê a cada dispositivo o seu próprio par de chaves.

OpenVPN tem uma pool, e a colisão comum é um perfil de cliente partilhado com uma linha --ifconfig fixa copiada para uma segunda máquina. Ambos os clientes pedem então o mesmo endereço de túnel, e o servidor aceita a sessão que processar primeiro. O esgotamento da pool com --duplicate-cn produz um resultado semelhante quando várias sessões de um certificado competem por uma entrada.

Leia o log do servidor em vez do log do cliente para isto. O servidor sabe que sessão reivindicou que endereço, e endereços repetidos são aí visíveis como avisos que nunca chegam ao cliente.

Repare na origem e volte a verificar os dois dispositivos

A ordem importa. Corrija primeiro uma duplicação na LAN, porque um cliente que não consegue manter um endereço também não consegue manter um túnel. Depois corrija o aprovisionamento do lado da VPN, porque uma alteração do lado do cliente a uma atribuição da pool é desfeita na ligação seguinte. Por último, trate das identidades duplicadas: pares de chaves separados no WireGuard, certificados separados ou pelo menos perfis separados no OpenVPN.

No cliente a parte mecânica é curta. Liberte e renove um lease DHCP, ou peça que o endereço seja alterado no servidor para uma reserva. Não escreva um endereço aleatório que pareça livre.

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

Depois verifique a partir dos dois extremos, não de um. Confirme o gateway, depois o serviço de que realmente precisa, e volte a ligar e repita. Se estavam envolvidos dois dispositivos, verifique ambos: mover um endereço deixa o outro com entradas de vizinhos desatualizadas ou um lease antigo que reaparece mais tarde.

O que não fazer pelo caminho

Não silencie o sintoma. A deteção de endereços duplicados é o que o impede de tomar um endereço já em uso, e desativá-la converte um conflito visível em perda intermitente de pacotes muito mais difícil de rastrear. O mesmo se aplica a aceitar um aviso de certificado de um host inesperado: isso não é de todo um problema de endereço, e clicar através dele esconde outra falha.

Também não altere sozinho o endereçamento de uma rede gerida. Registe a definição original, pergunte ao dono quando o endereço é atribuído centralmente, e mantenha a alteração pequena o suficiente para ser revertida. As regras de deteção de conflitos de endereços do RFC 5227 explicam o que uma sonda correta prova, o que vale a pena saber antes de considerar um conflito real.