O VPN conecta mas não alcança os dispositivos da LAN: o que verificar

O tráfego entra no túnel, o gateway responde no próprio endereço e nada atrás dele responde. Esse padrão é comum e não é uma contradição: uma resposta do gateway prova que o túnel terminou, e não prova nada sobre o que acontece com um pacote endereçado além dele. Os dois testes exercitam caminhos de código diferentes na mesma máquina.

A partir de agora, teste algo do outro lado do gateway. O próprio endereço do gateway continuará respondendo, por mais quebrado que esteja o encaminhamento.

O gateway responde da sua própria pilha

Um pacote endereçado ao gateway é entregue ao seu caminho de entrada local, onde o núcleo decide se um socket à escuta o aceita. Um pacote endereçado a um host atrás do gateway é entregue, em vez disso, ao caminho de encaminhamento, onde se aplica outro conjunto de verificações. O encaminhamento pode estar totalmente desativado, ou o núcleo pode ativá-lo e depois uma regra de filtro que nunca menciona o túnel pode rejeitá-lo. Nada disso afeta a resposta do próprio gateway, e é por isso que o sintoma engana com tanta confiabilidade.

As páginas de administração alcançadas pelo túnel também pertencem à primeira categoria. São evidência sobre o túnel, não sobre a rede atrás dele.

Siga o fluxo até a primeira fronteira que o descarta

Comece no cliente e confirme a rota e o endereço de origem que o fluxo usará. Depois observe o gateway para a chegada desse fluxo exato, e de novo o mesmo fluxo saindo em direção à LAN. Se ele nunca chega, o problema está no lado do cliente ou nos prefixos permitidos do túnel. Se chega e nunca sai, o problema está no encaminhamento ou num filtro do caminho de ida, e a captura já disse qual dos dois.

Executar o mesmo teste a partir do gateway esconde a metade interessante, porque um pacote originado no gateway tem outra origem e outro requisito de retorno. Use o fluxo do cliente, com o seu próprio endereço de origem, a cada passo. Uma captura feita na interface errada produz tolices com muita segurança.

As rotas de retorno e os firewalls dos hosts falham separadamente

Depois que o pacote chega ao host, mais três coisas precisam valer. O serviço precisa estar escutando no endereço para o qual o pacote foi enviado, o firewall do host precisa aceitá-lo, e a resposta precisa ter uma rota de volta para o conjunto de clientes. Essa última falha com frequência, porque a rota padrão do host aponta para um roteador que nunca ouviu falar da faixa do túnel. O resultado é uma conexão que se estabelece do ponto de vista do host e morre em silêncio na outra direção.

Teste o caminho de volta de propósito, enviando do cliente e observando o retorno. Uma captura unidirecional resolve em segundos o que uma hora de especulação não resolverá.

Confirme cada salto com o endereço de origem do cliente

Execute as verificações em ordem e guarde cada saída, porque o valor está na comparação e não em qualquer linha isolada. Os comandos abaixo fixam o endereço de origem, mostram a rota escolhida e capturam os dois lados do encaminhamento. Substitua o seu próprio host da LAN e a sua interface de túnel.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

A consulta de rota mostra se o cliente enviaria sequer esse pacote para o túnel, e o ping mostra se algo voltou do host. Comparar as duas capturas separa a chegada da saída, já que um quadro na interface do túnel sem contrapartida na interface da LAN é uma decisão de encaminhamento e não uma falha do serviço. Quando as duas capturas mostram o pedido e só uma mostra a resposta, a rota de volta é o suspeito restante.

Anote qual endereço respondeu e qual destino encaminhado falhou. Essa frase torna o relatório acionável em vez de uma afirmação de que o servidor está inacessível.