… traceroute com icmp e tcp

Quando “debugamos” problemas em um rede, sempre utilizamos alguns comandos ou temos sempre uma mesmo direcionamento:

- ping para o host

- traceroute para o host

- conectar ao host

- …

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 esta tentando saber o porque o mesmo não está sendo enviado. O servidor está com o nome de BRUMAIL, e esta 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.

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 ha 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 no 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 esta rodando. E que o serviço de SMTP, ao qual havíamso inicialmente validar, está fora do ar. Infelizmente dizer para todos que a resposabilidade é do firewall, pode ser algo ainda prematuro, pois como na maioria dos lugares dirão que o firewall está configurado corretamente.

A 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 principio o TTL para os hops, porém com pacotes TCP.

A grande questão é que os pacotes TCP, sempre são liberados nos firewall e não bloqueados com 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 tinhamos anteriormente. E ainda podemos assumir que o 193.191.9.29 é um fiewall. 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  * * *

A conclusão:

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

Espero ter ajudado e boa sorte.