Como usar o comando 'traceroute' no Linux

O que saber

  • O único parâmetro que você deve incluir com um comando traceroute é o nome do host ou endereço IP do destino.
  • Inicie as sondagens com TTL de um e aumente em um até obter uma "porta inacessível" ICMP ou atingir um valor máximo de tentativas.

Este artigo cobre informações de traceroute aplicáveis ​​a máquinas Linux e inclui explicações de troca de comando, além de informações sobre como interpretar os resultados. Traceroute é usado de forma diferente no Windows.

Como funciona o Traceroute

O comando traceroute mapeia a jornada que um pacote de informações realiza desde sua origem até seu destino. Um uso do traceroute é localizar quando ocorre perda de dados em uma rede, o que pode significar que um nó está inativo.

Porque cada salto no registro reflete um novo servidor ou roteador entre o PC de origem e o pretendido alvo, analisando os resultados de uma varredura traceroute identifica pontos lentos que podem afetar adversamente sua rede tráfego.

Solução de problemas com Traceroute

Avaliar a rota específica que o tráfego de rede segue (ou encontrar o gateway malfeitor que está descartando seus pacotes) apresenta vários desafios de solução de problemas. Traceroute usa o protocolo IP tempo de Viver campo para solicitar uma resposta ICMP TIME_EXCEEDED de cada gateway ao longo do caminho para um host de destino.

O único parâmetro que você deve incluir ao executar o comando traceroute é o nome do host ou endereço IP do destino.

Sintaxe e opções do Traceroute

Captura de tela da sintaxe do traceroute no Ubuntu
Sintaxe do Traceroute no Ubuntu.

O Traceroute segue a seguinte sintaxe geral:

traceroute [-dFInrvx] [-f first_ttl] [-g gateway] [-i iface] [-m max_ttl] [-p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs] host [packetlen] 

Você pode alterar o desempenho ou a saída do comando especificando uma ou mais opções opcionais.

Traceroute Command Switches
Trocar Explicação
-f Defina o tempo de vida inicial usado no primeiro pacote de sondagem de saída.
-F Defina o bit "não fragmentar".
-d Habilite a depuração de nível de soquete.
-g Especifique um gateway de rota de origem livre (8 no máximo).
-eu Especifique uma interface de rede para obter o endereço IP de origem para pacotes de sondagem de saída. Normalmente, isso só é útil em um host multihomed. (Veja o -s sinalize para outra maneira de fazer isso.)
-EU Use ICMP ECHO em vez de Datagramas UDP.
-m Defina o tempo de vida máximo (número máximo de saltos) usado nos pacotes de sondagem de saída. O padrão é 30 saltos (o mesmo padrão usado para conexões TCP).
-n Imprimir endereços de salto numericamente em vez de simbolicamente e numericamente (salva uma pesquisa de endereço para nome do servidor de nomes para cada gateway encontrado no caminho).
-p Defina o número da porta UDP base usado nas sondas (o padrão é 33434). Traceroute espera que nada esteja escutando nas portas UDP base para base + nhops - 1 no host de destino (portanto, uma mensagem ICMP PORT_UNREACHABLE será retornada para encerrar o rastreamento da rota). Se algo estiver escutando em uma porta no intervalo padrão, esta opção pode ser usada para escolher um intervalo de porta não usado.
-r Ignore as tabelas de roteamento normais e envie diretamente para um host em uma rede conectada. Se o host não estiver em uma rede conectada diretamente, um erro será retornado. Esta opção pode ser usada para executar ping em um host local por meio de uma interface que não tem rota por meio dele (por exemplo, depois que a interface foi descartada por encaminhado(8C)).
-s Use o seguinte endereço IP (que geralmente é fornecido como um número IP, não um nome de host) como o endereço de origem nos pacotes de sondagem de saída. Em hosts multihomed (aqueles com mais de um endereço IP), esta opção pode ser usada para forçar o endereço de origem a ser diferente do endereço IP da interface para a qual o pacote de investigação é enviado. Se o endereço IP não for um dos endereços de interface desta máquina, um erro será retornado e nada será enviado. (Veja o -eu sinalize para outra maneira de fazer isso.)
-t Colocou o tipo de serviço em pacotes de teste para o seguinte valor (padrão zero). O valor deve ser um número inteiro decimal no intervalo de 0 a 255. Esta opção pode ser usada para ver se diferentes tipos de serviço resultam em caminhos diferentes. (Se você não estiver executando o 4.4bsd, isso pode ser acadêmico, uma vez que os serviços de rede normais como telnet e ftp não deixe você controlar os TOS.) Nem todos os valores de TOS são legais ou significativos - consulte a especificação de IP para definições. Valores úteis são provavelmente `-t16'(baixo atraso) e `-t8'(alto rendimento).
-v Saída detalhada. Os pacotes ICMP recebidos diferentes de TIME_EXCEEDED e UNREACHABLEs são listados.
-C Defina o tempo (em segundos) de espera por uma resposta a uma sonda (padrão 5 segundos).
-x Alternar IP somas de verificação. Normalmente, isso evita que o traceroute calcule somas de verificação de IP. Em alguns casos, o sistema operacional pode sobrescrever partes do pacote de saída, mas não pode recalcular a soma de verificação; assim, em alguns casos, o padrão é não calcular somas de verificação e usar -x faz com que sejam calculados. Observe que as somas de verificação geralmente são necessárias para o último salto ao usar sondas ICMP ECHO (-EU), então eles são sempre calculados ao usar o ICMP.
-z Defina o tempo (em milissegundos) para fazer uma pausa entre as análises (padrão 0). Alguns sistemas, como Solaris e roteadores da Cisco, limitam a taxa de mensagens icmp. Um bom valor para usar com isso é 500 (por exemplo, 1/2 segundo).

