Diagnóstico de rede no MikroTik: ping, traceroute, torch e sniffer (RouterOS 7)

Diagnóstico de rede no MikroTik RouterOS 7: ping com origem e MTU, traceroute, torch para achar quem consome o link e sniffer com Wireshark.

Para que serve

"A internet está lenta", "o RDP no servidor cai", "a VPN não fecha": antes de mexer em configuração, é preciso descobrir onde está o problema. O RouterOS 7 traz ferramentas de diagnóstico de rede no MikroTik que dispensam instalar qualquer coisa: ping e traceroute com escolha de origem, torch para ver em tempo real quem está consumindo o link, sniffer para capturar pacotes e abrir no Wireshark, além do profiler de CPU. Este artigo mostra quando usar cada uma e como interpretar o resultado. Para testes do lado do servidor (mtr, iperf3), veja o artigo «Perda de pacotes e lentidão no servidor: como diagnosticar com mtr, traceroute e iperf3» na categoria de rede.

Pré-requisitos

• Acesso ao terminal do MikroTik (Winbox → New Terminal, ou SSH). Todas as ferramentas também existem no menu Tools do Winbox.
• Exemplos: LAN 192.168.10.0/24 (roteador 192.168.10.1), WAN ether1, túnel wg-datacenter, VM no servidor 10.10.10.30, IP público do servidor 203.0.113.20.

Passo 1: ping com origem, tamanho e contagem

O ping do MikroTik permite escolher de qual endereço o teste sai, algo essencial para VPN e policy routing:

# testa o caminho LAN -> tunel -> VM (sai com o IP da LAN, como um PC faria)
/ping 10.10.10.30 src-address=192.168.10.1 count=20

# testa a internet por uma tabela de rotas especifica (PCC/dois links)
/ping 203.0.113.20 routing-table=via-link2 count=20

# descobre problema de MTU: pacote inteiro, sem fragmentar
/ping 203.0.113.20 size=1500 do-not-fragment count=5
/ping 10.10.10.30 size=1420 do-not-fragment src-address=192.168.10.1 count=5

• No RouterOS, size é o tamanho total do pacote IP. Se size=1500 falha com "packet too large" e size=1492 passa, o link é PPPoE e o túnel/MSS precisa ser ajustado.
• Analise a linha de resumo: packet-loss e a variação entre min-rtt e max-rtt. Perda acima de 1% ou picos frequentes indicam problema no link.
• Ping que funciona do roteador mas não da LAN, com src-address da LAN falhando, aponta para rota de volta ou firewall do outro lado.

Passo 2: traceroute para ver onde o caminho quebra

/tool traceroute 203.0.113.20 use-dns=no count=3
/tool traceroute 10.10.10.30 src-address=192.168.10.1

Cada linha é um salto. Perda que aparece em um salto intermediário e some nos seguintes geralmente é só o roteador da operadora limitando respostas ICMP. Perda que começa num salto e continua até o destino mostra onde está o problema. Se o primeiro salto (gateway da operadora) já tem perda, o problema é o seu link ou o modem.

Passo 3: torch para descobrir quem está usando o link

O torch mostra o tráfego em tempo real agrupado por IP, porta ou protocolo. É a resposta para "quem está derrubando a internet":

# quais IPs da LAN mais consomem (veja as colunas TX/RX)
/tool torch interface=bridge src-address=0.0.0.0/0

# para onde vai o trafego que sai para a internet, por porta
/tool torch interface=ether1 dst-address=0.0.0.0/0 port=any ip-protocol=any

# trafego do tunel com o datacenter
/tool torch interface=wg-datacenter src-address=0.0.0.0/0 dst-address=0.0.0.0/0

O torch enxerga os pacotes antes do firewall, então mostra também o que será descartado: útil para confirmar se um ataque ou varredura está chegando. No Winbox, a janela do torch permite ordenar por taxa com um clique. Quando o tráfego é acelerado pelo FastTrack, ele pode aparecer de forma incompleta; considere isso ao investigar.

Passo 4: sniffer para capturar pacotes

Quando é preciso ver os pacotes em si (handshake do WireGuard, SIP do telefone, resposta de um servidor), use o sniffer.

Visão rápida no terminal

/tool sniffer quick interface=ether1 port=51820
/tool sniffer quick interface=bridge ip-address=192.168.10.55

Para sair, Ctrl+C. Se aparecem pacotes saindo para a porta 51820 do servidor e nenhum voltando, o problema está do lado de lá (firewall da VM WireGuard, porta fechada) ou no caminho.

