Testes rápidos em sua rede: parte 2

O nslookup apresentado no texto anterior é bastante útil para sabermos se não há um problema de resolução de nomes, porém algumas vezes nós podemos estar com dificuldades no roteamento de pacotes, o que pode ser testado usando o Traceroute que veremos a seguir.

traceroute

Esta ferramenta permite que você tenha uma visão do caminho por onde as suas requisições estão passando. Ele vai te relatar, quando possível, cada salto em um novo roteador/firewall, de forma que se algum deles tiver uma falha ou regra de bloqueio, você poderá identificar de forma mais assertiva.

Eu vou considerar aqui o uso do traceroute que era a ferramenta padrão na maioria das distribuições Linux. Atualmente algumas vem com uma versão mais moderna porém limitada chamada tracepath e no Windows, também há uma versão chamada “tracert” que oferece algumas limitações também.

Embora tenham o mesmo propósito, o maior problema destas versões “diferentonas” é que elas usam o algoritmo concebido há algumas décadas e que na maioria das redes atuais acaba sendo bloqueado apresentando resultados falsos ou imprecisos.

O traceroute pode ser instalado usando o gerenciador padrão de sua distribuição Linux sem grandes dificuldades, como por exemplo usando o comando, abaixo em distribuições compatíveis com Debian, tal como Ubuntu, Mint etc:

sudo apt install traceroute

Uma desvantagem desta versão do traceroute no Linux é que ele requer privilégios de root para ser usado com alguns parâmetros, mas isso é melhor do que não ter certos parâmetros que foram removidos do tracepath e que são importantes.

A sintaxe mais básica do traceroute requer que você use: traceroute <endereço final a alcançar> e por padrão ele usará a porta 33434 no protocolo UDP para testar os nós da rede ao longo do caminho, até chegar ao destino. Isso é o que se espera de todas as variações do traceroute, tal como o tracepath e o tracert, no entanto isso não é suficiente.

Usando uma boa versão da ferramenta, você pode mudar este protocolo para TCP ou ICMP e até mesmo a porta a ser alcançada, dependendo do propósito e esta é uma dica de ouro, porque nem sempre um determinado sistema está com permissão de responder requisições fora daquela o qual ela foi definida.

Por exemplo, por que um administrador deixaria portas UDP abertas no seu servidor WEB, que só precisa escutar nas portas 80/TCP e 443/TCP? Se você achou que ele deixaria uma porta de testes aberta só porque em algum momento um novato precisaria fazer testes… achou errado.

Da mesma forma, o fato de você mandar ping e não chegar a um destino, não necessariamente indica que o sistema esteja fora do ar. Ele pode estar apenas com um firewall bloqueando estas requisições.

Conhecer bem o que você está testando é fundamental. Testar a porta errada resulta em dados errados que serão usados para embasar soluções que não funcionam. Se você quer testar um serviço de DNS, você deve testar a porta 53/DNS, é um DHCP 67/UDP, servidor aleatório qualquer? Descubra a porta de serviço antes.

Use o protocolo certo de acordo com sua necessidade apenas usando as chaves como seguem:

  • -I = ICMP
  • -T = TCP (Se indicado, testa a porta 80/TCP, usada por servidores WEB)
  • -U = UDP (Se indicado, testa a porta 53/UDP, usada por serviços DNS)

Caso opte por identificar a porta TCP ou UDP diferente do padrão use o parâmetro “-p” seguido do número da porta.

Veja no exemplo abaixo um teste de traceroute usando o método tradicional (porta 33434/UDP). Cada linha, indica um salto, ou melhor, um roteador que o pacote teve que atravessar desde a minha máquina até o servidor de destino, que neste teste é o velho conhecido DNS público do Google (8.8.8.8)

sudo traceroute -4 dns.google
traceroute to dns.google (8.8.8.8), 30 hops max, 60 byte packets
 1  router.lan (192.168.88.1)  0.259 ms  0.310 ms  0.219 ms
 2  b3d20801.virtua.com.br (179.210.8.1)  11.296 ms  11.361 ms  11.272 ms
 3  c91108dd.rjo.static.virtua.com.br (201.17.8.221)  10.989 ms  10.733 ms  10.966 ms
 4  c9110520.virtua.com.br (201.17.5.32)  10.500 ms  10.489 ms  10.601 ms
 5  c9112281.virtua.com.br (201.17.34.129)  11.745 ms  11.708 ms  11.671 ms
 6  c911229e.virtua.com.br (201.17.34.158)  10.620 ms  13.484 ms  13.648 ms
 7  c9112292.virtua.com.br (201.17.34.146)  13.197 ms  3.417 ms  11.218 ms
 8  c9111fca.virtua.com.br (201.17.31.202)  12.237 ms  12.147 ms  12.164 ms
 9  142.250.39.113 (142.250.39.113)  10.817 ms 108.170.248.225 (108.170.248.225)  11.840 ms  11.248 ms
10  108.170.228.39 (108.170.228.39)  11.225 ms 142.251.78.27 (142.251.78.27)  9.705 ms 142.251.61.241 (142.251.61.241)  10.154 ms
11  * * *
[...]
30  * * *

