Router LAN e cliente VPN: dois dispositivos, duas tabelas de rotas

Dois dispositivos encaminham o pacote e cada um mantém a sua própria tabela. O router LAN sabe que o prefixo remoto pertence ao cliente VPN, e o cliente VPN sabe como chegar a esse prefixo através do seu túnel. Configure apenas a primeira tabela e o pacote chega a uma máquina que não tem qualquer rota correspondente, pelo que volta a sair pela rota predefinida. É toda a falha, e do lado da LAN parece um ciclo de encaminhamento, porque quase o é.

Desenhe os dois saltos antes de tocar numa rota

Tome um esquema ilustrativo: hosts da LAN em 192.168.50.0/24, o router comum em 192.168.50.1, um cliente dedicado em 192.168.50.15 e uma LAN remota em 10.60.0.0/24 acessível apenas pelo túnel que esse cliente mantém. Nenhum dos dois intervalos privados se sobrepõe ao outro, e o túnel tem o seu próprio plano de endereçamento.

Ambos os intervalos privados importam porque decidem qual dispositivo pode responder. O lado remoto verá o pacote chegar do endereço de túnel do cliente, e a resposta tem de encontrar um caminho de volta para 192.168.50.0/24. Se apenas o sentido de saída estiver configurado, o pedido pode funcionar enquanto a resposta desaparece.

Passo 1: aponte o router para o cliente, não para o túnel

No router LAN, adicione uma rota de destino cujo próximo salto seja o endereço LAN do cliente:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Esse registo diz «entrega-o à máquina que consegue fazer túnel». Não diz nada sobre como o túnel é construído, e não substitui a rota própria do cliente. Num router gerido, o equivalente vive na página de rotas estáticas do dispositivo; num router Linux pertence à configuração da interface que possui a LAN, não a uma shell que vai fechar.

Verifique a resposta do segundo comando. Se indicar o cliente como gateway e a interface LAN como device, o primeiro salto está correto e o trabalho restante está na outra máquina.

Passo 2: dê ao cliente uma rota própria do lado do túnel

O cliente recebe agora um pacote para 10.60.0.0/24 e consulta a sua própria tabela. Se a sua configuração de túnel instalou uma rota para esse prefixo, o pacote continua cifrado. Se não, o pacote corresponde à predefinida comum e volta para 192.168.50.1, que o envia novamente ao cliente.

Veja antes de acrescentar seja o que for:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Uma rota de prefixo em falta em todas as tabelas é o achado que procura. Acrescente-a através da configuração própria do túnel, para que a próxima reconexão a reinstale; uma ip route add manual desaparece com a sessão e faz a falha voltar no momento menos conveniente. O próximo salto é a interface de túnel ou o endereço que a VPN atribui como seu par, conforme o cliente, e o endereço do par deve vir do perfil atual e não de uma nota antiga.

O ciclo, quando ocorre, não é infinito na prática: o TTL desce em cada passagem e o pacote morre com uma mensagem de tempo excedido. Por isso um traceroute repetido pode sugerir um ciclo, enquanto um cliente que simplesmente não encaminha deixa cair o mesmo pacote em silêncio.

Passo 3: permita o encaminhamento e escolha o caminho de retorno

Receber e encaminhar são permissões diferentes. net.ipv4.ip_forward=1 no cliente permite o trânsito ao nível do kernel, e uma regra de firewall ainda tem de o permitir entre a interface LAN e o túnel. Uma regra que permite o acesso à página de gestão do próprio cliente não permitirá o trânsito para a LAN remota, e a distinção é fácil de perder quando o mesmo host responde a pings localmente.

O lado remoto tem o problema espelho. Tem de saber que 192.168.50.0/24 é acessível através deste cliente autenticado. Com OpenVPN isso significa normalmente uma rota por cliente empurrada pela configuração do servidor, ou um ficheiro específico do cliente no servidor que declara a LAN por trás do cliente. Sem isso, a LAN remota ou descarta a resposta ou envia-a para o seu próprio gateway predefinido, ou seja, para a internet.

A tradução de origem é a alternativa quando o prefixo da LAN não pode ser anunciado. Uma regra de masquerade com âmbito no cliente reescreve a origem para o endereço do túnel, e as respostas voltam então naturalmente. Também esconde qual host da LAN fez o pedido, e por si só não permite ao lado remoto iniciar ligações para dentro. Escolha esse compromisso deliberadamente em vez de acrescentar um masquerade global e descobrir o efeito secundário mais tarde.

Passo 4: torne ambas as decisões persistentes e depois teste o caminho real

Cada rota tem um dono, e o dono é a configuração que se regenera no arranque ou na reconexão. No router pode ser uma entrada de rota estática; no cliente pode ser o perfil VPN, o NetworkManager ou o systemd-networkd. Verifique reconectando o túnel e reiniciando o cliente, e depois leia a tabela de novo em vez de confiar na edição.

Mantenha intacta a rota predefinida que transporta a ligação exterior do túnel. Substituí-la para «simplificar» a configuração quebra o caminho cifrado antes de qualquer tráfego interior o poder usar, e o sintoma é um túnel que nunca se restabelece depois da alteração.

Teste a partir de um host LAN comum, não do cliente, porque um pedido originado no cliente nunca exercita o primeiro salto do router. Obtenha um serviço que só existe na LAN remota e confirme o corpo da resposta, e depois veja os contadores ou os registos do cliente para ver o trânsito acontecer. Um traceroute interior que mostra saltos privados prova o encaminhamento, não a cifra: o caminho exterior é uma observação separada, e só os contadores da interface do túnel mostram o que saiu por ele.