Capturar pacotes no Mikrotik: sniffer, Torch e Wireshark

Saber capturar pacotes no Mikrotik encurta muito chamado. O cliente diz que o PPPoE não conecta, o NOC jura que o concentrador está de pé, o técnico de campo trocou o roteador duas vezes. Uma captura de trinta segundos mostra se o PADI chegou, se o servidor respondeu e em que ponto a autenticação parou. A discussão acaba ali.
O RouterOS tem três ferramentas para isso: o Torch, que mostra os fluxos de uma interface em tempo real; o Packet Sniffer, que guarda os pacotes em memória ou num arquivo .pcap; e o streaming TZSP, que manda cada pacote capturado para um Wireshark no seu computador. Há ainda a ação sniff-tzsp no mangle, que copia só o tráfego que casar com uma regra de firewall.
Os exemplos foram montados em laboratório com RouterOS v7, seguindo a documentação oficial da MikroTik. O cenário: ether1 é o uplink, vlan100 recebe os clientes PPPoE, bridge-lan (192.0.2.1/24) atende clientes DHCP e o PC com Wireshark está em 198.51.100.50, na rede do NOC.
Resposta rápida: qual ferramenta usar para capturar pacotes no Mikrotik
| Ferramenta | Use quando | Saída |
|---|---|---|
| Torch | Quer ver agora quem está usando a interface, qual porta, quanto tráfego | Tabela de fluxos ao vivo, sem conteúdo dos pacotes |
/tool sniffer quick | Quer confirmar se um pacote passa (DHCP, ICMP) sem sair do terminal | Lista de pacotes no terminal |
Sniffer com file-name | Precisa analisar com calma ou mandar a captura para alguém | Arquivo .pcap no roteador |
| Streaming TZSP | Quer ver os pacotes no Wireshark enquanto o problema acontece | Pacotes ao vivo no PC, em UDP 37008 |
Mangle sniff-tzsp | Precisa de um filtro que o sniffer não tem (address-list, connection-state, mark) | Pacotes ao vivo no PC, só o que casou |
Com o Torch ou o sniffer rodando, o RouterOS desliga o fast path do IPv4 e, com ele, o FastTrack. Num roteador carregado isso sobe a CPU. Filtre bem e capture por pouco tempo.
Torch: a visão rápida antes de capturar pacotes no Mikrotik
O Torch não grava pacote nenhum. Ele agrupa o tráfego de uma interface em fluxos (endereços, protocolo, portas, DSCP) e mostra a taxa de cada um em tempo real. É o primeiro passo quando a pergunta é quem está consumindo o link ou se um tipo de tráfego aparece na interface:
/tool torch ether1 /tool torch ether1 ip-protocol=udp port=53 /tool torch bridge-lan src-address=192.0.2.21/32 duration=30s
- A primeira linha lista todos os fluxos do uplink, com TX e RX de cada um.
- A segunda restringe a UDP 53: útil para ver se os clientes estão consultando o seu DNS ou um de fora, e se tem alguém fazendo volume anormal de consultas.
- A terceira foca um cliente da LAN e para sozinha depois de 30 segundos com
duration.
O Torch enxerga o pacote recebido antes do firewall. Um tráfego que uma regra descarta continua aparecendo na interface de entrada, o que é bom para provar que o pacote chegou. O lado ruim: tráfego encaminhado em hardware (bridge com offload ou roteamento L3 em hardware nos switches CRS) não passa pela CPU e não aparece. Na mesma interface, o sniffer tem a mesma limitação.
Packet Sniffer: capturar pacotes no Mikrotik pelo terminal
O /tool sniffer é a ferramenta principal para capturar pacotes no Mikrotik. Ele tem dois modos. O quick imprime os pacotes no terminal enquanto roda e serve para confirmações simples:
/tool sniffer quick interface=bridge-lan port=bootps,bootpc duration=20s /tool sniffer quick interface=ether1 ip-protocol=icmp
A primeira linha mostra por 20 segundos a troca DHCP na bridge (portas 67 e 68, que o RouterOS chama de bootps e bootpc). Se aparece o Discover do cliente e não aparece o Offer, o problema está no servidor ou no pool; se nem o Discover aparece, o problema está antes do roteador. A segunda mostra ICMP no uplink, para confirmar se um ping sai e volta.
Gravar em arquivo: o caso do PPPoE
Para análise de verdade, grave em arquivo. As propriedades começadas por filter- ficam salvas na configuração do sniffer e valem para o próximo start. O exemplo captura a descoberta e a sessão PPPoE na VLAN de acesso:
/tool sniffer set filter-interface=vlan100 /tool sniffer set filter-mac-protocol=pppoe-discovery,pppoe /tool sniffer set file-name=pppoe.pcap file-limit=10000KiB /tool sniffer start /tool sniffer stop /file print where name~"pppoe"
Linha por linha: a interface é a VLAN onde chegam os clientes; pppoe-discovery pega PADI, PADO, PADR e PADS, e pppoe pega a sessão (LCP, autenticação PAP ou CHAP, IPCP). O file-limit é em KiB e o padrão é 1000 KiB; 10000 KiB dá uns 10 MB, e o valor não pode passar da memória livre. Entre o start e o stop, peça para o cliente desligar e ligar o roteador. O /file print confirma que o arquivo existe.
Baixe o arquivo pelo menu Files do WinBox ou por SCP, a partir do PC:
scp op.noc@198.51.100.1:pppoe.pcap .
No Wireshark, o filtro de exibição pppoed mostra a descoberta e pap || chap a autenticação. PADI sem PADO quer dizer que o concentrador não respondeu (serviço, VLAN ou interface errada); PADS seguido de falha no CHAP é usuário ou senha. O passo a passo do servidor está no guia de PPPoE server no Mikrotik RouterOS v7.
Filtros do sniffer e o operador entre eles
O jeito mais simples de limitar a captura é passar interface e endereço direto no start, como mostra a documentação. O exemplo grava todo o tráfego de um cliente da LAN e, depois do stop, usa os resumos que o próprio RouterOS monta:
/tool sniffer print /tool sniffer set file-name=dns-cliente.pcap file-limit=10000KiB /tool sniffer start interface=bridge-lan ip-address=192.0.2.21/32 /tool sniffer stop /tool sniffer packet print /tool sniffer protocol print /tool sniffer host print
O print no começo mostra a configuração gravada. Com parâmetros no start, só valem os filtros passados ali, e os gravados ficam de fora nessa rodada; num start sem parâmetros valem os gravados, e um filter-interface esquecido faz a captura sair vazia.
O packet print lista os pacotes guardados, o protocol print resume por protocolo e o host print por endereço. Se o cliente reclama de DNS, abra o arquivo e filtre por dns: consulta sem resposta aponta para o resolvedor, e o lado do servidor está no post sobre DNS recursivo com Unbound.
O detalhe do filter-operator-between-entries
Filtros de tipos diferentes sempre se combinam como E: com endereço e porta preenchidos, o sniffer só grava o pacote que casa com os dois. A primeira linha abaixo já pega só o DNS daquele cliente.
O filter-operator-between-entries vale para as várias entradas de um mesmo filtro. No padrão or, filter-ip-address com dois endereços grava o tráfego de qualquer um deles; com and, o pacote precisa casar com os dois, o que isola a conversa entre o cliente e o roteador (192.0.2.1), ainda limitada à porta 53:
/tool sniffer set filter-ip-address=192.0.2.21/32 filter-port=53 /tool sniffer set filter-ip-address=192.0.2.21/32,192.0.2.1/32 /tool sniffer set filter-operator-between-entries=and
O erro mais comum de quem começa a capturar pacotes no Mikrotik é capturar sem filtro nenhum: o arquivo enche em segundos com tráfego que não interessa, e a captura que importava é cortada pelo file-limit.
| Filtro | Formato | Exemplo |
|---|---|---|
| filter-interface | nome ou all | vlan100 |
| filter-ip-address | ip/máscara, até 16 | 192.0.2.21/32 |
| filter-port | [!]porta, até 16 | 53 ou !22 |
| filter-ip-protocol | [!]protocolo | udp, icmp |
| filter-mac-protocol | [!]protocolo | pppoe-discovery, arp |
| filter-direction | any, rx ou tx | rx |
| filter-vlan | ID de 0 a 4095 | 100 |
| filter-size | faixa de tamanho | 1400-1500 |
Existem as variantes src e dst para endereço e porta e as versões IPv6 e MAC de cada filtro. O filter-direction ajuda a separar o que entrou do que saiu: em rx o pacote é visto antes do firewall, em tx depois.
Streaming TZSP: capturar pacotes no Mikrotik direto no Wireshark
Quando o problema é intermitente, ficar baixando arquivo cansa. O streaming manda cada pacote capturado para o PC encapsulado em TZSP, um protocolo simples sobre UDP, na porta 37008 por padrão. No roteador:
/tool sniffer set streaming-enabled=yes streaming-server=198.51.100.50 /tool sniffer set filter-stream=yes /tool sniffer start interface=ether1 /tool sniffer stop /tool sniffer set streaming-enabled=no
streaming-server é o IP do PC que vai receber (só IPv4). O filter-stream=yes é o padrão e faz o sniffer ignorar os próprios pacotes TZSP; sem ele, se o caminho até o PC passa pela interface capturada, o roteador captura o que acabou de enviar e entra em laço. A última linha desliga o streaming depois do teste, para ninguém esquecer o roteador mandando tráfego para o NOC.

