Como diagnosticar perda de pacotes e rotas com o comando mtr

O que é o comando mtr e por que ele supera o ping tradicional

Quando uma aplicação corporativa começa a sofrer com lentidão intermitente ou quedas de conexão, a primeira ferramenta que costumamos abrir no terminal do Linux é o bom e velho ping. No entanto, o ping tradicional mostra apenas se o destino final está respondendo e qual é o tempo médio de ida e volta, conhecido como latência. Ele é cego para o que acontece no meio do caminho, ou seja, por quais roteadores intermediários os dados estão passando antes de chegar ao destino. É exatamente aí que entra o mtr, que une o melhor de dois mundos ao rodar testes contínuos enquanto rastreia cada salto da rota.

Na prática, o mtr executa um diagnóstico constante e atualiza as estatísticas na tela a cada segundo, permitindo que você observe o comportamento da rede ao longo do tempo. Enquanto investiga problemas de infraestrutura ou decide verificar gargalos operacionais, é muito comum precisar cruzar dados de conectividade com a saúde física do hardware, processo semelhante ao que realizamos ao diagnosticar gargalos de CPU e temperatura no Linux via SSH. Compreender essa dinâmica de ponta a ponta evita que você culpe o servidor errado por falhas que estão, na verdade, no meio do caminho.

Como instalar e executar a leitura básica do mtr no terminal

Antes de aplicar qualquer parâmetro avançado, precisamos garantir que a ferramenta esteja instalada no sistema operacional. Nas distribuições baseadas em Debian e Ubuntu, a instalação é feita rapidamente através do gerenciador de pacotes padrão com privilégios administrativos. O comando básico exige apenas que você informe o endereço IP ou o nome de domínio que deseja testar, iniciando imediatamente a captura de pacotes em tempo real na tela do seu terminal.

sudo apt update && sudo apt install mtr -y
mtr google.com

Ao executar essa linha, você verá uma tabela interativa sendo preenchida linha por linha. Cada linha representa um roteador ou salto pelo qual o pacote de dados passou. As colunas exibem informações vitais, como a porcentagem de pacotes perdidos, o número de pacotes enviados, o tempo de resposta atual, além das médias e do pior tempo registrado. Se você notar que o tráfego local apresenta anomalias antes mesmo de sair da interface, vale a pena monitorar tráfego de rede no Linux com bpfTOP para isolar se o problema é interno ou externo.

Como diferenciar perda de pacotes real de falsos positivos nos saltos

Um dos erros mais comuns cometidos por administradores de sistemas iniciantes é entrar em pânico ao ver uma alta taxa de perda de pacotes em um salto intermediário durante a execução do mtr. Na grande maioria das vezes, isso é um falso positivo inofensivo. Os roteadores de internet modernos são projetados para priorizar o encaminhamento rápido de dados e costumam limitar o processamento de pacotes de diagnóstico, como o protocolo ICMP, que serve para enviar mensagens de controle e erros na rede.

Na prática, se um salto intermediário mostra 100% de perda de pacotes, mas o salto seguinte e o destino final apresentam zero perda, significa apenas que aquele roteador específico recusou-se a responder às nossas requisições de teste, mas continuou encaminhando os pacotes normalmente. Para ter certeza absoluta de que a falha é real, você deve observar se a perda de pacotes persiste em todos os saltos subsequentes até o destino final. Caso a perda comece em um ponto e continue até o final, temos um gargalo real que precisa de intervenção urgente.

Como usar pacotes TCP para contornar bloqueios de firewall

Muitas redes corporativas modernas e provedores de internet aplicam regras restritivas de firewall que bloqueiam ou limitam severamente o tráfego ICMP, que é o padrão utilizado pelo mtr e pelo traceroute tradicional. Quando isso acontece, os relatórios ficam incompletos ou cheios de asteriscos, dificultando enormemente a análise da rota. Para resolver esse problema, podemos instruir o mtr a utilizar o protocolo TCP ou UDP em vez do ICMP padrão, forçando o tráfego a se parecer com um acesso web comum.

O comando abaixo demonstra como realizar essa variação utilizando a porta 443, que é a porta padrão para tráfego web criptografado via HTTPS e raramente é bloqueada por políticas corporativas de segurança. Assim como analisamos fluxos de dados complexos ao monitorar tráfego HTTP/3 e QUIC no terminal com tshark, forçar o mtr a usar portas específicas revela como o tráfego real da sua aplicação está se comportando na rota.

sudo mtr --tcp --port 443 8.8.8.8

Essa abordagem é extremamente útil para simular conexões reais de clientes que acessam APIs ou servidores em nuvem. Se a rota falhar apenas quando utilizamos o protocolo TCP em portas específicas, sabemos que existe um equipamento de segurança no meio do caminho filtrando pacotes com base em regras de inspeção profunda de conteúdo ou limitação de taxa.

Como exportar relatórios e automatizar o monitoramento de rotas

A interface interativa do mtr é excelente para diagnósticos rápidos e pontuais, mas em ambientes de produção muitas vezes precisamos registrar o comportamento da rede ao longo de várias horas para apresentar relatórios a operadoras de telecomunicações. Para atender a essa necessidade, o mtr possui um modo de relatório que desativa a interatividade visual, envia uma quantidade fixa de pacotes e gera um sumário textual limpo e pronto para ser salvo em arquivos de log.

sudo mtr --report --report-cycles 100 1.1.1.1 > relatorio_rede.txt

Com esse comando, o sistema envia exatamente cem ciclos de testes para o endereço IP especificado e direciona a saída para um arquivo de texto. Dessa forma, você consegue documentar quedas de desempenho intermitentes e cobrar acordos de nível de serviço das operadoras com provas técnicas irrefutáveis. O domínio dessas técnicas eleva drasticamente a capacidade de resposta da equipe de engenharia diante de incidentes críticos de conectividade.

Considerações finais sobre o diagnóstico avançado de redes

O domínio do comando mtr transforma a forma como engenheiros e administradores lidam com incidentes de conectividade, substituindo adivinhações por dados claros e objetivos. Saber separar falsos positivos de perdas reais de pacotes economiza horas preciosas de troubleshooting e evita conflitos desnecessários com provedores de serviços.

Integrar essa rotina de testes ao seu arsenal diário, combinando-a com análises profundas de tráfego e monitoramento de hardware, garante uma infraestrutura de rede muito mais resiliente, estável e preparada para suportar as demandas de sistemas corporativos modernos sem surpresas desagradáveis.