Gravar em arquivo para abrir no Wireshark

/tool sniffer set filter-interface=ether1 filter-port=5060 filter-ip-protocol=udp \
    file-name=captura-sip.pcap file-limit=10000KiB
/tool sniffer start
# reproduza o problema e depois:
/tool sniffer stop

Baixe o arquivo pela janela Files do Winbox e abra no Wireshark. Apague o arquivo depois: a memória do roteador é pequena.

Enviar a captura ao vivo para o Wireshark

/tool sniffer set streaming-enabled=yes streaming-server=192.168.10.50 filter-interface=ether1 filter-port=3389
/tool sniffer start

No computador 192.168.10.50, abra o Wireshark na placa de rede com o filtro udp port 37008; os pacotes chegam encapsulados em TZSP, que o Wireshark decodifica automaticamente.

Passo 5: conexões, logs, CPU e interfaces

# conexoes ativas de/para um host (confere NAT e se a conexao chega)
/ip firewall connection print where dst-address~"10.10.10.30"

# log em tempo real, filtrando o firewall (regras com log=yes)
/log print follow where topics~"firewall"

# quem esta usando a CPU (10 segundos)
/tool profile duration=10s

# taxa atual e erros fisicos nas interfaces
/interface monitor-traffic ether1,bridge once
/interface ethernet monitor ether1 once
/interface print stats

• No profile, firewall ou networking altos indicam regras demais ou FastTrack desligado; wireguard alto é criptografia de túnel no limite da CPU.
• Em /interface print stats, contadores de rx-error ou fcs-error crescendo indicam cabo, conector ou SFP com defeito. No ethernet monitor, confira se a velocidade negociada é a esperada (por exemplo, 1Gbps full-duplex, e não 100Mbps).

Passo 6: teste de banda entre dois MikroTik

Para medir o túnel entre o escritório e um CHR no datacenter, ligue temporariamente o servidor de bandwidth-test no CHR (lembre que ele fica desligado no hardening):

# no CHR
/tool bandwidth-server set enabled=yes authenticate=yes
# no escritorio
/tool bandwidth-test address=10.8.1.1 user=suporte.ti password=SENHA protocol=tcp direction=both duration=20s
# no CHR, ao terminar
/tool bandwidth-server set enabled=no

O teste consome bastante CPU; em roteadores pequenos, o resultado pode refletir o limite da CPU e não o do link. Para medidas mais precisas, use iperf3 entre duas máquinas.

Como saber se funcionou (roteiro rápido)

1. Ping ao gateway da operadora com perda zero → link local ok.
2. Ping a 203.0.113.20 estável → internet até o datacenter ok.
3. Ping com src-address da LAN até a VM → túnel e rotas ok.
4. Ping com size grande e do-not-fragment → MTU ok.
5. Torch sem um único IP consumindo o link todo → sem gargalo interno.

Problemas comuns

• Ping ao servidor funciona, mas o RDP trava: quase sempre MTU. Teste com do-not-fragment e ajuste o MSS/MTU do túnel.
• Torch não mostra o tráfego esperado: interface errada (use a bridge para a LAN e a WAN para a internet) ou tráfego acelerado por hardware/FastTrack.
• Sniffer não grava nada: filtros conflitantes; teste primeiro com sniffer quick e um único filtro.
• Traceroute para em asteriscos: muitos destinos e firewalls não respondem a traceroute. Isso por si só não indica falha, se o serviço funciona.

Perguntas frequentes

Como ver o consumo por IP no MikroTik?

Com o torch na interface da LAN agrupando por src-address. Para histórico, use o Traffic Flow (NetFlow/IPFIX) enviando para um coletor.

Posso abrir a captura do MikroTik no Wireshark?

Sim. O arquivo gerado pelo sniffer é pcap, e o streaming usa TZSP na porta 37008/udp, que o Wireshark entende.

O que enviar ao suporte num caso de lentidão até o servidor?

A saída do ping com 100 pacotes e do traceroute do MikroTik até o IP do servidor, com data e hora do teste.

Leitura complementar

• MikroTik: Torch
• MikroTik: Packet Sniffer
• MikroTik: Profiler

Precisa de ajuda?

Se os testes apontarem perda ou latência entre o seu link e o servidor dedicado, abra um ticket na Área do Cliente com as saídas de /ping 203.0.113.20 count=100 e /tool traceroute 203.0.113.20 (com o IP real do seu servidor), indicando data e horário.