O cliente VPN encaminhado alcança o servidor mas não os hosts da LAN

O túnel sobe, o cliente faz ping ao servidor VPN, e uma partilha numa máquina a um salto de distância nunca responde. Nada na configuração do cliente o explica, porque o pedido saiu mesmo do cliente e chegou mesmo. O que falhou foi a viagem de regresso, e o dispositivo que falhou é normalmente o gateway da LAN e não o host VPN. Rastrear o pacote de resposta explica toda esta classe de sintomas.

Siga a resposta, não o pedido

O servidor VPN desencripta o pacote do cliente e reencaminha-o para a LAN com o endereço do cliente ainda no campo de origem. O host de destino responde a esse endereço, e agora a sua própria tabela de rotas decide tudo. O gateway predefinido nada sabe do conjunto do túnel, por isso a resposta sai em direção ao fornecedor de internet e é descartada em algum ponto desse caminho.

No cliente o sintoma é um tempo limite silencioso: sem recusa, sem reposição, apenas nada. A navegação numa partilha bloqueia, o ping indica que não há resposta, e os registos do servidor parecem saudáveis porque o servidor fez o seu trabalho.

Coloque a rota de retorno onde os hosts olham

Cada host da LAN consulta o seu gateway predefinido, por isso o gateway é o único dispositivo que precisa de saber onde vive o conjunto do túnel. Adicione lá uma rota estática e cada host herda o caminho correto sem ser tocado.

Se o gateway distribui o seu próprio endereço como opção DHCP, distribua a rota dessa forma para que as máquinas novas a tomem automaticamente. Caso contrário, a rota vive num ficheiro de configuração e desaparece na reconstrução seguinte.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Porque o NAT de origem parece repará-lo

Mascarar o conjunto de clientes atrás do endereço do servidor VPN elimina o problema ao eliminar o endereço do cliente do pacote. As respostas voltam então ao servidor, que já sabe como alcançar o túnel, e tudo funciona. O custo é que os hosts internos deixam de ver quem é o cliente, e cada ligação parece vir de uma única máquina.

Essa troca às vezes é correta, por exemplo quando a um equipamento de um fornecedor não se pode dar uma rota estática. Não torne a regra mais ampla do que o conjunto atual, porque uma regra escrita para um /24 deixa de coincidir no dia em que o conjunto é renumerado para um /16, e o primeiro sinal é um lote de clientes novos que se ligam e não alcançam nada.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

O caminho na nuvem precisa de três ajustes

Numa VPC a mesma lacuna regressa noutra forma, porque a sub-rede não tem qualquer rota para o intervalo de clientes. A tabela de rotas precisa de uma entrada para o conjunto do túnel que aponte para a interface de rede da instância, e a interface precisa de ter a verificação de origem e destino desativada para que a plataforma aceite pacotes cuja origem não é o seu próprio endereço. Os grupos de segurança e as ACL de rede também devem admitir o conjunto nos dois sentidos.

Cada omissão produz uma falha parcial distinta. Omita a entrada da tabela de rotas e as instâncias privadas respondem para uma sub-rede que não consegue levar a resposta de volta ao conjunto. Com a verificação ainda ativa, a plataforma descarta a resposta depois de a instância já a ter enviado. Sem a regra do grupo de segurança, o próprio pedido nunca chega, e o cliente vê o tempo limite uma camada antes.

Execute as verificações por esta ordem

Confirme o encaminhamento e a política de filtragem antes de culpar o encaminhamento de rede, porque um host que não encaminhe falha da mesma forma silenciosa. Depois leia a definição efetiva de caminho inverso na interface que transporta o túnel, uma vez que um filtro rigoroso pode descartar respostas que chegam de uma direção inesperada.

Termine com uma captura feita no host da LAN enquanto o cliente lhe faz ping. Um pedido que chega sem resposta correspondente prova o caminho de regresso, e um pedido que nunca chega devolve a culpa ao servidor ou ao túnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

A verificação de origem e destino está documentada no guia da interface de rede elástica. Defina-a na interface que transporta realmente o tráfego do túnel, não num adaptador não relacionado ligado à mesma instância.