Mikrotik

Capturar pacotes no Mikrotik: sniffer, Torch e Wireshark

Onda de pacotes azuis passando por uma lupa amarela, representando a captura de pacotes no Mikrotik

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

FerramentaUse quandoSaída
TorchQuer ver agora quem está usando a interface, qual porta, quanto tráfegoTabela de fluxos ao vivo, sem conteúdo dos pacotes
/tool sniffer quickQuer confirmar se um pacote passa (DHCP, ICMP) sem sair do terminalLista de pacotes no terminal
Sniffer com file-namePrecisa analisar com calma ou mandar a captura para alguémArquivo .pcap no roteador
Streaming TZSPQuer ver os pacotes no Wireshark enquanto o problema acontecePacotes ao vivo no PC, em UDP 37008
Mangle sniff-tzspPrecisa 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.

A partir do RouterOS 7.20 o arquivo sai em formato PCAPNG, mesmo com a extensão .pcap. O Wireshark abre normalmente; algumas ferramentas antigas que só leem pcap clássico não.

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.

FiltroFormatoExemplo
filter-interfacenome ou allvlan100
filter-ip-addressip/máscara, até 16192.0.2.21/32
filter-port[!]porta, até 1653 ou !22
filter-ip-protocol[!]protocoloudp, icmp
filter-mac-protocol[!]protocolopppoe-discovery, arp
filter-directionany, rx ou txrx
filter-vlanID de 0 a 4095100
filter-sizefaixa de tamanho1400-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.

Roteador Mikrotik enviando pacotes capturados por TZSP para um PC com Wireshark
O sniffer copia os pacotes da interface e os envia em UDP 37008 para o PC do NOC; a alternativa é gravar um .pcap no roteador e baixar depois.

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).

Conexões que passam pelo FastTrack não atravessam o mangle. Se a regra não manda nada, verifique se o tráfego do cliente está sendo acelerado e, durante o teste, crie uma exceção para ele antes da regra de FastTrack.

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 duration no quick e no Torch, e pare o sniffer assim que tiver o que precisa.
  • Prefira only-headers=yes quando o conteúdo não importa: cabe muito mais no arquivo.
  • O memory-limit padrã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

SintomaOnde capturarO que procurar
PPPoE não conectaVLAN de acesso, pppoe-discovery,pppoePADI sem PADO (serviço ou VLAN); falha no CHAP (usuário ou senha); LCP que não fecha (MTU)
Cliente sem IP no DHCPBridge ou VLAN da LAN, portas bootps e bootpcDiscover sem Offer (pool cheio, servidor desligado); Offer sem Request (cliente não aceitou)
Site não abre, ping funcionaInterface do cliente, filtro no IP deleConsulta DNS sem resposta; TCP SYN sem SYN-ACK; pacote grande sem resposta (MTU)
Link cheio sem explicaçãoTorch no uplinkFluxo dominante, porta incomum, muitos destinos a partir de um só IP
Suspeita de ataque saindo de clienteMangle sniff-tzsp com address-listUDP 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-entries vale entre as entradas de um mesmo filtro; filtros diferentes já se somam como E.
  • Filtros antigos gravados. Os filter- ficam salvos e valem em todo start sem parâmetros. Rode /tool sniffer print antes 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=no e 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.

Compartilhar:

Sobre o autor

Ivan Alves

Especialista em redes de provedores (ISP)

Ivan Alves trabalha há mais de 15 anos com redes de provedores de internet, do NOC ao backbone e à borda BGP. Coordena infraestrutura e tecnologia em um provedor regional e escreve aqui os tutoriais que gostaria de ter encontrado quando começou: comandos testados, cenário explicado e o porquê de cada linha.

Deixe um comentário

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