Um cliente VPN com endereço LAN não está na LAN

O cliente conecta, recebe 10.50.0.200 e não consegue alcançar o servidor em 10.50.0.20 embora os dois números estejam na mesma /24. A crença por trás dessa configuração é que um endereço do prefixo da LAN torna o cliente parte da LAN. Não torna. O cliente está num link ponto a ponto, o servidor considera o destino local, e a peça que falta é uma resposta de vizinho que ninguém envia.

O mito: mesmo prefixo significa mesmo segmento

Um prefixo de endereço diz a um host quais destinos ele alcança diretamente e quais exigem um roteador. Ele não diz ao host como o destino está fisicamente conectado, e certamente não garante que o destino possa responder a uma requisição na camada de enlace. São perguntas diferentes, respondidas por tabelas diferentes no host. A máscara responde à primeira e a tabela de vizinhos à segunda, e somente a primeira está sob seu controle do lado da VPN.

Quando o servidor envia para 10.50.0.200, ele compara o destino com sua própria máscara, decide que o endereço está on-link e pergunta ao segmento local o endereço de hardware que o possui. Essa requisição sai pela interface Ethernet, e o cliente VPN não está lá para ouvi-la.

Nada na configuração do cliente pode corrigir isso do lado dele. O caminho de resposta depende de um dispositivo na LAN responder em nome do cliente, ou de o cliente ter um endereço que o servidor não considera local.

O que o host local realmente faz com o endereço

O comportamento é fácil de observar e vale a pena observar antes de mudar qualquer coisa. Olhe a tabela de vizinhos num host da LAN depois que ele tenta alcançar o cliente: uma entrada incompleta ou falha é todo o diagnóstico numa linha. Essa linha também diz que a falha é local ao segmento e não em algum ponto dentro do túnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

A consulta de rota reportará o destino como on-link pela interface Ethernet, e esse é exatamente o problema. Se a entrada de vizinho permanecer incompleta enquanto a sessão VPN está ativa, você confirmou que a peça que falta é a resolução na camada de enlace, e não o roteamento ou a política de firewall.

Faça a mesma verificação a partir de um host em outra sub-rede e compare. Um host que alcança o cliente através de um roteador não precisa de entrada de vizinho alguma, e essa diferença é a decisão de projeto em miniatura.

Como o proxy ARP fornece o próximo salto

O proxy ARP faz o gateway responder à requisição da camada de enlace em nome de um destino que ele pode alcançar por outra interface. O host da LAN recebe um endereço de hardware, envia o quadro ao gateway, e o gateway encaminha o pacote para a sessão VPN. Do ponto de vista do host, o cliente simplesmente parece estar atrás do gateway. Nada na configuração do cliente muda.

A documentação de ARP do RouterOS da MikroTik descreve esse uso para clientes dial-in que tomam emprestado o espaço de endereços da LAN conectada. O mecanismo é um reparo da resolução de vizinhos, e funciona porque o gateway está realmente nos dois caminhos.

Isso não é o mesmo que colocar o cliente em ponte dentro da LAN. O gateway ainda precisa encaminhar o pacote para a sessão ativa correta, e seu roteamento e sua política de firewall ainda precisam permitir o serviço. O proxy ARP muda quem responde à requisição de vizinho, não quem tem permissão para falar.

Leia com atenção os nomes de modo da plataforma. O RouterOS separa proxy-arp de local-proxy-arp, e o segundo trata do tráfego que entra e sai pela mesma interface. Não são grafias intercambiáveis, e ativar os dois sem critério não é um atalho.

O que o proxy ARP não lhe dá

Ele não fornece descoberta por broadcast nem multicast. Um cliente que precisa encontrar um serviço por broadcast ainda falhará, porque o gateway encaminha unicast para a sessão e não torna o cliente membro do domínio de broadcast da LAN. Protocolos de descoberta que dependem de broadcast são uma fonte comum de relatos de que funciona para uma coisa e não para outra em projetos com endereços emprestados.

Ele não reserva o endereço. Se o número emprestado também estiver num pool DHCP ou numa atribuição estática, dois dispositivos podem acabar com o mesmo endereço e o comportamento resultante depende do momento. Um login bem-sucedido não é uma reserva.

E não elimina a necessidade de coordenação com o dono da LAN. Uma entrada de proxy ARP que surpreende o dono do plano de endereços é um incidente de suporte esperando uma semana tranquila.

Comparação com um pool roteado em separado

A alternativa é dar aos clientes VPN seu próprio prefixo e deixar os hosts da LAN rotear para ele. Então o servidor envia respostas fora do link ao seu gateway, o gateway roteia o prefixo para o endpoint da VPN, e no segmento da LAN não é necessária resolução de vizinhos alguma. Isso são menos peças móveis do que um endereço emprestado mais uma resposta proxy.

Esse projeto é mais fácil de raciocinar e de auditar, porque a faixa de clientes está visivelmente separada da faixa da LAN. Custa uma rota, um caminho de volta e uma regra de acesso, as mesmas coisas que o projeto com proxy ARP precisa num lugar menos óbvio.

Escolha entre os modelos deliberadamente e não por acidente. O proxy ARP repara uma relação concreta; um pool roteado evita precisar desse reparo. Anote qual você escolheu e por quê, e a próxima pessoa não terá que redescobrir isso a partir de uma entrada de vizinho falha.