Por que um servidor atrás de um cliente VPN responde pelo túnel

As conexões de entrada para um host que também executa um cliente VPN falham de forma muito específica: o handshake chega, o daemon responde e o cliente não recebe nada de volta. Nada bloqueia a porta. A resposta saiu pelo túnel, porque o túnel possui a rota padrão e o kernel roteia as respostas por destino, não pela memória de onde veio a requisição. O daemon está bem e a porta está aberta.

A resposta é roteada, não lembrada

Um cliente VPN que instala uma rota padrão adiciona uma entrada que supera o gateway da LAN, seja por métrica, seja dividindo o espaço em duas metades mais específicas. Os pacotes de saída agora escolhem a interface do túnel. O kernel nunca pergunta de onde o pacote que está sendo respondido chegou originalmente. Essa única omissão explica todos os sintomas a seguir.

O sentido de ida é roteado por destino, e o de volta também. A resposta é endereçada a um cliente público, que o túnel carregará de bom grado. A extremidade remota recebe um pacote cuja origem não possui, descarta-o, e o cliente original espera até o tempo esgotar.

A filtragem estrita do caminho inverso pode descartar o pacote de entrada antes de o daemon lê-lo. Verifique esse contador primeiro, porque um descarte de filtro e um erro de roteamento parecem idênticos de fora.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

O primeiro comando mostra qual rota padrão vence agora. O segundo informa se a filtragem estrita se aplica globalmente ou por interface, e o terceiro mostra qualquer regra da cadeia de encaminhamento que possa estar envolvida.

Três maneiras de conservar o caminho de volta

Excluir o destino do serviço do túnel é a opção mais estreita. Uma rota de host apontada para o gateway da LAN, mais um daemon vinculado ao endereço físico em vez de todos os endereços, mantém esse único fluxo fora do túnel. A mudança é local e fácil de reverter.

O roteamento por políticas é a resposta geral. Uma regra baseada no endereço de origem ou numa marca de firewall escolhe uma tabela cuja rota padrão aponta para o gateway WAN, enquanto as conexões do próprio host continuam usando o túnel. Mantenha a prioridade explícita para que a regra não seja ofuscada mais tarde.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Os dois primeiros comandos constroem o caminho alternativo para respostas com origem no endereço público. O terceiro pergunta ao kernel qual caminho exatamente essa origem e destino tomariam, e assim você confirma que a regra tem algum efeito.

A tradução de origem é a terceira opção e a única que sobrevive a um roteador que já faz NAT diante do serviço. A resposta tem de voltar a esse roteador, e o mascaramento para a interface WAN consegue isso enquanto esconde o cliente dos registros do serviço. Substituir a rota padrão à mão após conectar é um diagnóstico, porque o cliente reescreve a tabela na próxima reconexão.

Quando a máquina também roteia para uma LAN

A mesma falha aparece um salto mais adiante quando o host roteia para os dispositivos atrás de si. Uma conexão de entrada é encaminhada a um dispositivo interno cujo único caminho de volta é o túnel, e a resposta chega ao cliente externo a partir do endereço do provedor. O dispositivo interno funciona corretamente o tempo todo.

O rastreamento de conexões vê então uma resposta de um fluxo que nunca registrou e a descarta. A tradução de destino entrega a conexão de entrada ao dispositivo, e a tradução de origem faz a resposta parecer vir do próprio roteador.

Uma rota de política que mantém a porta encaminhada na WAN enquanto o tráfego do próprio roteador usa o túnel é o equivalente mais limpo. Sem tradução de origem a resposta é endereçada ao cliente externo, e o dispositivo interno não tem nenhuma rota para esse endereço.

Três sondagens que separam as causas

Faça três sondagens: uma conexão para a máquina a partir da internet, uma conexão a partir dela para um host público e uma consulta de nome. Quando as duas primeiras discordam, o caminho de volta é o culpado. Quando os nomes falham nos dois sentidos, o resolvedor é outra falha que apenas compartilha o túnel.

Corrija primeiro a questão do roteamento, depois olhe os nomes. Misturar os dois é como um servidor que funciona é culpado por um resolvedor quebrado.

Anote qual interface a exceção nomeia e mantenha a configuração sob controle de versão. Uma regra escrita contra uma interface renomeada após uma atualização passa hoje e falha após o próximo reinício.