Por que o traceroute morre em uma só direção através de um túnel VPN

A saída do traceroute que se completa em uma direção e imprime linhas de asteriscos na outra parece encaminhamento assimétrico, e normalmente não é. Cada salto exibido exige que a sonda chegue, que um roteador decida responder e que a resposta volte e seja associada à sonda. Quebre qualquer um desses elos e a linha vira um asterisco, enquanto o túnel continua transportando dados.

O rastreamento é evidência sobre o diagnóstico antes de ser evidência sobre o transporte. A pergunta que vale a pena fazer é qual dos três elos falhou, e a resposta vem dos pacotes, não da forma da saída.

Um asterisco é uma resposta que falta, não um salto que falta

O traceroute avança para fora enviando sondas cujo TTL expira um roteador além em cada rodada. Um roteador que descarta uma sonda expirada deveria devolver uma mensagem ICMP Time Exceeded que nomeia a si mesmo, e a ferramenta imprime esse nome. O que a ferramenta realmente espera é que essa mensagem chegue dentro de um tempo limite. Se o roteador responde de outro endereço de origem, limita a frequência com que gera erros ou descarta a sonda sem uma palavra, a rodada não produz nada imprimível.

Nenhum desses resultados diz que o caminho de ida está quebrado. Um asterisco é um relatório sobre correio sem resposta, não sobre uma estrada vazia.

O método da sonda decide qual filtro você encontra

O método padrão no Linux costuma ser uma porta de destino UDP com número alto, o tracert do Windows envia ecos ICMP, e o Linux pode receber a ordem de usar ICMP ou TCP em vez disso. Cada um deles parece um tipo diferente de tráfego para um firewall com estado ou um grupo de segurança da nuvem. Comparar um rastreamento UDP de um lado com um rastreamento ICMP do outro compara dois experimentos diferentes. Fixe o método, a família de endereços, o endereço de origem e o tempo limite antes de chamar os resultados de diferença.

Para uma comparação justa, execute o rastreamento a partir dos hosts que realmente transportam o tráfego e não de um gateway que encaminha em nome deles. Um rastreamento gerado pelo roteador usa o próprio endereço de origem e a política de saída do roteador, que podem ser mais rígidos do que qualquer coisa que um cliente veja. Registre a invocação exata para que a próxima pessoa possa repeti-la.

O valor do tempo limite é a outra metade do experimento, e é fácil deixá-lo fora das notas. Uma espera de dois segundos em um caminho congestionado relata asteriscos onde uma espera de cinco segundos relata saltos. Mantenha o valor idêntico entre execuções para que a comparação continue sendo sobre a rede.

O caminho de volta é uma rota própria

Um erro ICMP é um pacote comum com sua própria origem e destino, e precisa de uma rota de volta até o rastreador. Se a política do túnel carrega os prefixos da LAN mas não o endereço do roteador que gerou o erro, a mensagem sai por um caminho que não pode alcançá-lo. A filtragem de respostas pode descartá-la mesmo quando a rota existe, porque o pacote chega de um endereço inesperado em uma interface inesperada. Isso é um desencontro no plano de diagnóstico e não uma falha da aplicação.

Alargar cada seletor até o rastreamento se completar deixa a imagem mais bonita e a política pior. Repare o endereço de diagnóstico específico, ou aceite o asterisco e teste a aplicação de outra maneira.

Confirme o túnel com um pedido real

Um aperto de mão TCP na porta própria do serviço exercita encaminhamento, roteamento de volta e filtragem na direção que importa. Os comandos abaixo rodam nas duas pontas e comparam o que cada lado consegue abrir. Substitua a porta do serviço e o nome da interface do túnel pelos da sua própria configuração.

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

Leia primeiro as duas execuções de traceroute: se a execução ICMP mostra saltos e a TCP não, a diferença é de método, não de caminho. Depois tome o resultado do curl como a resposta em nível de aplicação, porque uma troca concluída com um código de status razoável significa que os caminhos de ida e de volta funcionam para tráfego real. A listagem de sockets mostra se a conexão está estabelecida, algo que nenhum rastreamento pode dizer.

Um túnel que transporta uma sessão interativa nas duas direções enquanto um traceroute imprime asteriscos está saudável e é apenas pouco fotogênico. Guarde a saída dos comandos de cada lado como registro e trate os saltos ausentes como uma pergunta aberta sobre o diagnóstico e não como um veredito sobre a VPN.