Clientes VPN chegam ao servidor mas não à LAN: qual correção?

O cliente faz ping ao endereço do túnel do servidor OpenVPN e obtém resposta, depois tenta um host na LAN do servidor e não obtém nada. Essa divisão restringe muito a falha: o túnel está de pé, o encaminhamento provavelmente funciona e a resposta sai por uma porta que não leva de volta. Existem três correções, e a certa depende do que você controla e do que aceita perder. Responda às três perguntas abaixo em ordem e a escolha deixa de ser questão de gosto.

Primeiro, confirme qual direção está quebrada

A requisição chega à interface do túnel com um endereço de origem do pool VPN. O servidor a encaminha ao host da LAN, e esse host responde ao gateway que a própria tabela indica, normalmente o roteador da LAN. Se o roteador não tem rota para o pool, a resposta morre ali ou vaga em direção à internet.

Teste as duas máquinas antes de editar qualquer uma. Pergunte ao servidor qual rota a tabela dele tomaria até um cliente; pergunte ao host da LAN como ele chegaria ao mesmo endereço. A primeira consulta costuma apontar para o túnel e a segunda para o roteador da LAN, e essa diferença é a falha em uma linha. Duas consultas custam menos que uma auditoria de firewall e fixam a direção do problema.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Se o host da LAN já aponta para o servidor VPN, seu problema é uma regra de firewall ou um limite de MTU, não um caminho de retorno ausente. Não adicione uma rota para consertar um filtro.

Pergunta um: você pode editar o roteador da LAN remota?

Quando o roteador da LAN é seu, uma rota estática para o pool VPN com o endereço LAN do servidor VPN como próximo salto é a resposta limpa. Ela mantém intactos os endereços de origem dos clientes, o que importa quando os hosts da LAN registram, filtram ou limitam por endereço. Também não exige tradução no servidor, então o túnel continua um caminho puro de roteamento. A obrigação que ela cria é documental, porque pool, rota e configuração do servidor precisam concordar.

Ela falha em silêncio no dia em que alguém muda o pool. Anote o valor uma vez e trate uma edição em qualquer um dos três pontos como edição nos três.

Um NAS ou um switch de camada 3 que hospeda o serviço precisa da mesma rota, a menos que envie tudo por um roteador que a tenha. Verifique o dispositivo que termina a sub-rede, não apenas o que olha para a internet. Redes pequenas costumam ter três aparelhos com opinião sobre roteamento.

Pergunta dois: a LAN pode deixar de ver os endereços dos clientes?

Quando o roteador é de outra pessoa, traduzir no servidor VPN não exige cooperação. O host da LAN vê o endereço LAN do servidor, responde a ele, e o servidor traduz de volta. É por isso que appliances e papéis de acesso remoto baseados em NAT se comportam assim.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

O custo é a atribuição: endereços por cliente somem dos logs da LAN. Qualquer lista de permissões no host da LAN precisa então nomear o servidor em vez do pool.

Escolha a tradução quando a cooperação não estiver disponível, não quando for apenas inconveniente. Ela esconde o cliente de toda investigação futura, inclusive das em que você precisa saber qual notebook abriu uma conexão. Também pode quebrar protocolos que embutem endereços no payload, porque a tradução vive no cabeçalho. Nenhuma das opções é mais avançada; elas respondem a perguntas diferentes sobre propriedade.

Pergunta três: o servidor é ele mesmo cliente de outro túnel?

Imagine a outra topologia: o servidor VPN também disca para um provedor comercial, então tem dois túneis e dois conjuntos de endereços. O tráfego que ele encaminha para os próprios clientes sai pelo provedor, que não roteia respostas de volta aos endereços do pool. É por isso que as respostas desaparecem embora os dois túneis estejam saudáveis.

A correção é mascarar também o túnel de saída, para que o provedor veja apenas o endereço do túnel do servidor. A direção inversa precisa da própria regra, porque o servidor que inicia uma conexão para um dos próprios clientes é outro fluxo. Sem essa regra, o cliente responde a um endereço que não consegue rotear. Coloque a regra estreita antes de qualquer mascaramento amplo para que a tradução específica vença.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Hosts multi-homed acrescentam uma falha relacionada que parece idêntica do lado do cliente. A resposta sai pela interface de métrica menor porque o endereço de origem foi escolhido em outra tabela. Verifique o caminho de volta com uma consulta em vez de supor que o de ida o implique.

Depois verifique as duas direções e os dois tamanhos

Após a mudança, faça ping do cliente para um host da LAN e depois do host da LAN para o cliente. A segunda direção é a que as pessoas pulam, e é a que expõe uma regra de tradução incompleta. Registre os dois resultados com carimbo de tempo para que uma regressão posterior seja comparável.

Depois mova dados reais, porque um ping pequeno que funciona enquanto uma transferência grande trava é sintoma de MTU. Essa falha aparece logo depois de você se parabenizar por ter consertado a rota.

Por fim, teste de novo após reiniciar. Comandos de rota e firewall em tempo de execução não sobrevivem, e uma correção que some no próximo boot será diagnosticada outra vez por alguém com menos contexto. Torne a mudança persistente do jeito que seu sistema já faz, depois reinicie uma vez de propósito.