mikrotik-wiki.ru
Главная
Загрузка...

Torch на MikroTik — анализ трафика в реальном времени

RouterOS 7.xTools4 мин130 мар. 2026 г.
TelegramVK

Torch (Traffic Observer) — встроенный инструмент RouterOS для просмотра трафика, проходящего через интерфейс, в реальном времени. В отличие от счётчиков firewall или SNMP-графиков, Torch показывает живую картину: кто, куда, по какому протоколу и сколько трафика генерирует прямо сейчас. Это незаменимый инструмент для оперативной диагностики: найти, кто "съедает" канал, обнаружить подозрительный трафик или проверить, работает ли NAT-правило.

Описание

Что показывает Torch

Torch перехватывает пакеты на указанном интерфейсе и группирует их по выбранным критериям. Для каждой группы отображаются:

  • Tx/Rx Rate — скорость отправки и приёма в данный момент (бит/с или пакет/с)
  • Tx/Rx Packets — количество пакетов
  • Source Address — IP-адрес источника
  • Destination Address — IP-адрес назначения
  • Protocol — протокол (TCP, UDP, ICMP и т.д.)
  • Port — порт источника или назначения

Torch работает на уровне интерфейса — он видит трафик до и после обработки firewall (в зависимости от того, на каком интерфейсе запущен). Это позволяет проверять, доходит ли трафик до определённого интерфейса, и в каком виде.

Torch vs Packet Sniffer

ХарактеристикаTorchPacket Sniffer (/tool/sniffer)
НазначениеСтатистика в реальном времениЗахват пакетов для анализа
Нагрузка на CPUНизкаяВысокая (особенно при записи)
РезультатАгрегированные данные (rate, bytes)Полный дамп пакетов (pcap)
АнализПрямо на роутереЭкспорт в Wireshark
Применение"Кто ест канал?""Почему не проходит пакет?"

Torch — для быстрой диагностики, Packet Sniffer — для глубокого анализа.

Настройка

Базовый запуск Torch

Простейший вариант — наблюдать весь трафик на интерфейсе:

[admin@MikroTik] >
/tool/torch interface=ether1

Команда покажет поток данных в реальном времени. Для остановки нажмите Ctrl+C.

Фильтрация по адресам и портам

Torch поддерживает фильтры для сужения результатов:

[admin@MikroTik] >
# Трафик только от конкретного хоста
/tool/torch interface=bridge-LAN src-address=192.168.88.100/32

# Трафик только к конкретному назначению
/tool/torch interface=ether1 dst-address=8.8.8.8/32

# Только HTTP и HTTPS трафик
/tool/torch interface=ether1 port=80,443

# Только UDP-трафик (DNS, VoIP, игры)
/tool/torch interface=bridge-LAN protocol=udp

# Комбинация фильтров: UDP от конкретного хоста
/tool/torch interface=bridge-LAN \
  src-address=192.168.88.50/32 protocol=udp

Выбор группировки

По умолчанию Torch группирует трафик по src-address и dst-address. Можно изменить критерии группировки:

[admin@MikroTik] >
# Группировка по source-адресу — кто генерирует трафик
/tool/torch interface=bridge-LAN src-address=0.0.0.0/0

# Группировка по dst-port — какие сервисы используются
/tool/torch interface=ether1 port=any protocol=tcp

# Группировка по протоколу
/tool/torch interface=ether1 protocol=any

Ограничение по времени

Для автоматического завершения Torch (полезно в скриптах):

[admin@MikroTik] >
/tool/torch interface=ether1 duration=30s

Проверка

Кто потребляет полосу

Самый частый сценарий — интернет "тормозит" и нужно быстро найти виновника:

[admin@MikroTik] >
# Смотрим трафик на WAN-интерфейсе, группируя по LAN-адресам
/tool/torch interface=bridge-LAN src-address=0.0.0.0/0

В выводе ищем строку с наибольшим Tx/Rx Rate — это устройство потребляет больше всего трафика.

Проверка NAT и Firewall

Torch помогает проверить, доходит ли трафик до нужного интерфейса после NAT:

[admin@MikroTik] >
# На WAN-интерфейсе: проверяем, что dst-nat перенаправляет трафик
/tool/torch interface=ether1 dst-port=80 protocol=tcp

# На LAN-интерфейсе: проверяем, что перенаправленный трафик дошёл
/tool/torch interface=bridge-LAN dst-address=192.168.88.100/32 dst-port=80

Если на WAN видим трафик, а на LAN — нет, значит правило dst-nat или firewall-filter блокирует пакеты.

Обнаружение подозрительного трафика

