Traceroute com ICMP e TCP

Quando "debugamos" problemas em uma rede, sempre utilizamos alguns comandos ou temos sempre uma mesmo direcionamento: ping, traceroute, nc. Mas quando nos confrontamos com firewall em algumas partes da rede, eis que surgem os problemas, pois muitos firewalls bloqueiam o protocolo ICMP, outros pings e até mesmo o uso traceroute se torna obsoleto.

[ Hits: 34.987 ]

Por: Rodrigo de Oliveira em 16/07/2008


Introdução



Quando "debugamos" problemas em um rede, sempre utilizamos alguns comandos ou temos sempre um mesmo direcionamento:
  • ping para o host;
  • traceroute para o host;
  • nc etc.

Mas quando nos confrontamos com firewall em algumas partes da rede, eis que surgem os problemas. Pois muitos firewalls bloqueiam o protocolo ICMP, e outros pings e até mesmo o uso traceroute se torna obsoleto. Para estes casos surge uma ferramenta bem interessante , o TCPtraceroute (ou similares).

Situação:

Imaginem a situação: alguém esta tentando enviar um e-mail, porém está tentando saber porque o mesmo não está sendo enviado. O servidor está com o nome de BRUMAIL, e está disposto em uma DMZ. Infelizmente não temos acesso as configurações do firewall, para verificar se há ou não uma regra barrando o tal acesso.

Alguns casos de exemplo

Passos para se debugar o fato relatado:

Segundo o que havíamos comentando inicialmente, as primeiras tentativas se baseiam exclusivamente nas 3 principais ferramentas: ping, traceroute, netcat.

O teste de verificar se o host está sendo alcançado, ou mesmo se há resposta se baseia no ping, e veja o resultado:

$ ping -c 2 193.190.255.40
PING 193.190.255.40 (193.190.255.40) 56(84) bytes of data.

--- 193.190.255.40 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1014ms

O ping realmente não foi produtivo, já que nem mesmo nos retornou qualquer resposta. Então tentamos utilizar o segundo comando, traceroute:

$ tracepath -n 193.190.255.40
1: 213.251.167.209 0.200ms pmtu 1500
1: 213.251.167.252 0.819ms
2: 213.186.32.1 0.634ms
3: 213.186.32.4 asymm 2 2.467ms
4: 194.68.129.183 16.559ms
5: 193.191.1.1 16.443ms
6: 193.191.1.174 17.083ms
7: no reply
8: no reply
9: no reply

Neste caso, tivemos um resultado para os 7 primeiros hops. Mas o hop 7 não nos mostra nada, e o firewall provavelmente nos anula qualquer resultado conclusivo. Neste caso, vamos utilizar o comando seguinte, o netcat, já que um acesso a porta do servidor de e-mail poderá ser algo bem mais conclusivo do que as tentativas anteriores.

$ nc -n -vv 193.190.255.40 25
(UNKNOWN) [193.190.255.40] 25 (smtp) : Connection timed out
sent 0, rcvd 0

$ nc -n -vv 193.190.255.40 80
(UNKNOWN) [193.190.255.40] 80 (www) open
sent 0, rcvd 0

Assim verificamos que o nosso webserver está rodando e que o serviço de SMTP, ao qual havíamos inicialmente validado, está fora do ar. Infelizmente dizer para todos que a responsabilidade é do firewall pode ser algo ainda prematuro, pois como na maioria dos lugares, dirão que o firewall está configurado corretamente.

Solução

TCPtraceroute (ou outras variantes) é a solução. Em comparação com o traceroute normal, tcptraceroute não usa pacotes ICMP. Mas ainda assim usa o princípio do TTL para os hops, porém com pacotes TCP.

A grande questão é que os pacotes TCP sempre são liberados no firewall e não bloqueados como o ICMP. A resposta para as tentativas anteriores, para acesso ao webserver e ao SMTP seguem abaixo com a nova ferramenta.

$ tcptraceroute -i eth0 -n 193.190.255.40 80
Selected device eth0, address 213.251.167.209, port 53545 for outgoing packets
Tracing the path to 193.190.255.40 on TCP port 80 (www), 30 hops max
1 213.251.167.252 0.522 ms 0.378 ms 0.544 ms
2 213.186.32.1 0.475 ms * 5.214 ms
3 213.186.32.4 0.657 ms * 1.252 ms
4 194.68.129.183 15.986 ms 16.138 ms 15.946 ms
5 193.191.1.1 15.824 ms 16.130 ms 16.017 ms
6 193.191.1.174 16.204 ms 16.683 ms 16.917 ms
7 193.191.9.29 17.168 ms 17.091 ms 17.676 ms
8 193.190.255.40 [open] 16.953 ms 17.342 ms 17.429 ms

Aguarde, e verá que diferentemente do traceroute, neste caso são mostrados todos os hops além dos apenas 7 que tínhamos anteriormente. E ainda podemos assumir que o 193.191.9.29 é um firewall. E imediatamente testaremos o serviço SMTP (porta 25).