No PC, libere a porta 37008 vinda do roteador e capture nela. O Wireshark reconhece o TZSP nessa porta e mostra o pacote original por dentro, então o filtro de exibição é o de sempre (dns, dhcp, pppoed). Pela linha de comando, com tshark:
sudo ufw allow from 198.51.100.1 to any port 37008 proto udp sudo tshark -i eth0 -f "udp port 37008" -Y "dns" sudo tshark -i eth0 -f "udp port 37008" -w /tmp/captura.pcapng
O -f é o filtro de captura (só o UDP do TZSP), o -Y é o filtro de exibição aplicado ao pacote de dentro, e o -w grava tudo para abrir depois no Wireshark. No Windows, rode o Wireshark como administrador, escolha a placa que recebe do roteador e use udp port 37008 como filtro de captura.
Se o PC estiver em outra rede, confira o firewall do roteador e o do caminho. E se você seguiu o hardening do post de segurança no Mikrotik RouterOS v7, lembre que a regra de saída do NOC precisa permitir esse UDP.
Mangle com sniff-tzsp: capturar só o que interessa
O sniffer filtra por interface, endereço, porta e protocolo. Quando você precisa de algo que só o firewall sabe (uma address-list, um connection-mark, o estado da conexão), use a ação sniff-tzsp no mangle, a forma mais seletiva de capturar pacotes no Mikrotik. Ela manda uma cópia do pacote para o Wireshark e deixa o original seguir para a próxima regra, como um passthrough:
/ip firewall mangle add chain=prerouting src-address=192.0.2.21 action=sniff-tzsp sniff-target=198.51.100.50 sniff-target-port=37008 comment=captura /ip firewall mangle add chain=postrouting dst-address=192.0.2.21 action=sniff-tzsp sniff-target=198.51.100.50 sniff-target-port=37008 comment=captura /ip firewall mangle print where comment=captura /ip firewall mangle remove [find comment=captura]
A regra em prerouting pega o que o cliente envia e a de postrouting o que chega para ele. O comment=captura serve para listar e apagar as duas de uma vez no fim. Troque o src-address por src-address-list para acompanhar um grupo de clientes, por exemplo os que apareceram numa notificação do CERT.br (veja o post sobre portas de amplificação DDoS).
Em roteador com CGNAT, a captura no prerouting da interface do cliente mostra o IP privado, e no uplink já aparece o público; o mapeamento entre os dois está no post sobre CGNAT no Mikrotik com netmap. Escolha o ponto de captura de acordo com o endereço que você tem em mãos.
Cuidado com a CPU durante a captura
Toda forma de capturar pacotes no Mikrotik passa pela CPU. Enquanto o sniffer ou o Torch rodam, o RouterOS desliga o fast path do IPv4 e o FastTrack, e o tráfego encaminhado que antes era acelerado passa a ser processado pacote a pacote. Num concentrador com milhares de sessões, isso pode subir bastante o uso de CPU.
Acompanhe a carga numa segunda sessão enquanto captura:
/system resource print /tool profile
- Capture com filtro: interface, endereço e protocolo. Sem filtro no uplink, o streaming gera tanto tráfego quanto o próprio link.
- Use
durationno quick e no Torch, e pare o sniffer assim que tiver o que precisa. - Prefira
only-headers=yesquando o conteúdo não importa: cabe muito mais no arquivo. - O
memory-limitpadrão é 100 KiB; aumente com moderação e só para capturas curtas em memória. - Evite capturar no horário de pico em roteador que já trabalha acima de 60% de CPU.
Casos práticos para capturar pacotes no Mikrotik no provedor
| Sintoma | Onde capturar | O que procurar |
|---|---|---|
| PPPoE não conecta | VLAN de acesso, pppoe-discovery,pppoe | PADI sem PADO (serviço ou VLAN); falha no CHAP (usuário ou senha); LCP que não fecha (MTU) |
| Cliente sem IP no DHCP | Bridge ou VLAN da LAN, portas bootps e bootpc | Discover sem Offer (pool cheio, servidor desligado); Offer sem Request (cliente não aceitou) |
| Site não abre, ping funciona | Interface do cliente, filtro no IP dele | Consulta DNS sem resposta; TCP SYN sem SYN-ACK; pacote grande sem resposta (MTU) |
| Link cheio sem explicação | Torch no uplink | Fluxo dominante, porta incomum, muitos destinos a partir de um só IP |
| Suspeita de ataque saindo de cliente | Mangle sniff-tzsp com address-list | UDP grande saindo de portas de serviço; muitos SYN para destinos aleatórios |
Nos casos de MTU, olhe o tamanho dos pacotes que somem: em PPPoE o MTU padrão é 1480 ou 1492, e um pacote de 1500 sem fragmentação nem MSS ajustado simplesmente não passa. O filtro filter-size ajuda a isolar só os pacotes grandes.
Erros comuns ao capturar pacotes no Mikrotik
- Capturar na interface errada. Na bridge com hardware offload, o tráfego entre portas não passa pela CPU. Capture na VLAN ou na interface roteada.
- Confundir o operador. O
filter-operator-between-entriesvale entre as entradas de um mesmo filtro; filtros diferentes já se somam como E. - Filtros antigos gravados. Os
filter-ficam salvos e valem em todostartsem parâmetros. Rode/tool sniffer printantes de cada captura. - Streaming sem liberar a porta. O firewall do PC descarta o UDP 37008 e o Wireshark fica vazio, mesmo com o roteador enviando.
- Deixar o streaming ligado. Desligue com
streaming-enabled=noe apague as regras de mangle de captura. - Achar que a captura vê tudo. Tráfego cifrado (HTTPS, VPN) aparece só com cabeçalhos úteis; o conteúdo não se lê.
Perguntas frequentes
Qual a diferença entre Torch e Packet Sniffer?
O Torch mostra fluxos e taxas em tempo real, sem guardar os pacotes. O sniffer guarda os pacotes, em memória ou em arquivo, e permite abrir cada um no Wireshark. Use o Torch para achar o fluxo e o sniffer para entender o que acontece nele.
Como capturar pacotes no Mikrotik e abrir no Wireshark?
Configure file-name no /tool sniffer, rode start e stop, e baixe o arquivo pelo Files do WinBox ou por SCP. Para ver ao vivo, ligue o streaming com o IP do PC e capture UDP 37008 no Wireshark.
Por que o sniffer não mostra o tráfego entre portas da bridge?
Porque, com hardware offload, o switch encaminha esse tráfego sem passar pela CPU. Capture numa interface roteada, numa VLAN que termina no roteador ou desligue o offload só durante o teste.
Capturar pacotes derruba o desempenho do roteador?
Enquanto a captura roda, o RouterOS desliga o fast path e o FastTrack, e a CPU sobe. Com filtros bem feitos e captura curta, o impacto costuma ser pequeno; sem filtro no uplink de um concentrador, não.
O streaming TZSP funciona com IPv6?
Na documentação, o streaming-server recebe um endereço IPv4. Os pacotes capturados podem ser IPv6, o que precisa ser IPv4 é o destino do TZSP.
Conclusão
Para capturar pacotes no Mikrotik, comece pelo Torch para achar o fluxo, use o quick para confirmar a hipótese e grave um .pcap ou ligue o streaming quando precisar ver o protocolo por dentro. Filtre por interface, endereço e porta, que se combinam entre si, e capture pelo menor tempo possível.
Com o hábito, a captura vira a primeira ferramenta do chamado difícil: em vez de opinião sobre onde está o problema, você tem o pacote que chegou e o que não voltou.
Leitura recomendada: Como capturar pacotes no Mikrotik, da wiki do Brasil Peering Forum (CC BY-NC 4.0), com o passo a passo pelas abas do WinBox.
