Acesso à LAN via OpenVPN quebrado? Verifique zonas, rotas e caminho de volta

O túnel relata uma conexão bem-sucedida, a página do próprio roteador carrega, e o mapeamento de unidade para uma máquina atrás dele ainda expira. Nada nessa combinação é contraditório: o roteador responde como ele mesmo, e alcançar algo atrás dele é outra decisão tomada em outro lugar. Faça as verificações abaixo em ordem e pare na primeira falha, porque cada uma se apoia na anterior. Quando as quatro passam, o defeito está acima do túnel e não dentro dele.

Qual filtro vê um pacote destinado à LAN

Um pacote endereçado ao roteador é consumido localmente; um pacote endereçado a um host atrás dele precisa ser encaminhado, e os firewalls julgam esses dois casos separadamente. Portanto, a permissão para chegar ao roteador não diz nada sobre a permissão para atravessá-lo. O firmware que esconde seus conjuntos de regras ainda implementa os dois, normalmente como um seletor que oferece a LAN, a internet ou ambas. Se o seletor deixa a LAN de fora, nenhuma verificação posterior importará.

O OpenWrt torna essa divisão inspecionável, e a distinção vale uma leitura. A zona que termina o túnel precisa de uma regra de encaminhamento para a zona LAN, enquanto uma regra de entrada governa apenas serviços no próprio roteador. Uma página de administração funcionando ao lado de uma LAN morta é o resultado comum dessa regra de encaminhamento ausente.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Olhe o destino de encaminhamento da zona que carrega o túnel: accept é o que a escada precisa, e reject explica cada tempo esgotado abaixo. Duas configurações vizinhas produzem o mesmo sintoma, então descarte-as enquanto está aqui. O isolamento sem fio esconde hosts cabeados dos clientes sem fio, e um roteador que trata hosts LAN inativos como offline pode descartar as respostas mesmo depois que o encaminhamento funciona.

Por que um túnel dividido precisa do prefixo empurrado

Um cliente que envia todo o tráfego pelo túnel já possui o prefixo LAN pela sua rota padrão, então não há nada a acrescentar. O túnel dividido é o caso que exige o prefixo declarado explicitamente, porque nada mais na configuração o menciona. Adicione a diretiva à configuração do servidor e recarregue o serviço.

push "route 192.168.50.0 255.255.255.0"

Os perfis que contêm route-nopull ignoram as rotas empurradas, então o mesmo prefixo pertence ao arquivo do cliente. De qualquer forma, confirme que a entrada chegou em vez de supor, porque uma substituição silenciosa parece idêntica a um problema de firewall.

ip route show | grep 192.168.50

Um par site a site pede mais do que um empurrão. O servidor precisa aprender quais prefixos estão atrás desse par, o que uma linha iroute em seu arquivo client-config-dir faz, e sua própria tabela precisa de uma rota correspondente para dentro do túnel.

A resposta precisa de um endereço que consiga alcançar

Encaminhar a requisição é só metade de uma troca, porque o host da LAN precisa responder a um endereço do conjunto do túnel. Roteadores pequenos costumam resolver isso traduzindo a origem na zona do túnel, de modo que a resposta é endereçada ao roteador e não exige configuração em outro lugar. Remova essa tradução e o host passa a precisar da própria rota para o conjunto, que obtém de graça quando o roteador é seu gateway padrão. Um host com endereço fixado à mão e outro gateway responde por esse gateway, e o cliente vê uma sessão abrir e depois travar.

tcpdump -ni tun0 host 192.168.50.20

Execute isso no roteador enquanto o cliente repete a requisição, e leia o destino da resposta em vez da requisição. Uma resposta endereçada ao conjunto significa que o caminho de volta funciona e que o defeito está mais adentro. Nenhuma resposta significa que o host nunca aceitou o pacote, o que devolve você ao conjunto de regras.

Uma escada que termina no lugar certo

Quatro verificações localizam a camada, e cada uma é um único comando em vez de um julgamento. Execute-as em ordem e pare na primeira falha. A ordem importa mais que os comandos, porque um passo posterior que passa esconde a razão de um anterior ter falhado.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Nomes ficam no fim da escada, nunca no começo. Um compartilhamento que responde como 192.168.50.20 mas não como nas.local aponta para resolução de nomes ou para um sufixo de busca, e edições no firewall não mudam nenhum dos dois.

Anote o primeiro passo que falhou e depois dê às portas de serviço a própria rodada, porque um ouvinte e uma permissão de host são requisitos separados. Compartilhamento de arquivos, desktop remoto e fluxos de câmera precisam dos dois, e um firewall do host que confia na sub-rede LAN mas não no conjunto do túnel descarta o cliente enquanto o ping ainda funciona. Quando todas as verificações passam e a aplicação continua falhando, o defeito está acima do túnel: um serviço ligado a uma interface ou um proxy configurado no cliente.