O seu pool VPN não é o intervalo DHCP da LAN: por que quebra

O atalho tentador é entregar aos clientes VPN endereços do mesmo intervalo que o servidor DHCP do escritório usa, com a teoria de que afinal tudo é uma só rede. Não é. Um túnel encaminhado transporta pacotes unicast entre dois extremos, enquanto o pool da LAN existe para responder a pedidos de difusão num segmento físico. Reutilizar os números coloca dois atribuidores responsáveis por um só espaço de endereços e deixa o caminho de retorno indefinido.

Dois atribuidores, um espaço de endereços

O servidor DHCP da LAN sabe que endereços arrendou e a que endereço MAC, e defende-os com ARP. O servidor VPN tem o seu próprio pool e não sabe nada desses arrendamentos. Nenhum dos dois está errado; simplesmente nunca foram apresentados um ao outro.

Um endereço do pool da LAN que o servidor VPN entrega pode já pertencer a uma impressora. Agora dois dispositivos reclamam um endereço no mesmo prefixo, e a tabela de encaminhamento do comutador decide qual responde.

É a falha com que as pessoas se deparam primeiro: um cliente que se liga com sucesso e depois chega à máquina errada, ou chega à certa de forma intermitente.

Por que o router não distribui endereços VPN

A descoberta DHCP é uma difusão, e as difusões param numa fronteira encaminhada. A menos que o desenho faça ponte no túnel ou execute um relé DHCP com a autoridade correspondente, o pedido do cliente nunca chega ao servidor da LAN.

Por isso o servidor VPN atribui o endereço ele mesmo: um pool na configuração do servidor, um endereço por par numa instalação WireGuard, ou um endereço empurrado pela camada de autenticação numa implementação IKEv2. Esses mecanismos são independentes da base de dados de arrendamentos da LAN, e é exatamente por isso que precisam de um intervalo próprio.

O mesmo raciocínio explica por que mudar o âmbito DHCP não corrige um cliente VPN que nunca obtém endereço. O cliente não pergunta ao servidor da LAN, e nenhuma edição do âmbito o fará perguntar.

A sobreposição manifesta-se como conflito, não como rede lenta

Duas redes que partilham um prefixo sem um desenho suportado são um problema diferente da propriedade duplicada, e são frequentemente confundidas. Se o pool VPN for um prefixo separado, a sobreposição só importa quando uma rota envia o tráfego para o lado errado. Se o pool estiver dentro do prefixo da LAN, o conflito é imediato e local.

Na prática vê respostas ARP do dispositivo errado, ligações que reiniciam a meio caminho, e um cliente cujo próprio endereço é reclamado por outra pessoa. Nada disso parece um problema de encaminhamento, por isso a correção é aplicada na camada errada. Um arrendamento duplicado é fácil de confirmar e incómodo de suportar. Também sobrevive a reinícios, porque ambos os atribuidores continuam a insistir no mesmo endereço.

O caminho de retorno é um problema à parte

Mesmo com um pool limpo e distinto, os anfitriões da LAN precisam de saber como responder a um cliente. A sua gateway predefinida é o router, e o router precisa de uma rota para o pool que aponte para o servidor VPN, a menos que o desenho traduza o tráfego do cliente.

Leia o caminho nos dois sentidos antes de mudar o que quer que seja. Na gateway, pergunte que interface o núcleo usaria para um endereço de cliente; no cliente, pergunte que rota usa para um endereço da LAN.

Estes comandos mostram a decisão de encaminhamento na gateway e as entradas de vizinhos que revelam um duplicado:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Se o primeiro comando responder com a interface do túnel, a rota de retorno existe. Se responder com a interface da LAN, o router acredita que o cliente está no cabo e tentará fazer ARP por ele.

Existem desenhos com ponte, mas têm de ser escolhidos

Fazer ponte de um túnel para a LAN é um desenho real, usado quando os clientes têm de receber difusões ou ser descobertos por protocolos que pressupõem um só segmento. Exige que o servidor possua esse comportamento de ponte e o tratamento de endereços que o acompanha.

O que não funciona é imitar o resultado copiando números. Um pool partilhado sem ponte dá-lhe o conflito sem a descoberta, que é o pior das duas disposições.

Escolha a camada três com um pool distinto, a menos que a aplicação precise realmente do segmento, e documente o pool para que o próximo administrador não reutilize o intervalo DHCP por pura arrumação.