Explicando o Comando Traceroute

O Traceroute pode ser uma ferramenta inestimável ao tentar diagnosticar problemas de conexão com hosts em outras redes. No entanto, para ser utilizado eficazmente, é preciso entender como funciona e o que significa a saída.

O Traceroute trabalha manipulando o valor Time-To-Live (TTL) no cabeçalho IP (figura 1). Como eu tive que fazer meus exemplos usando a rede interna Stratus, X'ed fez a representação hexadecimal do endereço IP nos traços do pacote e traduziu todos os octetos em qualquer notação decimal doada para um código de letra único de A a W. O número de letras representa o número de dígitos no octeto. Isto é AAA representa um número de 3 dígitos enquanto J representa um número de 1 dígito.

Figura 1 - estrutura de monitor_de_pacote com alta luminosidade TTL

Todo roteador que processar o pacote diminuirá o valor TTL em 1 e se o valor TTL for maior que 0 passará o pacote para o próximo roteador ou para o destino final. Se o valor TTL for 0, o roteador descartará o pacote e *pode* enviar uma mensagem de tempo ICMP excedido de volta para o remetente. A chave é *pode*, alguns roteadores não enviarão uma mensagem com tempo excedido de volta ou só o farão se não estiverem ocupados. Além disso, alguns firewalls bloquearão a mensagem ICMP, portanto, mesmo que o roteador envie a mensagem de tempo excedido, o traceroute executando o host poderá nunca vê-la.

O Traceroute começa enviando uma mensagem para o destino alvo com um valor TTL de 1. Ele vezes o tempo que leva desde o momento em que envia a mensagem até obter uma resposta.

Figura 2 - quadro e resposta do traçador de monitor de pacotes

Por padrão, o comando traceroute envia três mensagens com uma TTL de 1 e informa as três vezes e o nome e/ou endereço IP do roteador que enviou a resposta. Eu sempre uso o argumento -numérico para não ter que esperar pela resolução do nome (figura 3). Traceroute então incrementa o TTL em 1 e o faz novamente. Ele continuará incrementando a TTL até obter uma resposta do destino alvo ou algum limite, 30 (por padrão), seja alcançado. Você pode encontrar documentação sobre todos os argumentos do traceroute no manual do OpenVOS STREAMS TCP/IP Administrator's Guide (R419 ).

Figura 3 - saída do traceroute

Você esperaria que à medida que a TTL aumenta os tempos, e este é geralmente o caso, mas nem sempre, compare o terceiro tempo relatado de lúpulo 6 (79 ms) e lúpulo 5 (80 ms) na figura 3. Há várias razões para isto. Primeiro, a rede não é determinista, às vezes leva apenas mais tempo. Segundo, o roteador no hop N-1 pode estar mais ocupado do que o roteador no hop N e demorar mais para se locomover e enviar a mensagem ICMP. Finalmente, o caminho de retorno do roteador N pode ser mais rápido do que o caminho de retorno do roteador N-1. Por exemplo, não há exigência de que o 4º roteador envie sua resposta de volta à fonte através dos roteadores 3, 2 e 1. Ele poderia enviar sua resposta diretamente ao roteador 1, que pode ser significativamente mais rápido. Isto significa que, embora o traceroute seja muito bom em relatar a rota que um pacote leva do host de envio para o host de destino, você não pode confiar que um pacote enviado do host de destino para o host de envio tome o mesmo caminho apenas em sentido inverso. Isto é conhecido como roteamento assimétrico.

O Traceroute pode anexar uma bandeira a uma hora que indique que recebeu algo diferente do tempo esperado que excedeu a mensagem. As bandeiras são:

!H - hospedeiro inalcançável
!N - rede inalcançável
!P - protocolo inalcançável

Por exemplo, a figura 4 mostra que o primeiro roteador não sabe como alcançar a rede alvo e, portanto, retorna uma mensagem inalcançável e o traceroute termina naquele ponto.

Figura 4 Mensagens inacessíveis em rede

Um asterisco (*) no lugar de um tempo indica que o traceroute não recebeu uma resposta. Como afirmei acima, pode ser que o roteador não envie uma mensagem de tempo excedido ICMP, pode ser que um firewall tenha bloqueado a mensagem de tempo excedido na volta ou que um firewall tenha bloqueado a mensagem de saída. Também pode ser que a rede tenha simplesmente descartado ou a mensagem de saída ou a mensagem de retorno.

