Endereço VPN versus concessão DHCP na LAN: quem atribui o IP do túnel?

Ligue o cliente e olhe para o adaptador em vez do ícone de Wi-Fi. Um endereço como 10.80.0.14 pode estar num túnel embora nenhum servidor DHCP da LAN do escritório tenha alguma vez registado essa concessão. O processo que escolheu o número decide onde começa o diagnóstico.

No cliente tudo parece igual: um endereço IPv4, uma máscara, às vezes um gateway predefinido. A diferença só aparece quando pergunta quem responde por esse endereço e quem guarda um registo dele.

Leia o endereço do túnel do lado do cliente

O Windows mostra a distinção se ler o bloco inteiro e não a primeira linha. ipconfig /all imprime uma descrição do adaptador, um endereço físico e uma linha DHCP. Um adaptador de marcação PPP ou IKEv2 normalmente reporta DHCP como desativado, porque a ligação negociou o endereço durante a marcação em vez de o obter de um servidor da LAN. Um adaptador de túnel com DHCP ativo é invulgar e merece uma investigação própria.

O Linux reparte a mesma informação por duas ferramentas. ip -4 addr show dev tun0 dá o endereço e o comprimento do prefixo. nmcli -f IP4 connection show work revela se o valor veio do perfil de ligação, de uma troca DHCP na ligação ou de uma configuração empurrada. O WireGuard é o caso mais claro, porque wg-quick aplica a linha Address do ficheiro de configuração quando a interface aparece e nenhum par atribui nada ao ligar.

O prefixo também diz algo. Um /32, ou uma máscara de 255.255.255.255, significa que o gateway espera encaminhar para um único endereço de anfitrião, enquanto uma máscara mais ampla sugere uma sub-rede na ligação em algum lugar atrás do túnel.

O que transporta a carga de configuração do IKEv2

O IKEv2 tem um mecanismo dedicado a esta tarefa. A carga de configuração descrita na RFC 7296, secção 3.15.1 transporta atributos como INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS e os seus equivalentes IPv6. O cliente envia um atributo de comprimento zero quando não tem preferência, e o respondedor devolve o valor que pretende ver usado. Essa troca viaja dentro do IKE_AUTH, já cifrada, pelo que nenhuma difusão DHCP atravessa o túnel.

Daí decorrem duas consequências. Primeira, o endereço é escolhido pelo respondedor ou por qualquer backend de autorização que ele consulte, e é por isso que um conjunto pode residir no gateway, numa resposta RADIUS ou num mapeamento do fornecedor de identidade. Segunda, o atributo DNS é separado do atributo de endereço. Receber 10.80.0.14 não diz nada sobre que resolvedor voltou, nem se voltou algum.

O atributo de máscara de rede é opcional na prática. Muitas implementações devolvem apenas um endereço e deixam o cliente instalar uma rota de anfitrião, e é por isso que o mesmo conjunto pode parecer um /32 num cliente e um /24 noutro.

Onde colidem um âmbito DHCP da LAN e um conjunto VPN

O problema começa quando ambos os atribuidores apontam para o mesmo intervalo. Um servidor DHCP para 10.20.30.0/24 nada sabe de um conjunto VPN configurado para 10.20.30.128/25, pelo que nada o impede de conceder 10.20.30.140 a uma impressora enquanto o gateway entrega o mesmo endereço a um cliente remoto. A colisão fica silenciosa durante dias e depois surge como um duplicado intermitente.

Um desenho encaminhado de site para site evita a colisão por construção. Um anfitrião na sucursal mantém o endereço que o seu servidor DHCP local lhe deu. As interfaces de túnel dos dois gateways transportam os seus próprios endereços de ligação, e a tabela de encaminhamento decide como viajam os pacotes. Os endereços dos clientes de acesso remoto são uma terceira categoria e não devem ser misturados com os endereços de ligação do gateway.

Fazer ponte do túnel para a LAN elimina essa separação. Se o desenho precisar realmente de um único domínio de difusão, o ponto final da VPN tem de participar nas mesmas decisões de atribuição que o servidor DHCP, através de um relé ou de uma fonte autoritativa partilhada, em vez de emitir endereços por conta própria.

Verifique que processo é dono do endereço

Prove a propriedade antes de alterar um âmbito. No cliente, anote o endereço e o prefixo. Na LAN, procure na base de dados de concessões. No gateway, liste os conjuntos que está configurado para distribuir. Um endereço encontrado no ficheiro de concessões pertence a um servidor DHCP, o que significa que o túnel está em ponte ou relayado; um endereço encontrado apenas no conjunto do gateway pertence ao ponto final do túnel.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Anote quatro coisas quando a resposta estiver clara: que componente atribui o endereço do cliente, que intervalo está reservado para ele, como o tráfego de retorno chega a esse intervalo e que recursos o aceitam. Essas quatro entradas transformam uma linha de adaptador virtual num facto operacional.

Repita a verificação do atributo DNS enquanto está aí. Um conjunto que distribui endereços sem resolvedor deixa o cliente no seu DNS local, o que é uma falha diferente de um conjunto que distribui um endereço que a LAN já usa.