Traceroute é uma das ferramentas mais utilizadas não apenas por analistas de rede, mas por grande parte dos analistas de TI quando precisam fazer algum troubleshooting e entender onde (provavelmente) está acontecendo algum tipo de falha que esteja impedindo alcançar um destino X.

 

Para entendermos como o traceroute funciona, precisamos lembrar que quando estamos acessando um site ou qualquer outro recurso fora da rede local, o tráfego da ponta A para a ponta B (e vice-versa) precisam passar por diversos equipamentos, o acesso não é direto e sim intermediado pelos equipamentos no caminho da comunicação.

 

Vamos pegar o exemplo abaixo, um traceroute para 8.8.8.8. Podemos ver que do desktop onde rodei o comando até o destino, houveram 10 saltos. Podemos considerar que cada salto (exceto o último, que no caso é o servidor DNS do Google) é um roteador, ou qualquer outro tipo de equipamento que seja capaz de rotear pacotes.

 

 

Quando acessamos algo, os roteadores em cada salto não avisam para a origem o seu IP, isso seria impraticável. O roteamento funciona na maioria das vezes na base da ‘confiança’ que o próximo salto/roteador seja capaz de alcançar ou intermediar o tráfego até o destino.

 

Considerando isso, agora vamos entender como o traceroute é capaz de mapear cada salto até o destino.

 

Atualmente utilizamos majoritariamente dois possíveis protocolos em nossas redes, IPv4 ou IPv6. Em ambos os protocolos, existe um cabeçalho que define a quantidade máxima de saltos que um pacote pode fazer. No IPv4 o campo é o TTL (Time to Live) enquanto no IPv6 é campo Hop-Limit.

 

Quando um pacote passa por um roteador, ele (roteador) decrementa em ‘1’ o valor do TTL, isso é feito até o pacote chegar ao destino. Se por algum motivo o TTL zerar antes disso acontecer, o pacote é descartado. Isso impede que pacotes em loop consumam recursos indefinidamente.

 

Quando isso acontece (TTL zera) o roteador envia uma mensagem (ICMP type 11) de volta a origem informando que o TTL expirou em trânsito e que o pacote foi descartado por causa disso, essa resposta é enviada direto do roteador, com o seu IP de origem no cabeçalho IP. É a partir dessa informação que o traceroute começa a montar a sua tabela/mapa até o destino.

 

O que o traceroute realiza para fazer o mapeamento do caminho até o destino é encaminhar pacotes ICMP com TTL setado em valores incrementais, começando em 1, isso força os equipamentos no meio do caminho a droparem o pacote e avisar a origem. Vamos olhar isso no exemplo abaixo.

 

O IP 192.168.1.43 iniciou um traceroute para 8.8.8.8.

 

 

Se abrirmos o pacote, podemos ver mais detalhes. No exemplo abaixo (e como esperado) o TTL do pacote inicial está setado em 1.

 

 

Isso força o próximo salto (desde que ele não seja o destino, no caso 8.8.8.8) a dropar o pacote e mandar uma mensagem ICMP type 11 (TTL expired) de volta para a origem.

 

 

No nosso caso o primeiro IP a dropar o pacote é o 192.168.1.1, com isso o host local já tem a informação (o traceroute já começa a popular essa informação ao usuário_que o primeiro salto é esse IP, podemos ver mais detalhes abaixo.

 

 

Como quem respondeu ao pacote não foi o destino que estamos tentando alcançar (8.8.8.8) o host local prepara um novo pacote, mas ao invés de TTL 1, ele coloca o valor em ‘2’ e isso vai sendo feito (o valor do TTL é incrementado) toda vez que o host local receber uma mensagem de TTL expirado.

 

Vamos relembrar o traceroute gerado pela máquina, cada salto desse foi mapeado da forma que descrevemos acima (TTL sendo incrementado pouco a pouco).

 

 

O IP 142.251.78.11 é o último salto antes do destino, vamos olhar esse pacote. Como podemos ver, conforme o traceroute acima, esse IP é o nono salto (penúltimo), o TTL está setado em nove e esse IP, por não ser o destino também devolve uma mensagem de TTL expirado.

 

 

 

Por fim, o desktop gera um novo pacote com TTL setado em 10, mas nesse caso, o próximo salto é o destino esperado (8.8.8.8), então o destino responde a requisição ICMP (ping) e traceroute finaliza aí, pois todo o caminho já foi mapeado.

 

 

Note que novamente, o valor do TTL do pacote de resposta é diferente (de 10), isso é esperado, pois o caminho que o pacote do destino trafega de volta, não necessariamente é o mesmo que foi utilizado para alcançá-lo.