$ tcptraceroute -i eth0 -n 193.190.255.40 25
Selected device eth0, address 213.251.167.209, port 57399 for outgoing packets
Tracing the path to 193.190.255.40 on TCP port 25, 30 hops max
1 213.251.167.252 0.504 ms 0.388 ms 0.396 ms
2 213.186.32.1 0.292 ms * 6.403 ms
3 213.186.32.4 0.977 ms * 0.691 ms
4 194.68.129.183 16.052 ms 15.803 ms 15.862 ms
5 193.191.1.1 16.088 ms 16.021 ms 15.870 ms
6 193.191.1.174 16.806 ms 16.505 ms 16.571 ms
7 * * *
8 * * *
9 * * *

Conclusão

A conclusão é simples. É provável que o firewall esteja bloqueando conexões para a porta 25. Com estas informações, podemos convencer todos sobre as configurações errônea do firewall, já que a justificativa que se mostra é a seguinte, porque o pacote vai até o hop7 e não temos resposta do 8 em diante? E quando buscarmos pela porta 80 isso não acontece, só acontece caso tentamos o SMTP na porta 25? Bem, aí está a justificativa.

Espero ter ajudado e boa sorte.

   

Páginas do artigo
   1. Introdução
Outros artigos deste autor

Testes de stress no Apache com o comando ab

Leitura recomendada

Request Tracker 3 - Ticketing system

Trabalhando com shell e variáveis de ambiente

Personalizando o servidor centralizador de logs com rotate, script e crontab

Ubuntu 64: Como criar um chroot para aplicações 32 bits

Instalando o Nagios Core no Suse Linux Enterprise Server

  
Comentários
[1] Comentário enviado por vsmoraes em 16/07/2008 - 11:36h

Perfeito. TCPTracerout é muito útil em vários aspectos e você conseguiu demonstrar uma situação ótima de uso para essa ferramenta.

Abraços.

[2] Comentário enviado por hendrigo em 16/07/2008 - 12:52h

O Neguin..
Legal seu artigo!

[3] Comentário enviado por letifer em 16/07/2008 - 13:30h

Jack, seu artigo é bastante interessante, mas para atingir seu objetivo não seria melhor o uso do nmap ou variante?

[4] Comentário enviado por valtinho em 16/07/2008 - 14:04h

Cara, muito interessante seu artigo, me foi bem útil. Em alguns casos, o firewall do host destino pode estar configurado para não aceitar port scaners. por isso o uso deste tcptraceroute. Por favor me corrijam se estiver errado.

Abraços

[5] Comentário enviado por grandmaster em 16/07/2008 - 18:10h

Leifer,

O que ele quis demonstrar foi o uso do TCPtraceroute.

O namp é uma senhora ferramente para fazer um "scan" na rede, mas o texto está bem legal e demonstrando como o TCPtraceroute pode ser usado em um troubleshoout na rede. :D

---
Renato de Castro Henriques
CobiT Foundation 4.1 Certified ID: 90391725
http://www.renato.henriques.nom.br

[6] Comentário enviado por thelinux em 17/07/2008 - 08:46h

Informação muito útil. Parabéns.

[7] Comentário enviado por cesar.bsb em 18/07/2008 - 09:47h

Otima informação. Vai ser bem útil. Valeus!!!

[8] Comentário enviado por upc0d3 em 19/07/2008 - 19:13h

muito bom o artigo, muito mesmo...
acho que o VOL soh deveria publicar artigos deste tipo, artigos tecnicos e parar com akela palhacada de comparar o windows com o linux, cada um eh bom no que faz.. e deu..

o cara que fez esse artigo ai tah de parabens.....muito bom mesmo!!!

[9] Comentário enviado por sdevil em 19/02/2009 - 16:04h

Tenho um servidor centos 4 como firewall e nas estações de trabalho nao consigo traçar rota com tracert ja direto do servidor eu consigo.
EX. Estação de trabalho

c:\tracert 200.208.180.5
Rastreando a rota para 200.208.180.5 com maximo 30 saltos
1 * * * * * * * Esgotado o tempo limite do pedido
2 * * * * * * * Esgotado o tempo limite do pedido
3 * * * * * * * Esgotado o tempo limite do pedido
4 * * * * * * * Esgotado o tempo limite do pedido



e nada por favor me ajudem ja rastreei o ip e o seguinte diz icmp 72, também fiz a liberação do servidor e nada.

[10] Comentário enviado por woclandiner em 18/08/2010 - 15:54h

Excelente artigo. Esclarecedor, bem escrito e com um bom exemplo. Neste caso também funciona o traceroute -T -p 25 -i eth0 -n 193.190.255.40 sendo o traceroute já nativo.

[11] Comentário enviado por mlgrassi em 27/09/2016 - 16:07h

Prezados, tenho algumas dúvidas, portanto vejam se conseguem esclarecê-las:

Quando tento traçar uma rota completa com o tcptraceroute, supondo, utilizando a porta 8080. E durante os hops aparecem asteriscos (*). Cada linha com asteriscos representa necessariamente um host ou roteador o qual possui restrição para a porta 8080 ou para cabeçcalhos SYN ?
Caso afirmativo, existem portas que por padrão ficariam abertas (seja UDP ou TCP) em roteadores que compreendem a rota?


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts