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.