Por que a sua LAN não alcança um serviço num cliente VPN

O seu túnel está ativo, o serviço está à escuta, e a LAN do escritório continua a não receber nada de volta. Ninguém quebrou a VPN. Do lado da LAN, o endereço de túnel do portátil não existe até algo dizer à LAN como chegar até ele, e a resposta tem de voltar pelo mesmo caminho por onde saiu o pedido. Já vi pessoas reconstruírem três vezes um túnel perfeitamente saudável antes de alguém olhar para o caminho de volta.

Não foi o túnel que quebrou

Os dois extremos ficam em faixas privadas, que é o caso normal e não uma configuração errada. Um endereço como 10.8.0.6 é real dentro do túnel e não existe em mais lado nenhum, por isso a LAN não tem motivo para lhe enviar nada. Antes de tocar no encaminhamento, confirme que o serviço é alcançável dentro do túnel: no cliente, ss -ltn mostra se o ouvinte se liga a 127.0.0.1, à interface da LAN ou ao endereço do túnel. Um daemon ligado apenas a loopback não responde a ninguém exceto a si próprio, e nenhuma rota, DNAT ou reencaminhamento de porta muda isso.

Um proxy no porto 80 ou 443 é outra ferramenta com outra visibilidade. Move pedidos, não pacotes, por isso é a camada errada para uma ligação direta a uma base de dados, e recorrer a ele é como este problema acaba três ferramentas mais fundo antes de alguém medir o que quer que seja.

Forma de rota: diga à LAN onde está o conjunto

Uma rota estática na gateway da LAN é a resposta mais limpa quando a LAN e o conjunto do túnel não se sobrepõem. Aponte o conjunto para a máquina que termina o túnel:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Isso corrige apenas uma direção, e é por isso que versões a meio deste cambio parecem progresso. O lado do túnel precisa da metade correspondente, senão a resposta sai do cliente pela sua própria rota padrão e morre pelo caminho:

push "route 192.168.1.0 255.255.255.0"

Para uma sub-rede que fica atrás de um cliente e não atrás do servidor, o servidor precisa tanto de uma rota de sistema como de uma entrada iroute no ficheiro desse cliente em client-config-dir. Sem iroute, o OpenVPN sabe que o prefixo existe e não tem ideia de que cliente o possui: os pacotes chegam e o daemon não tem com quê emparelhá-los.

Aqui está o mito que merece um nome. Uma rota torna um endereço alcançável; não torna o outro lado disposto a responder. Os pares site a site acrescentam mais uma camada, porque a gateway remota só aceita origens dentro dos prefixos da sua política, e um portátil que chega de um conjunto doméstico não está dentro deles.

Forma NAT: DNAT para dentro, e a linha SNAT que todos saltam

Quando não pode tocar na gateway da LAN, ou quer publicar exatamente uma porta, a tradução no anfitrião VPN funciona sem qualquer rota na LAN. Publique a porta, reencaminhe-a e traduza a origem a caminho do túnel:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

A terceira linha é a que desaparece. Salte-a e o cliente vê o endereço original da LAN como origem, responde pela sua própria rota padrão, e essa resposta vai para o túnel em vez de voltar para a LAN. Se a ligação sobrevive depende então de encaminhamento que nunca planeou. Com SNAT o cliente vê o endereço de túnel do servidor, por isso a resposta segue o túnel de volta ao único anfitrião que pode desfazer a tradução.

O firmware de consumo usa os seus próprios nomes de cadeia e não gera essa tradução por si. No Tomato, uma regra de entrada cai em WANPREROUTING e depois numa cadeia de filtragem como wanin, e um conjunto de regras que parece completo ainda precisa de uma linha POSTROUTING manual. Isso não é um erro do firmware; é um conjunto de regras escrito só para tráfego de entrada.

Por que uma regra que parece correta ainda descarta o pacote

A maioria destas falhas não está na regra que está a fitar. Verifique quatro coisas nesta ordem e pare na primeira que não se cumpre:

• Ordem das cadeias. iptables -I insere no topo e -A acrescenta no fim, por isso uma regra permissiva ou bloqueante anterior decide primeiro.
• Cadeia errada. O tráfego dirigido ao próprio router passa por INPUT, e o tráfego reencaminhado nunca lhe toca. Publicar um só serviço pode exigir regras em ambas.
• Bandeiras de direção. -i tun0 corresponde ao tráfego que vem dos clientes e -o tun0 ao que sai na direção deles. Um REJECT com a bandeira errada bloqueia algo que não pretendia.
• Restrição de origem. Um reencaminhamento que aceita um endereço de cliente funciona a partir desse cliente e descarta qualquer outra origem sem uma palavra.

Uma regra com um contador de pacotes a zero não está no caminho de todo, e ler os contadores é a forma mais rápida de separar um problema de cadeia errada de um problema de regra errada.

O reencaminhamento local, quando nada na LAN pode mudar

Um reencaminhamento SSH local contorna toda a questão. Não precisa de rota na LAN, nem de cooperação da firewall do cliente, nem de qualquer porta publicada em lado nenhum:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

O serviço aparece então em localhost:3000 da máquina que mantém o túnel, e em mais lado nenhum. Esse é o limite: uma estação de trabalho, uma porta, e o reencaminhamento morre com a sessão a menos que algo o reinicie. Para um administrador que verifica uma base de dados de testes é a ferramenta certa. Para uma câmara ou um scanner que outras pessoas têm de alcançar, não é, porque cada utilizador precisaria do seu próprio reencaminhamento.

Verifique ambas as direções antes de acrescentar outra regra

A tradução deixa rastos, e lê-los é melhor do que adivinhar. No anfitrião VPN, conntrack -L mostra se a tradução ocorreu, iptables -t nat -L -n -v mostra se os contadores se moveram, e tcpdump -ni any port 3000 mostra que endereço de origem chegou de facto. No cliente, ss -ltn confirma que o ouvinte está num endereço que o túnel consegue alcançar.

Depois escolha a forma que vai manter. Uma porta publicada, uma rota para todo o conjunto e um reencaminhamento para um único administrador são três compromissos diferentes, e misturá-los é como uma configuração que funciona se torna uma que ninguém saberá explicar seis meses depois. Escreva que endereço é alcançável a partir de onde, e a próxima pessoa que depurar isto começa pela resposta em vez do túnel.