Notou os “* * *” no final? Eles se repetiram dos passos 11 ao 30 (para reduzir o tamanho da listagem eu os substituí pelos “[…]”). Isso ocorre porque após este ponto nós não conseguimos comunicação com os roteadores seguintes ou com o servidor final usando as portas escolhidas.

Sem novos testes eu sairia por ai alardeando que o serviço de DNS do Google está com problemas, o que é um equivoco (nunca julgue o sistema alheio sem antes ter absoluta certeza do que está fazendo).

E como eu já sei que neste servidor há um serviço WEB rodando, posso ser um pouco mais racional e tentar novos testes com o protocolo TCP (chave “-T”) que vai requisitar respostas da porta 80. E … veja por si mesmo o resultado.

sudo traceroute -4 -T  8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  router.lan (192.168.88.1)  0.293 ms  0.354 ms  0.412 ms
 2  b3d20801.virtua.com.br (179.210.8.1)  13.209 ms  12.912 ms  13.224 ms
 3  c91108dd.rjo.static.virtua.com.br (201.17.8.221)  12.499 ms  12.544 ms  12.236 ms
 4  c9110520.virtua.com.br (201.17.5.32)  12.805 ms  12.143 ms  12.165 ms
 5  c9112281.virtua.com.br (201.17.34.129)  13.060 ms  12.843 ms  12.871 ms
 6  c911229e.virtua.com.br (201.17.34.158)  63.838 ms  62.924 ms  62.977 ms
 7  c9112292.virtua.com.br (201.17.34.146)  11.415 ms  16.514 ms  16.442 ms
 8  c9111fca.virtua.com.br (201.17.31.202)  16.575 ms  16.301 ms  16.331 ms
 9  * * *
[...]
30  * * *

Ops! A ideia foi boa mas tivemos o mesmo problema. Será que o serviço de DNS do Google bugou mesmo!? Não, espere.

Respire fundo e pense. Estamos falando de servidores WEB do Google que supostamente são muito bem configurados e respondem na porta 443/TCP que são para servidores WEB/SSL (ou HTTPS), não na porta 80.

Vamos então identificar a porta que queremos e testar denovo?

sudo traceroute -4 -T -p443 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  router.lan (192.168.88.1)  0.224 ms  0.269 ms  0.181 ms
 2  b3d20801.virtua.com.br (179.210.8.1)  15.190 ms  15.158 ms  15.302 ms
 3  c91108dd.rjo.static.virtua.com.br (201.17.8.221)  16.129 ms  15.538 ms  15.844 ms
 4  c9110520.virtua.com.br (201.17.5.32)  15.794 ms  15.279 ms  15.838 ms
 5  c9112281.virtua.com.br (201.17.34.129)  16.551 ms  16.570 ms  16.242 ms
 6  c911229e.virtua.com.br (201.17.34.158)  15.996 ms  15.634 ms  15.204 ms
 7  c9112292.virtua.com.br (201.17.34.146)  14.821 ms  18.383 ms  18.334 ms
 8  c9111fca.virtua.com.br (201.17.31.202)  19.598 ms  19.678 ms  19.600 ms
 9  142.250.39.113 (142.250.39.113)  19.335 ms 108.170.248.225 (108.170.248.225)  19.378 ms 108.170.248.241 (108.170.248.241)  19.927 ms
10  216.239.42.153 (216.239.42.153)  19.306 ms 142.251.48.155 (142.251.48.155)  19.102 ms 142.251.48.153 (142.251.48.153)  18.689 ms
11  dns.google (8.8.8.8)  18.816 ms  18.919 ms  18.900 ms

Era isso! Perceba que requisitando a porta correta, conseguimos rastrear todo o caminho dos pacotes entre a minha máquina e o DNS do Google sem problema.

É perfeitamente normal, embora não desejável, que no meio do caminho surjam “* * *”, por exemplo, entre os passos 4 e 5, ou qualquer outro local entre o 2 e 10.

Estas falhas, mesmo que possam ser indícios de um um problema mais grave e que certamente afeta muito mais gente do que apenas as da sua casa ou empresa, estão além de nossas possibilidades de análise e manutenção. Se após eles tivermos ao menos uma resposta, siga a diante como se não tivesse visto esta falha.

Por outro lado, caso o pacote pare em algum roteador que você tenha acesso e condições de analisar e prestar manutenção, você deverá fazê-lo.

A título de curiosidade, nos exemplos mostrados eu usei a chave “-4” para forçar o rastreamento apenas com o protocolo IPv4. Sem ela o traceroute poderia misturar respostas IPv4 e IPv6, quando fazemos consultas por nome, ao invés de IP, o que nem sempre é desejável. Caso queira testar apenas uma rede IPv6, você usaria “-6” com o mesmo efeito.

Sabe o que é uma boa dica? Mantenha anotado em algum lugar acessível as rotas de alguns serviços importantes. Tanto de dentro da sua empresa para fora (escolha alguns bons sites de referência para testar) quanto de fora da empresa para serviços internos (digamos, da sua casa para o servidor WEB, ou uma aplicação da empresa). O dia que você tiver problemas de roteamento, você vai me agradecer por ter anotado esta dica.

E nos falamos no próximo artigo. Até breve!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.