Interpretando os resultados

O Traceroute descreve o caminho que um pacote IP segue até um host da Internet, iniciando pacotes de sondagem UDP com um pequeno TTL e, em seguida, ouvindo uma resposta ICMP de "tempo excedido" de um gateway. Inicie as sondagens com um TTL de um e aumente em um até obter uma "porta inacessível" ICMP (o que significa que o pacote chegou ao seu destino) ou atingiu um valor máximo de tentativas, que é padronizado para 30 saltos e pode ser alterado com o -m bandeira.

Quando o traceroute é executado, ele envia três testes em cada configuração de TTL e, em seguida, imprime uma linha no console mostrando o TTL, o endereço do gateway e o tempo de ida e volta de cada teste. Se as respostas da investigação vierem de gateways diferentes, o endereço de cada sistema respondente será impresso. Se o traceroute não receber uma resposta em cinco segundos (alterado com o -C sinalizador), ele imprime um asterisco para esse probe.

Para evitar que o processamento do pacote de investigação UDP sobrecarregue o host de destino, o traceroute define a porta de destino com um valor que o dispositivo provavelmente não usará. Se uma rede ou serviço no destino usar essa porta, altere o valor usando o -p bandeira.

Exemplos de resultados do Traceroute

Um exemplo de uso e saída retornará resultados semelhantes a este exemplo:

[yak 71]% traceroute nis.nsf.net.
traceroute para nis.nsf.net (35.1.1.48), máximo de 30 saltos, pacote de 38 bytes
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilás-dmc. Berkeley. EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilás-dmc. Berkeley. EDU (128.32.216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc. Berkeley. EDU (128.32.136.23) 39 ms 40 ms 39 ms
5 ccn-nerif22.Berkeley. EDU (128.32.168.22) 39 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms
8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms

A segunda e a terceira linhas são iguais. Esse resultado está relacionado a um kernel com erros no sistema de segundo salto - lbl-csam.arpa - que encaminha pacotes com TTL zero (um bug na versão distribuída do 4.3 BSD). Você deve adivinhar o caminho que os pacotes estão percorrendo entre os países, uma vez que a NSFNet (129.140) não fornece traduções de endereço para nome para seus NSSes.

Exemplo de gateway silencioso

Um exemplo mais interessante é:

[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute para allspice.lcs.mit.edu (18.26.0.115), 30 saltos no máximo
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilás-dmc. Berkeley. EDU (128.32.216.1) 19 ms 19 ms 19 ms
3 lilás-dmc. Berkeley. EDU (128.32.216.1) 39 ms 19 ms 19 ms
4 ccngw-ner-cc. Berkeley. EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley. EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

Observe que os gateways em 12, 14, 15, 16 e 17 saltos de distância não enviam mensagens ICMP de "tempo excedido" ou as enviam com um TTL muito pequeno para chegar até nós. As linhas 14 a 17 estão executando o código MIT C Gateway que não envia mensagens de "tempo excedido".

O gateway silencioso 12 no exemplo acima pode ser o resultado de um bug no código de rede 4. [23] BSD e seus derivados: as máquinas que executam o código 4.3 e anteriores enviam uma mensagem inacessível usando qualquer TTL restante no datagrama original. Para gateways, o TTL restante é zero, o ICMP "tempo excedido" é garantido que não retornará para nós.

Exemplo de gateway silencioso de sistema de destino

O comportamento desse bug é um pouco mais interessante quando aparece no sistema de destino:

1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilás-dmc. Berkeley. EDU (128.32.216.1) 39 ms 19 ms 39 ms
3 lilás-dmc. Berkeley. EDU (128.32.216.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc. Berkeley. EDU (128.32.136.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.Berkeley. EDU (128.32.168.35) 39 ms 39 ms 39 ms
6 csgw. Berkeley. EDU (128.32.133.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip. Berkeley. EDU (128.32.131.22) 59 ms! 39 ms! 39 ms!

Observe que existem 12 "gateways" (13 é o destino final) e a última metade deles está faltando. O que realmente está acontecendo é que o servidor chamado rasgar (um Sun-3 executando Sun OS 3.5) está usando o TTL de nosso datagrama de chegada como o TTL em sua resposta ICMP. Portanto, a resposta atingirá o tempo limite no caminho de retorno (sem notificação enviada a ninguém, uma vez que ICMPs não são enviados para ICMPs) até testarmos com um TTL que tenha pelo menos o dobro do comprimento do caminho - em outras palavras, o rip tem realmente apenas sete saltos longe.

Uma resposta que retorna com um TTL de 1 é uma pista de que esse problema existe. Traceroute imprime um! após o tempo se o TTL for menor ou igual a 1. Como os fornecedores distribuem muitos softwares obsoletos (DEC's Ultrix, Sun 3.x) ou não padrão (HPUX), espere ver esse problema com frequência e tome cuidado ao escolher o host de destino de suas sondas.

Outras anotações possíveis após o tempo são ! H, ! N, ou ! P (host, rede ou protocolo inacessível), ! S (falha na rota de origem), ! F- (fragmentação necessária - o valor RFC1191 Path MTU Discovery é exibido), ! X (comunicação proibida administrativamente), ! V (violação de precedência de host), ! C (corte de precedência em vigor), ou ! (Código ICMP inacessível). Esses códigos são definidos pelo RFC1812, que substitui o RFC1716. Se quase todas as sondagens resultarem em algum tipo de host inacessível, o traceroute desistirá e será encerrado.

Este programa destina-se ao uso em teste, medição e gerenciamento de rede. Deve ser usado principalmente para isolamento manual de falhas. Por causa da carga que pode impor à rede, não é aconselhável usar o traceroute durante as operações normais ou a partir de scripts automatizados.