Um único ou mesmo dois timeouts em um salto (figura 5) provavelmente indica ou que o roteador não enviou a mensagem porque estava ocupado ou que a rede estava deixando cair os pacotes (ou ambos). Observe o 8º salto na figura 5, o asterisco antes do endereço IP significa que a primeira mensagem no conjunto foi programada.

Figura 5 - roteador ocupado ou pacotes descartados

Se todas as três mensagens de tempo esgotado, mas os tempos de relatório subseqüentes do lúpulo (figura 6), é provável que o roteador para aquele lúpulo simplesmente não envie mensagens com tempo ICMP excedido.

Figura 6 - roteador(es) não responsivo(s)

Se todos os lúpulos passarem de um certo tempo limite (figura 7), é provável que haja um firewall bloqueando tanto as mensagens de saída quanto as de retorno.

Figura 7 - bloqueio de firewall

Há uma outra razão pela qual tudo passa de um certo ponto de vista. É quando o alvo não responde. Nem todos os alvos vão responder e quando isso acontece você tem algo que se parece com a figura 8. A diferença entre as figuras 7 e 8 é que na figura 8 o último roteador a enviar uma resposta é o roteador que é local para o alvo. Como você pode dizer que este é o caso? Às vezes o endereçamento torna óbvio, por exemplo, o alvo é 192.168.1.12 e 192.168.1.1 é o último roteador a responder. Não é tão óbvio na figura 9, EEE.FFF.W.XXX pode ser o último roteador antes de EEE.FFF.GGG.HHH, eles têm os primeiros 16 bits em comum. Mas sem conhecer o esquema de sub-rede utilizado pela rede do alvo, não há como ter certeza sem perguntar.

Figura 8 - alvo não responde

Também é possível obter respostas de dois ou mais roteadores para o mesmo salto (figura 9). Isto pode acontecer se os roteadores estiverem balanceando a carga ou se a rede estiver instável e as rotas estiverem mudando ou, como no caso da figura 9, o roteador AAA.BBB.CC.KKK não era o roteador ideal e, após encaminhar o pacote para AAA.BBB.II.J, enviou uma mensagem de redirecionamento de volta à fonte para mudar sua tabela de roteamento.

Figura 9 - duas respostas para o mesmo salto

Há dois tipos de comandos de traceroute que se distinguem pelo tipo de mensagem que enviam. Alguns traceroutes, como o encontrado nos sistemas Microsoft Windows, enviam mensagens de solicitação de eco ICMP (ping); outros, como o que roda sob STCP, enviam mensagens UDP. Saber que tipo de traceroute você está usando é importante se você precisar configurar firewalls para deixar os pacotes passar ou escrever filtros analisadores de protocolo. Além disso, a resposta do alvo será diferente. Se o alvo receber um pedido de ping, ele enviará de volta uma resposta de ping; se receber uma mensagem UDP, então a resposta dependerá do número da porta. Se a porta estiver em uso, a aplicação de escuta provavelmente descartará o pacote porque ele não atende aos requisitos de estrutura de mensagem da aplicação. Se a porta não estiver em uso, o host *pode* enviar de volta uma mensagem ICMP de destino inalcançável. Por esse motivo, o traceroute seleciona portas que normalmente não são utilizadas.

O número de porta que o anfitrião alvo verá dependerá de quantos lúpulos são necessários para alcançá-lo. Traceroute inicia a porta de destino em 33435 (por padrão) e incrementa o número da porta para cada mensagem (figura 10). O alvo, portanto, vê 3 portas diferentes, as chances não são todas as três que estarão em uso. A porta de origem é baseada no ID do processo de envio. Um determinado processo sempre utilizará a mesma porta de origem.

Finalmente, a menos que haja um problema no primeiro salto, provavelmente não haverá muito que você possa fazer para resolver o problema. Uma vez que o STCP (ou qualquer pilha de rede do host) envia um pacote para o roteador local, ele está fora de suas (e de suas) mãos. Entretanto, se você souber o endereço IP do último salto que responde ou o salto em que os timeouts começam a ocorrer de repente, você tem uma idéia de onde está o problema e pode contatar o grupo correto de administradores de rede para resolvê-lo.