O cliente OpenVPN chega ao servidor mas não aos hosts da LAN: lista de verificação

O cliente diz conectado, o endereço do túnel responde a um ping e nada na LAN do escritório responde. Vejo isto depois de quase todas as atualizações do cliente, e o primeiro instinto é abrir a firewall, o que costuma ser o movimento errado: o túnel está bem e a quebra está num dos três saltos que o pacote tem de atravessar. Percorra o caminho na ordem em que o pacote o percorre, primeiro a rota do cliente, depois o encaminhamento no servidor, depois a viagem de volta, e encontrará o responsável pela falha em alguns minutos.

Primeiro passo: observe a decisão de encaminhamento do cliente

Antes de tocar no servidor, prove que o cliente envia o pacote para o túnel. Pergunte ao kernel que interface usaria para um host LAN específico, em vez de ler a tabela toda:

ip route get 192.168.50.10

Se a resposta nomear o seu adaptador físico e a gateway do escritório, nenhuma alteração do lado do servidor pode ajudar. OpenVPN só distribui rotas quando o servidor as empurra, por isso procure push "route 192.168.50.0 255.255.255.0" na configuração do servidor e volte a ligar o cliente depois. A maioria dos clientes aplica as rotas empurradas ao ligar, não quando recarrega o perfil.

No Windows a mesma pergunta tem outro comando. Find-NetRoute -RemoteIPAddress 192.168.50.10 imprime a interface e o próximo salto que a pilha escolheria, e route print -4 mostra se o prefixo empurrado existe sequer.

Segundo passo: confirme que o servidor vai encaminhar o pacote

Se a rota do cliente estiver correta, o pacote chega ao servidor e o servidor tem de aceitar encaminhá-lo. O interruptor do kernel é a primeira porta, e sysctl net.ipv4.ip_forward tem de devolver 1. Defini-lo com echo 1 > /proc/sys/net/ipv4/ip_forward funciona até ao próximo reinício, e é exatamente por isso que a mesma queixa volta semanas depois.

Anote-o num sítio que sobreviva a um reinício:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

A segunda porta é a tabela de filtros. Um host com o Docker instalado costuma ter uma política FORWARD de DROP, e o túnel herda essa decisão. iptables -L FORWARD -v -n mostra tanto a política como os contadores de pacotes; se a política for DROP, o encaminhamento precisa de uma autorização explícita para o sentido do túnel para a LAN e outra para a resposta.

Terceiro passo: siga o pacote até à LAN e procure a resposta

Observe os dois lados do servidor ao mesmo tempo. Capture no túnel e na interface LAN, filtrado a um cliente e a um host para que a saída continue legível:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Os pedidos que aparecem em tun0 e de novo em eth0 com origem 10.8.0.x, seguidos de silêncio, significam que o pacote chegou e a resposta foi a outro sítio. O host da LAN responde à sua gateway predefinida, essa gateway não tem rota para o conjunto VPN, e a resposta morre no router da LAN. Fazer ping ao host da LAN a partir do servidor não prova nada sobre este caminho, porque esse tráfego nunca atravessa o túnel.

Quarto passo: escolha entre tradução e uma rota de volta

Duas reparações fecham o buraco, e a escolha tem consequências para além de o ping funcionar. A tradução de origem torna o servidor o remetente aparente:

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

Limite a regra ao conjunto e à interface LAN, e torne-a permanente, senão o próximo recarregamento da firewall remove a sua correção em silêncio. O custo é a identidade: cada cliente parece o servidor VPN nos registos da LAN e nas regras de acesso, e per-client policy becomes guesswork.

Uma rota estática para 10.8.0.0/24 no router da LAN, a apontar para o servidor VPN, mantém os endereços dos clientes visíveis e é a melhor resposta a longo prazo quando esse router é seu. Muitos locais correm as duas durante algum tempo, NAT para a reparação imediata e a rota assim que a política da firewall estiver escrita. Se o servidor for um par site-to-site em vez de um conjunto, o lado do servidor também precisa de um iroute para a sub-rede remota, caso contrário a rota do par existe mas o tráfego dos clientes nunca é associado a ela.

Quinto passo: verifique a partir do cliente e registe o que mudou

Feche o ciclo a partir do cliente, não do servidor. Ligue-se a um serviço real no host da LAN e depois confirme que os contadores de tradução se moveram com iptables -t nat -L POSTROUTING -v -n, porque uma regra sem pacotes é uma regra que nunca correspondeu. conntrack -L -s 10.8.0.5 mostra o fluxo e o seu estado quando precisa de prova de que o sentido de volta está a ser seguido.

Deixe uma nota na configuração do servidor: que sub-rede, que interface, que regra, e se o router da LAN tem uma rota de volta. Da próxima vez que uma atualização do cliente apagar uma rota empurrada, essa nota transforma uma sessão de apagar fogos numa correção de uma linha.