[admin@MikroTik] >
# Поиск нестандартных протоколов
/tool/torch interface=ether1 protocol=any

# Поиск трафика на нестандартных портах
/tool/torch interface=bridge-LAN port=any protocol=tcp

# Поиск UDP-флуда (DDoS, DNS amplification)
/tool/torch interface=ether1 protocol=udp

Большой объём трафика на порт 53 (DNS) от внешних адресов может указывать на DNS amplification атаку. Большой UDP-поток на случайных портах — возможный DDoS.

Проверка VPN-туннелей

[admin@MikroTik] >
# Трафик внутри WireGuard-туннеля
/tool/torch interface=wireguard1

# Трафик внутри L2TP-туннеля
/tool/torch interface=<l2tp-connection-name>

Если Torch на VPN-интерфейсе не показывает трафика, но на LAN-интерфейсе он есть — проблема в маршрутизации: трафик не попадает в туннель.

Torch в WinBox

В графическом интерфейсе WinBox Torch доступен через меню Tools > Torch. Преимущества WinBox-версии:

  • Удобная сортировка по столбцам (клик на заголовок)
  • Визуальное выделение потоков с высокой скоростью
  • Возможность быстро менять фильтры без перезапуска
  • Автоматическое обновление каждые 1-2 секунды

Для серверов без GUI используйте CLI-версию, описанную выше.

Типичные ошибки

  1. Torch на неправильном интерфейсе — запустили Torch на ether1 (WAN), а ищем LAN-трафик. Torch показывает пакеты только на указанном интерфейсе. Для анализа клиентского трафика используйте bridge-LAN, для анализа исходящего — WAN-интерфейс

  2. Torch "не видит" трафик после hardware offloading — если bridge использует hardware offloading, трафик между портами коммутируется на аппаратном уровне и не проходит через CPU. Torch не увидит этот трафик. Временное решение для диагностики: отключить hw offloading на нужных портах

  3. Высокая нагрузка CPU при длительной работе — Torch создаёт нагрузку на CPU, особенно на загруженных интерфейсах. Не оставляйте Torch включённым на продакшн-роутере на длительное время. Используйте фильтры для сужения анализируемого трафика

  4. Путаница с NAT-адресами — на WAN-интерфейсе Torch показывает src-address уже после NAT-трансляции (публичный IP роутера). Чтобы увидеть оригинальный LAN-адрес источника, запускайте Torch на bridge-LAN

  5. Забыли указать protocol при фильтре по порту — фильтр port= без указания protocol= может не дать результатов. Всегда указывайте protocol=tcp или protocol=udp вместе с port=

[admin@MikroTik] >
/tool/torch interface=ether1
# Трафик только от конкретного хоста
/tool/torch interface=bridge-LAN src-address=192.168.88.100/32

# Трафик только к конкретному назначению
/tool/torch interface=ether1 dst-address=8.8.8.8/32

# Только HTTP и HTTPS трафик
/tool/torch interface=ether1 port=80,443

# Только UDP-трафик (DNS, VoIP, игры)
/tool/torch interface=bridge-LAN protocol=udp

# Комбинация фильтров: UDP от конкретного хоста
/tool/torch interface=bridge-LAN \
  src-address=192.168.88.50/32 protocol=udp
# Группировка по source-адресу — кто генерирует трафик
/tool/torch interface=bridge-LAN src-address=0.0.0.0/0

# Группировка по dst-port — какие сервисы используются
/tool/torch interface=ether1 port=any protocol=tcp

# Группировка по протоколу
/tool/torch interface=ether1 protocol=any
/tool/torch interface=ether1 duration=30s
# Смотрим трафик на WAN-интерфейсе, группируя по LAN-адресам
/tool/torch interface=bridge-LAN src-address=0.0.0.0/0
# На WAN-интерфейсе: проверяем, что dst-nat перенаправляет трафик
/tool/torch interface=ether1 dst-port=80 protocol=tcp

# На LAN-интерфейсе: проверяем, что перенаправленный трафик дошёл
/tool/torch interface=bridge-LAN dst-address=192.168.88.100/32 dst-port=80
# Поиск нестандартных протоколов
/tool/torch interface=ether1 protocol=any

# Поиск трафика на нестандартных портах
/tool/torch interface=bridge-LAN port=any protocol=tcp

# Поиск UDP-флуда (DDoS, DNS amplification)
/tool/torch interface=ether1 protocol=udp
# Трафик внутри WireGuard-туннеля
/tool/torch interface=wireguard1

# Трафик внутри L2TP-туннеля
/tool/torch interface=<l2tp-connection-name>
Tools / Torch на MikroTik — анализ трафика в реальном времени