Linux / Comando traceroute: investigar saltos, tempos e asteriscos

O comando traceroute investiga os saltos até um destino aumentando gradualmente o TTL (Time to Live, limite de saltos no IPv4) ou o Hop Limit do IPv6. Ele mostra respostas de sondas e seus tempos de ida e volta, ajudando a investigar a rede; um salto sem resposta ou com tempo elevado não identifica, sozinho, um equipamento defeituoso.

Cada salto, ou hop, corresponde a uma etapa de encaminhamento por um roteador. As respostas descrevem o comportamento observado pelas sondas, e não uma rota definitiva de todo tráfego de aplicações. O caminho de retorno pode ser diferente do caminho de ida, e balanceamento de carga ou mudanças de rota podem produzir respostas distintas entre tentativas.

Na implementação Traceroute for Linux descrita aqui, o método padrão usa UDP (User Datagram Protocol). A opção -I seleciona ICMP Echo, do Internet Control Message Protocol, e -T seleciona sondas TCP SYN, do Transmission Control Protocol. As opções e permissões variam entre implementações e ambientes.

Sintaxe básica

traceroute [opções] destino

Os colchetes representam opções facultativas, sem serem digitados. Informe um nome ou endereço IP como destino. Confira man traceroute e traceroute --version no sistema em uso; opções de BusyBox, de outros sistemas e do tracert do Windows podem ser diferentes.

As sondas começam com um limite de saltos baixo, que é aumentado para investigar etapas mais distantes. O programa espera mensagens de diagnóstico, como ICMP Time Exceeded de roteadores intermediários, até obter uma resposta final, atingir o limite ou encerrar por outro motivo. Por isso, os números das linhas representam limites de saltos das sondas, não um inventário completo dos equipamentos físicos.

Exemplos de uso

Investigar o caminho pelo método padrão

O exemplo mostra os endereços que responderem e os tempos das sondas pelo método UDP padrão:

traceroute example.com

O domínio example.com é reservado para documentação pela IANA. Substitua-o por um destino conhecido que você tenha autorização para testar; não pressuponha que esse domínio de exemplo responderá às sondas ou fornecerá um caminho completo.

Apresentar endereços numéricos

A opção -n dispensa a busca reversa de nomes para os endereços exibidos, evitando a espera associada à apresentação desses nomes:

traceroute -n example.com

Ela não elimina a resolução inicial do nome passado como destino. Se a falha acontece nessa etapa, compare com o endereço IP correto do mesmo destino. A opção ajuda a separar a apresentação de nomes do diagnóstico de rede; não transforma os tempos das sondas em uma medida de latência de apenas um enlace.

Comparar sondas ICMP Echo

Quando o método UDP não fornece respostas suficientes e a política da rede permite esse teste, compare com ICMP Echo:

traceroute -I example.com

Uma diferença entre UDP e ICMP pode refletir regras de filtragem, limitação de respostas ou tratamento distinto dos protocolos. Ela não prova que um dos resultados seja a rota exclusiva da aplicação. Algumas formas de sondagem exigem permissões adicionais; se houver erro de permissão, consulte a configuração aprovada para esse sistema em vez de supor que o destino está inacessível.

Interpretar as respostas por salto

O exemplo numérico é repetido para relacionar a consulta à leitura das colunas:

traceroute -n example.com

Trecho esquemático de saída: o endereço e os tempos são didáticos, não uma medição real nem uma demonstração de chegada ao destino.

1  192.0.2.1  1.0 ms  0.9 ms  1.1 ms
2  * * *

• 1 e 2 identificam os limites de saltos das sondas. Na configuração padrão dessa implementação, são enviadas três sondas por salto; -q pode mudar essa quantidade.
• 192.0.2.1 representa o endereço que respondeu no primeiro salto. Ele é um endereço de documentação da TEST-NET-1, definida na RFC 5737, e não deve ser copiado como se fosse seu gateway real.
• 1.0 ms, 0.9 ms e 1.1 ms são tempos de ida e volta, ou RTT (round-trip time), de três sondas. Não são três partes de um único percurso e não devem ser somados para calcular a latência total.
• Cada * indica que não chegou uma resposta àquela sonda dentro da espera usada. * * * não significa, por si só, perda de todo tráfego encaminhado por esse roteador.

O trecho termina no segundo salto e não contém evidência de que o destino foi alcançado. Se, em uma saída completa, saltos posteriores respondem após uma linha com asteriscos, o encaminhamento pode continuar apesar de um equipamento intermediário não responder ao diagnóstico. Se nenhum salto posterior responde, ainda é preciso considerar filtros, limite de saltos e o método utilizado antes de localizar uma falha.

O RTT inclui a ida, o retorno e o tratamento da sonda. Um roteador pode dar baixa prioridade às próprias respostas ICMP e continuar encaminhando normalmente os pacotes de outras aplicações. Compare respostas do destino e amostras repetidas; subtrair os tempos de duas linhas não isola de forma confiável o atraso do enlace entre esses roteadores.

No ambiente de verificação, Git Bash 5.3.9 no Windows, traceroute não estava disponível: a consulta de versão e as três consultas distintas retornaram código 127, “command not found”. As três formas distintas passaram pela análise de sintaxe do Bash; a consulta com -n é repetida no texto. Não houve execução nativa Linux ou envio de sondas, e o trecho acima continua sendo ilustrativo.

Opções principais

Na forma completa, -w max,aqui,perto representa um máximo e dois fatores usados para adaptar a espera a respostas já observadas; “aqui” e “perto” são nomes explicativos, não valores literais. Confira a sintaxe e os valores aceitos no manual do Traceroute for Linux antes de usá-la em automação. Na falta de resposta, uma espera curta pode produzir asteriscos prematuros, sem demonstrar uma interrupção de rede.

Como investigar sem atribuir uma falha ao salto errado

1. Confirme o destino resolvido, a família IPv4/IPv6 e o método de sonda. Se precisar selecionar uma família, confira -4 ou -6 no manual local. Compare testes com as mesmas condições.
2. Leia os saltos posteriores e o resultado final junto com a linha suspeita. Um asterisco isolado ou um RTT alto em um roteador intermediário não comprova que ele esteja descartando o tráfego da aplicação.
3. Considere filtragem, limitação de ICMP, balanceamento e assimetria do retorno. Faça apenas a quantidade de consultas necessária e registre horário, opções e destino; repetir sondas agressivamente pode alterar o próprio resultado.
4. Verifique também as rotas locais com o comando ip e teste a aplicação com seu cliente e protocolo reais. Chegada de uma sonda ao host não demonstra sucesso de autenticação, resposta HTTP ou funcionamento de um banco de dados.

O método TCP usual usa uma técnica parcialmente aberta: uma resposta de porta fechada ou uma resposta inicial de porta em escuta pode indicar chegada ao destino, sem concluir uma sessão de aplicação. Escolher outro método deve respeitar as regras da rede e as permissões da conta. Para uma investigação mais simples que também ajude a examinar a MTU do caminho, consulte o comando tracepath; as duas ferramentas fornecem evidências complementares.

Pergunta frequente

Um asterisco em um salto intermediário significa que os pacotes pararam ali?

Não necessariamente. O equipamento pode não enviar ou pode limitar a resposta ao esgotamento do TTL, enquanto continua encaminhando tráfego. Observe os saltos posteriores, as respostas do destino e o comportamento da aplicação. Se a investigação inteira termina sem resposta, confira também o limite de saltos, o protocolo das sondas e as regras da rede antes de concluir onde ocorreu a falha.