MikroTik с нуля 08. Диагностика и мониторинг

Когда «интернет тормозит» или «что-то не работает», настройки уже не помогут: нужны инструменты, которые показывают, что происходит на самом деле. В RouterOS их немало, и почти все встроены в систему. В этой статье вы познакомитесь с набором для повседневных задач: проверка связности (ping, traceroute), поиск того, кто занял канал (Torch), захват пакетов (Packet Sniffer), замер скорости между двумя роутерами, оповещения о недоступности узлов (Netwatch), контроль загрузки и температуры, журнал событий, SNMP для систем мониторинга и встроенные графики.

В конце вы получите схему, по которой удобно искать причину любой сетевой проблемы: канал → адрес и шлюз → DNS → NAT → firewall → MTU.

Что понадобится

• Роутер MikroTik с RouterOS 7, настроенный по статьям 01–04 серии: порт ether1 к провайдеру, мост bridge с адресом 192.168.88.1/24.
• Доступ к консоли (SSH, WinBox или WebFig). Как работает командная строка и Safe Mode, описано в статье 02.
• Для проверки скорости между роутерами — второй MikroTik (в примерах это роутер удалённого офиса 192.168.89.1, подключённый по туннелю из статьи 11).
• По желанию — сервер в локальной сети (в примерах 192.168.88.10) для журнала syslog (стандартного протокола пересылки журналов на отдельный сервер) и системы мониторинга, например Zabbix.

Ping и traceroute: проверка связности

ping отвечает на вопрос «доходит ли пакет до узла и как быстро». Начните с ближайшего: шлюза провайдера, потом внешнего узла.

/ping 203.0.113.1 count=5
/ping 192.0.2.80 count=5

Адрес 192.0.2.80 в примерах означает «любой надёжный внешний узел» (в серии он закреплён за этой ролью): подставьте адрес, который вы знаете как всегда доступный. Без count пинг идёт, пока вы не нажмёте Ctrl+C. В итоговой строке смотрите на packet-loss и время ответа (avg-rtt).

ping работает по протоколу ICMP (Internet Control Message Protocol), служебному протоколу для проверок и сообщений об ошибках. Колонка STATUS объясняет, что случилось с запросом:

Статус	Что означает
(пусто)	Нормальный ответ
timeout	Ответа нет: узел выключен, не отвечает на ICMP или пакет где-то отброшен
net unreachable, host unreachable	Роутер из колонки HOST не знает, как дойти до сети или узла (или firewall отвечает отказом)
TTL exceeded	Исчерпан TTL (Time To Live, «время жизни» пакета: каждый роутер на пути уменьшает его на единицу, а при нуле пакет отбрасывается). Обычно это петля маршрутизации: пакет «ходит по кругу»
fragmentation needed and DF set	На пути есть звено с меньшим MTU (Maximum Transmission Unit, максимальный размер пакета; см. раздел про MTU ниже)

Выбор интерфейса и адреса источника

По умолчанию роутер сам выбирает, с какого адреса отправить запрос. Но проверять часто нужно «глазами» конкретной сети. Параметр src-address отправляет пинг от имени нужного адреса, interface задаёт интерфейс выхода:

/ping 192.0.2.80 src-address=192.168.88.1 count=3
/ping 192.0.2.80 src-address=203.0.113.2 count=3
/ping 192.0.2.80 interface=ether1 count=3

Первая команда показывает, как выглядит путь для адреса из локальной сети, вторая — для адреса на стороне провайдера. Если одна работает, а другая нет, проблема в NAT, политике маршрутизации или firewall, а не в самом канале.

Две оговорки. Во-первых, пинг, который роутер шлёт сам, проходит цепочки output и srcnat, но не forward: он не проверяет правила транзита и не доказывает, что NAT работает для компьютеров LAN. Для полной проверки пингуйте с реального компьютера или сверяйте счётчики правил forward и NAT (см. схему в конце статьи). Во-вторых, interface=ether1 задаёт только интерфейс выхода. Если через этот интерфейс нет маршрута, покрывающего адрес назначения, роутер считает его непосредственно подключённым и вместо шлюза будет слать ARP-запросы на сам адрес, поэтому ответа не будет.

Узел не отвечает на ping — он точно выключен?

Многие компьютеры по умолчанию режут ICMP, поэтому timeout не значит «выключен». Для узлов в той же подсети есть ARP-ping: ARP (Address Resolution Protocol) сопоставляет IP-адреса и MAC-адреса в локальной сети, и на него обязан отвечать любой работающий узел.

/ping 192.168.88.10 arp-ping=yes interface=bridge count=2

В колонке HOST вместо IP вы увидите MAC-адрес ответившего устройства. Если ответ есть, узел жив, просто закрыт для ICMP.

Traceroute: где обрывается путь

traceroute показывает все роутеры на пути и статистику по каждому из них:

/tool traceroute 192.0.2.80 count=3
/tool traceroute 192.0.2.80 src-address=192.168.88.1 count=3 use-dns=yes

Как читать результат:

• Первые узлы отвечают, дальше пустые строки с 100% потерь: проблема после последнего ответившего узла (обрыв линка, нет маршрута, пакеты режутся или нет обратного маршрута).
• Одни и те же два адреса чередуются: петля маршрутизации.
• Потери на одном промежуточном узле, а на следующих их нет: это не потери на пути. Многие маршрутизаторы просто не любят отвечать на служебные запросы. Настоящие потери начинаются на одном узле и сохраняются на всех следующих.
• В колонке STATUS появляется host unreachable from ... или packet filtered from ...: указанный узел отказывает в доставке, возможно из-за правила firewall с reject.

Кто грузит канал: Torch и monitor-traffic

Начните с самого дешёвого инструмента — счётчиков интерфейса. Они показывают текущую скорость в обоих направлениях:

/interface monitor-traffic ether1
/interface monitor-traffic [find]

Команда обновляется каждую секунду, остановить её можно через Ctrl+C. Если нужна одна строка и возврат в консоль, добавьте once: в справочнике этих команд аргумент не описан, но в примерах документации RouterOS (/interface monitor-traffic ether1 once, /interface ethernet monitor ether1 once) он используется. Если rx-bits-per-second на ether1 упирается в тариф, канал занят. Но кем? Это показывает Torch:

/tool torch interface=bridge duration=10s

Torch группирует трафик в потоки (адреса, протокол, порты) и показывает скорость каждого. Ключевое правило: смотрите на LAN-интерфейс, не на WAN. После NAT на WAN все потоки идут с адреса роутера, и вы не узнаете, кто именно качает.

Как читать столбцы на интерфейсе bridge:

• SRC-ADDRESS — это узел «по ту сторону» интерфейса, то есть локальный компьютер;
• TX — то, что роутер отправляет этому компьютеру (его скачивание);
• RX — то, что роутер получает от него (его отдача).

Чтобы сузить выдачу, добавьте фильтры:

/tool torch interface=bridge src-address=192.168.88.20/32 duration=10s
/tool torch interface=bridge ip-protocol=tcp port=443 duration=10s

Параметр port принимает один порт или any; список через запятую не работает.

Как проверить: запустите на компьютере в локальной сети скачивание большого файла и выполните Torch на bridge с фильтром по его адресу. В строке потока вы увидите скорость в колонке TX, примерно равную скорости скачивания.

Packet Sniffer: что на самом деле пришло в пакетах

Sniffer нужен, когда надо увидеть сами пакеты: пришёл ли запрос, был ли ответ, что за протокол. Он видит принятые пакеты до firewall и NAT, а отправленные — после них. Пакеты, которые мост пересылает между портами аппаратно (hardware offload), до процессора не доходят и в захват не попадают, как и в Torch.

Всегда ставьте фильтр по интерфейсу и адресу. Захват для компьютера 192.168.88.20 в локальной сети состоит из трёх отдельных шагов. Сначала запустите захват:

/tool sniffer start interface=bridge ip-address=192.168.88.20/32

Теперь воспроизведите проблему (например, откройте проблемный сайт на этом компьютере) и сразу остановите захват:

/tool sniffer stop

После остановки пакеты остаются в памяти роутера около 10 минут (или до следующего запуска). За это время сохраните их в файл:

/tool sniffer save file-name=capture.pcap

Захватывайте на стороне LAN: на ether1 источником уже будет адрес роутера. Файл capture.pcap скачайте через раздел Files в WinBox или WebFig и откройте в Wireshark (бесплатная программа для разбора сетевых пакетов). По умолчанию sniffer хранит всего 100 КиБ последних пакетов, и новые вытесняют старые, поэтому останавливайте захват сразу после проявления проблемы. Для просмотра в консоли есть /tool sniffer packet print, /tool sniffer host print и /tool sniffer protocol print.

Быстрый просмотр в консоли без сохранения, например DHCP-обмен на порту к провайдеру:

/tool sniffer quick interface=ether1 port=bootps,bootpc duration=10s proplist=time,dir,src-address,dst-address,size

Метка <- означает полученный пакет, -> — отправленный.

Если нужно смотреть пакеты в Wireshark «вживую», sniffer умеет отправлять их на компьютер по протоколу TZSP (протокол пересылки захваченных пакетов):

/tool sniffer set streaming-enabled=yes streaming-server=192.168.88.10 filter-stream=yes
/tool sniffer start interface=ether1

Параметр filter-stream=yes обязателен, если поток уходит через сниффируемый интерфейс: без него sniffer захватывает собственный поток и зацикливается. Поток не шифруется и повторяет весь трафик, поэтому на загруженном интерфейсе он нагружает и канал до компьютера. В Wireshark используйте фильтр udp.port==37008. Закончив, остановите захват и выключите стриминг: забытый sniffer грузит процессор и держит fast path выключенным.

/tool sniffer stop
/tool sniffer set streaming-enabled=no

Как проверить: после stop выполните /tool sniffer packet print. В списке должны быть пакеты вашего компьютера; если он пуст, фильтр или интерфейс выбраны неверно.

Проверка скорости между двумя роутерами: bandwidth-test

/tool bandwidth-test измеряет пропускную способность между двумя MikroTik. Это не «спидтест до интернета»: один из концов обязательно ваш роутер, на котором работает bandwidth-сервер.

Подготовка. В примерах сервер — роутер удалённого офиса 192.168.89.1, а клиент — роутер главного офиса: тест идёт через туннель из статьи 11. Если туннеля у вас ещё нет, выполните этот раздел после статьи 11 или пропустите его. Если же тестовый клиент (роутер или компьютер) находится в локальной сети самого сервера, туннель не нужен: канонический input из статьи 04 уже принимает всё из LAN, поэтому шаг 4 с правилами firewall вам не понадобится.

1. Проверьте режим устройства на обоих роутерах, и на сервере, и на клиенте:

   /system device-mode print

   В выводе должно быть bandwidth-test: yes. Иначе команда завершится ошибкой not allowed by device-mode. Включение этого режима требует физического доступа к роутеру, поэтому проверьте его заранее, особенно для удалённого офиса.

2. На сервере создайте временного пользователя с правами test и winbox:

   /user group add name=btest policy=test,winbox
   /user add name=btest group=btest password=<ПАРОЛЬ>

3. На сервере разрешите тесты только тому адресу, с которого клиент реально приходит. Роутер, отправляя собственный трафик в туннель, использует адрес интерфейса туннеля, поэтому здесь это сеть туннеля из статьи 11, а не 192.168.88.0/24:

   /tool bandwidth-server set enabled=yes allowed-addresses4=172.31.255.0/30

   В статьях 01 и 04 сервер проверки скорости отключён (enabled=no) как лишняя служба. Поэтому здесь его нужно включить явно, иначе клиент получит can not connect. Если клиентом будет компьютер в локальной сети сервера, укажите его подсеть. Клиент вне списка allowed-addresses4 тоже получит can not connect. Сервер требует логин (authenticate=yes, это значение по умолчанию): без ограничения адресов любой, кто доберётся до порта 2000, сможет пытаться подобрать пароль пользователя с правами test и winbox. Параметр authenticate=no не выключайте.

4. По каноническому firewall из статьи 04 цепочка input принимает только трафик из LAN, поэтому тест через туннель будет отброшен. Откройте на сервере TCP-порт 2000 и UDP-порты от 2000 и выше, но только от адресов туннеля и перед финальным drop (имя интерфейса туннеля на удалённом роутере у вас может отличаться; правила рассчитаны на туннель wg-office из статьи 11):

   /ip firewall filter add chain=input action=accept protocol=tcp dst-port=2000 in-interface=wg-office src-address=172.31.255.0/30 place-before=[find comment="drop everything else"] comment="btest tcp"
   /ip firewall filter add chain=input action=accept protocol=udp dst-port=2000-65535 in-interface=wg-office src-address=172.31.255.0/30 place-before=[find comment="drop everything else"] comment="btest udp"

   Если UDP-тест не получает данных, проверьте, что firewall клиента тоже не блокирует эти порты: UDP-данные идут на порты обоих роутеров.

Запуск теста на клиенте (роутер главного офиса), TCP с ограничением 50 Мбит/с в каждую сторону:

/tool bandwidth-test address=192.168.89.1 user=btest password=<ПАРОЛЬ> protocol=tcp direction=both local-tx-speed=50M remote-tx-speed=50M duration=10s

В результатах tx- — это то, что отправил клиент, rx- — что он получил. Значения local-cpu-load и remote-cpu-load показывают загрузку процессора на каждом конце: если одно из них близко к 100%, упирается роутер, а не канал.

Для проверки потерь пакетов запустите UDP-тест (protocol по умолчанию udp) на скорости ниже ёмкости канала:

/tool bandwidth-test address=192.168.89.1 user=btest password=<ПАРОЛЬ> protocol=udp direction=receive remote-tx-speed=50M duration=10s

При direction=receive данные отправляет сервер, поэтому скорость задаёт remote-tx-speed; при direction=transmit её задаёт local-tx-speed. Если ограничить не ту сторону, UDP-тест зальёт канал без ограничения и покажет ложные потери. Следите за lost-packets: это потери за последнюю секунду.

После тестов уберите всё временное: пользователя, группу и правила firewall, а затем снова отключите сервер, как это было сделано в статьях 01 и 04.

/user remove btest
/user group remove btest
/ip firewall filter remove [find comment="btest tcp"]
/ip firewall filter remove [find comment="btest udp"]
/tool bandwidth-server set enabled=no

Если сервер нужен постоянно, вместо последней команды оставьте enabled=yes вместе с ограничением allowed-addresses4.

Netwatch: оповещения о недоступности узлов

Netwatch периодически проверяет узел и выполняет скрипт, когда состояние меняется. Типы проверок: simple (по умолчанию, обычный ping), icmp (ping с порогами по задержке и потерям), tcp-conn, http-get, https-get и dns.

У проб типа icmp есть пороги по задержке и потерям (thr-avg, по умолчанию 100 мс, и thr-loss-percent, по умолчанию 85%): при превышении проба считается упавшей. На медленных каналах (спутник, мобильная связь) увеличьте пороги или используйте тип simple.

Следим за шлюзом провайдера и пишем в журнал событие:

/tool netwatch add name=isp-gateway host=203.0.113.1 type=icmp interval=10s timeout=3s up-script=":log info \"ISP gateway is up\"" down-script=":log warning \"ISP gateway is down\""

Проверка работоспособности сервиса, а не просто узла (порт 443 на сервере в локальной сети):

/tool netwatch add name=web-server host=192.168.88.10 type=tcp-conn port=443 down-script=":log warning \"Web server is down\""

Состояние всех проб показывает /tool netwatch print: колонка STATUS принимает значения up, down и unknown, а since — время последней смены. Подробные записи об изменениях идут в журнал с топиком netwatch.

Что важно помнить:

• После перезагрузки проба стартует не сразу: по умолчанию startup-delay равен 5 минутам, а до этого статус unknown.
• Если провайдер пропал, письмо через интернет уже не отправить. Поэтому надёжнее доставлять событие во внутренний syslog-сервер (см. ниже) или в систему мониторинга, а не пытаться слать почту из down-script.
• Скрипты Netwatch запускаются с ограниченными правами (read, write, test, reboot); команды, требующие большего, не выполнятся.

Как проверить: временно отключите кабель у проверяемого узла или временно измените host на заведомо недоступный адрес. Через 10–15 секунд /tool netwatch print покажет down, а /log print where topics~"netwatch" — запись о событии.

Состояние самого роутера: ресурсы, температура, профилировщик

Начните с общей картины:

/system resource print
/system resource cpu print
/system health print

• /system resource print: аптайм, версия RouterOS, свободная и общая память, загрузка процессора (cpu-load), свободное место на накопителе. Постоянно высокий cpu-load или почти нулевая свободная память — повод разбираться.
• /system resource cpu print: загрузка по ядрам. Одно ядро под 100% при остальных свободных может быть причиной низкой скорости, хотя общий показатель выглядит спокойным.
• /system health print: напряжение питания, температура и обороты вентиляторов. Какие датчики есть, зависит от модели; на некоторых устройствах команда ничего не покажет. Через SNMP и API температура передаётся в десятых долях градуса: значение 450 означает 45 °C.

Если процессор загружен, а непонятно чем, поможет профилировщик, который показывает долю процессорного времени по типам процессов:

/tool profile
/tool profile cpu=all

Вторая форма доступна на многоядерных моделях. В списке ищите строки с высоким USAGE: firewall, networking, bridging, queuing, wireless, encrypting, dns. Строка idle — свободный ресурс процессора. Остановить вывод можно через Ctrl+C.

Журнал: топики, правила и действия

RouterOS пишет события в журнал: входы пользователей, изменения настроек, смену состояния линков, DHCP, ошибки. У каждой записи есть топики: например, dhcp,info или system,error,critical. Правила /system logging выбирают записи по топикам и передают их действию из /system logging action.

В заводской конфигурации четыре правила: info, warning и error идут в действие memory (память, последние 1000 записей, теряется при перезагрузке), а critical печатается в консоль (echo). Отладочные сообщения (debug) по умолчанию не пишутся.

Чтение журнала

/log print where topics~"interface|dhcp"
/log print where message~"login failure"
/log print follow-only where topics~"critical"

Первая команда фильтрует по топикам, вторая — по тексту, третья в реальном времени показывает новые записи (остановка через Ctrl+C). Добавьте with-extra-info, чтобы увидеть адрес и сервис при входе пользователей.

Чтобы выяснить, кто менял настройки, ищите записи с system,info и словом by:

/log print where topics~"system" and message~" by "

Отладка одной функции

Если, например, клиент не получает адрес по DHCP, включите отладочные сообщения только для этого топика и отдельным буфером, чтобы они не вытеснили остальные записи:

/system logging action add name=dhcpdebug target=memory memory-lines=2000
/system logging add topics=dhcp,debug action=dhcpdebug
/log print where buffer=dhcpdebug
/system logging remove [find action=dhcpdebug]
/system logging action remove dhcpdebug

Последние две команды выполните, когда закончите: они удаляют правило и временное действие.

Сохранение журнала: диск и syslog-сервер

Чтобы записи пережили перезагрузку, отправьте их на диск роутера или на внешний сервер. Правило должно быть своё на каждый топик: правило topics=info,warning,error совпадает лишь с записями, у которых есть все три топика сразу, то есть ни с какими.

Запись на накопитель роутера:

/system logging add topics=warning action=disk
/system logging add topics=error action=disk
/system logging add topics=critical action=disk

Действие disk хранит по умолчанию два файла по 1000 строк (disk-lines-per-file, disk-file-count). Не пишите на встроенную флеш-память всё подряд (например, топик info): она имеет ограниченный ресурс записи. Для долгого хранения лучше внешний диск или syslog-сервер.

Отправка на syslog-сервер в локальной сети (192.168.88.10):

/system logging action set remote remote=192.168.88.10 remote-log-format=syslog syslog-time-format=iso8601
/system logging add topics=info action=remote
/system logging add topics=warning action=remote
/system logging add topics=error action=remote
/system logging add topics=critical action=remote

Готовое действие remote по умолчанию не имеет адреса сервера, поэтому его нужно задать. Формат syslog добавляет к сообщению время и имя роутера (/system identity); iso8601 включает в время год и часовой пояс, а классический формат этих данных не содержит. Следите, чтобы часы роутера были верными: /system clock print. По умолчанию топики в syslog-сообщение не попадают; если нужно различать, например, DHCP и firewall на стороне сервера, добавьте add-topics-string=yes.

Как проверить: создайте тестовую запись и найдите её на сервере.

/log warning "syslog test"

Полезные списки: кто и что в сети

Для повседневной диагностики пригодятся несколько списков:

/ip dhcp-server lease print
/ip arp print
/ip firewall connection print count-only
/ip firewall connection print where src-address~"192.168.88.20"
/interface ethernet monitor ether1 once
/interface print stats
/interface print stats-detail where name=ether1
/interface ethernet print stats

• /ip dhcp-server lease print: кому выдан какой адрес. Torch показывает только IP-адреса, без MAC: по IP-адресу из Torch найдите аренду и прочитайте mac-address, host-name и comment. Если у вас есть MAC-адрес (из sniffer или ARP-ping), найдите его в аренде и в /ip arp print.
• /ip arp print: соответствие IP и MAC; статус reachable означает, что MAC-адрес получен и подтверждён недавно (это не гарантия, что узел сейчас отвечает на запросы); stale, delay и probe — запись устаревает или перепроверяется; failed и incomplete — MAC-адрес получить не удалось.
• /ip firewall connection print: таблица отслеживаемых соединений. С count-only показывает их число (резкий рост может означать сканирование или заражённый компьютер). По строке соединения видно, как NAT поменял адреса: поля reply-dst-address и reply-src-address.
• /interface ethernet monitor ether1 once: состояние порта (status), скорость (rate) и дуплекс. Порт, который вместо 1Gbps договорился на 100Mbps, часто указывает на плохой кабель или разъём.
• /interface print stats, /interface print stats-detail и /interface ethernet print stats: счётчики. tx-queue-drop (есть в print stats) — переполнение очереди интерфейса; link-downs и время последних потерь линка видны только в print stats-detail: растущее значение означает, что линк «моргает»; rx-fcs-error (в /interface ethernet print stats) — битые кадры, обычно кабель или порт.

SNMP: подключение системы мониторинга

SNMP (Simple Network Management Protocol) позволяет системе мониторинга опрашивать роутер: загрузка, трафик на интерфейсах, температура. Для Zabbix есть готовый шаблон «MikroTik by SNMP», и заводить элементы данных вручную не придётся.

Включение:

/snmp set enabled=yes

В заводской конфигурации есть сообщество (community) public, доступное с любого адреса. Это небезопасно: имя сообщества в SNMP версий 1 и 2c передаётся открытым текстом и играет роль пароля. Если вы используете v2c, ограничьте адрес источника и смените имя:

/snmp community set [find name=public] name=<СООБЩЕСТВО> addresses=192.168.88.10/32

Запись write-access должна оставаться no: иначе тот, кто знает имя сообщества, сможет менять настройки и даже перезагрузить роутер.

Выбор версии:

Версия	Безопасность	Когда использовать
v2c	Только имя сообщества в открытом виде и ограничение по адресу	Только в доверенной локальной сети
v3	Аутентификация и шифрование	Везде, где трафик SNMP выходит за пределы доверенного сегмента

Для SNMPv3 создайте запись сообщества с проверкой подлинности и шифрованием (пароли должны быть не короче 8 символов). В документации RouterOS для v3 сказано только об аутентификации по «пользователю и паролю»; в системе мониторинга обычно вводят имя записи как имя пользователя v3, но проверьте это на своём стенде:

/snmp community add name=monitor addresses=192.168.88.10/32 security=private authentication-protocol=SHA1 authentication-password=<ПАРОЛЬ_АУТЕНТИФИКАЦИИ> encryption-protocol=AES encryption-password=<ПАРОЛЬ_ШИФРОВАНИЯ> read-access=yes write-access=no

Для аутентификации доступны также SHA256, SHA384 и SHA512, если их поддерживает ваша система мониторинга; шифрование — DES или AES. Если вы пользуетесь только v3, удалите сообщество public (v2c) совсем, чтобы к роутеру нельзя было обратиться по открытому имени:

/snmp community remove [find name=public]

Если сервер мониторинга находится не в локальной сети (например, за туннелем из статьи 11), придётся добавить в цепочку input правило, разрешающее UDP 161 от его адреса (если туннеля из статьи 11 у вас ещё нет, этот шаг пропустите: сервер в локальной сети в нём не нуждается, потому что input принимает весь трафик из LAN). Разместите его перед финальным drop (см. статью 04), подставьте адрес сервера и никогда не открывайте SNMP на стороне WAN:

/ip firewall filter add chain=input action=accept protocol=udp dst-port=161 in-interface=wg-office src-address=<АДРЕС_СЕРВЕРА> place-before=[find comment="drop everything else"] comment="snmp from monitoring"

В Zabbix создайте узел с интерфейсом SNMP, укажите адрес роутера и привяжите шаблон «MikroTik by SNMP». Версию и сообщество (или имя пользователя и пароли v3) задайте в настройках SNMP-интерфейса узла или в макросах шаблона; точные имена макросов смотрите в описании шаблона в вашей версии Zabbix.

Как проверить: с сервера мониторинга выполните запрос к имени системы, например утилитой net-snmp. Для v2c:

snmpwalk -v2c -c <СООБЩЕСТВО> 192.168.88.1 1.3.6.1.2.1.1.5

Для v3:

snmpwalk -v3 -l authPriv -u monitor -a SHA -A <ПАРОЛЬ_АУТЕНТИФИКАЦИИ> -x AES -X <ПАРОЛЬ_ШИФРОВАНИЯ> 192.168.88.1 1.3.6.1.2.1.1.5

В ответе должно быть имя роутера (sysName). Нет ответа: проверьте адрес в addresses, правило firewall и что SNMP включён.

Graphing: простые графики на самом роутере

Если полноценной системы мониторинга нет, встроенные графики помогут увидеть динамику за сутки, неделю, месяц и год. По умолчанию правил нет, ничего не рисуется.

/tool graphing interface add interface=ether1 allow-address=192.168.88.10/32
/tool graphing resource add allow-address=192.168.88.10/32

Графики отдаёт веб-сервер роутера: должна быть включена служба www (или www-ssl, ей нужен сертификат), а в /ip service webserver не должны быть выключены graphs-plain и graphs-secure. Если вы отключили www по статье 01, страница не откроется. Включите службу только для локальной сети и после просмотра можете выключить её снова:

/ip service enable www
/ip service set www available-from=192.168.88.0/24

Откройте в браузере http://192.168.88.1/graphs/ с компьютера 192.168.88.10. Всегда задавайте allow-address: страницы графиков не требуют входа, а значение по умолчанию (0.0.0.0/0) открывает их любому, кто достучится до веб-сервера роутера. Ответ 403 Forbidden означает, что графики выключены в /ip service webserver. Первые значения появятся через несколько минут: график строится по пятиминутным средним, поэтому короткие всплески на нём сглажены. Графики очередей настраиваются отдельно (/tool graphing queue), к ним мы вернёмся в статье 09.

Как искать причину

Когда пользователь жалуется, что «ничего не открывается», двигайтесь снизу вверх по стеку, не перескакивая. Каждый шаг отвечает на один вопрос и отсекает половину версий.

Шаг	Вопрос	Чем проверить
1. Канал	Есть ли линк и с какой скоростью?	/interface ethernet monitor ether1 once, /interface print stats-detail where name=ether1, /interface ethernet print stats
2. Адрес и шлюз	Есть ли адрес, маршрут и отвечает ли шлюз?	/ip address print, /ip route print where dst-address=0.0.0.0/0, /ping 203.0.113.1
3. Внешний узел по IP	Выходят ли пакеты в интернет?	/ping 192.0.2.80
4. DNS	Разрешаются ли имена?	:put [:resolve example.com], /ip dns cache print
5. NAT	Подменяется ли адрес источника?	/ip firewall nat print stats, /ip firewall connection print where src-address~"192.168.88.20"
6. Firewall	Не режет ли правило трафик?	/ip firewall filter print stats до и после проверки
7. MTU	Проходят ли большие пакеты?	/ping ... size=1500 do-not-fragment

Как это выглядит на практике:

1. Канал. Статус должен быть link-ok, а скорость — ожидаемой. no-link означает кабель, порт или оборудование провайдера. Растущие rx-fcs-error (в /interface ethernet print stats) и link-downs (в /interface print stats-detail) указывают на плохой кабель.
2. Адрес и шлюз. Если адрес от провайдера не получен, смотрите /ip dhcp-client print. Шлюз должен отвечать на ping.
3. Внешний узел по IP. Если пинг до внешнего адреса работает, а в браузере нет, проблема выше по стеку. Если нет, смотрите маршрут по умолчанию и traceroute: он покажет, где обрывается путь.
4. DNS. Пинг по IP проходит, а по имени нет — виноват DNS. Проверьте /ip dns print (поле servers и dynamic-servers) и команду :put [:resolve example.com], выполненную на роутере. Если для заведомо существующего имени она возвращает ошибку (failure: dns name does not exist означает «имя не найдено», а при недоступных серверах ответа нет вовсе или он приходит с ошибкой SERVFAIL) или долго не отвечает, виноват резолвер роутера или его серверы: проверьте servers и dynamic-servers. (Строку resolve failed выводит ping по имени, а не :resolve.) Устаревший ответ поможет сбросить /ip dns cache flush. Если имя разрешается на роутере, но не у клиентов, проверьте, что /ip dns print показывает allow-remote-requests: yes, а /ip dhcp-server network print выдаёт клиентам адрес роутера как dns-server; с компьютера проверьте nslookup example.com 192.168.88.1. Проверка на самом роутере не доказывает, что DNS работает у клиентов.
5. NAT. Пакеты уходят, а ответов нет: проверьте, что правило masquerade существует и его счётчик растёт (/ip firewall nat print stats). В таблице соединений reply-dst-address для исходящего соединения должен быть адресом роутера на ether1.
6. Firewall. Сбросьте счётчики командой /ip firewall filter reset-counters-all, повторите проблемное действие и посмотрите /ip firewall filter print stats: правило, у которого выросли пакеты, и есть виновник. Torch поможет увидеть, доходит ли трафик до роутера вообще: он считает пакеты до firewall.

7. MTU. Мелкие страницы открываются, а крупные зависают, SSH к серверу работает, а передача файла останавливается — типичные признаки проблемы с MTU (чаще на PPPoE, способе подключения, который используют некоторые провайдеры, и на туннелях). Найдите наибольший размер, который проходит без фрагментации:

   /ping 192.0.2.80 size=1500 do-not-fragment count=2
   /ping 192.0.2.80 size=1492 do-not-fragment count=2

   Уменьшайте size, пока не пойдут ответы: это MTU пути. Для PPPoE типично 1492. В колонке STATUS у слишком крупных пакетов будет packet too large and cannot be fragmented или fragmentation needed and DF set. Если нужно, ограничьте размер сегмента TCP правилом в таблице mangle (в ней правила, которые меняют пакеты на лету). MSS (Maximum Segment Size) — максимальный размер данных в одном TCP-сегменте; правило подгоняет его под MTU пути в момент установки соединения (по пакетам SYN), поэтому крупные пакеты перестают зависать. Для PPPoE расчёт такой: MTU 1492 минус 40 байт заголовков IP и TCP дают MSS 1452. Первое правило ниже подгоняет MSS у соединений, которые открывают ваши клиенты наружу, а второе нужно для SYN-пакетов, приходящих снаружи (например, подключений из интернета к серверу из статьи 05):

   /ip firewall mangle add chain=forward out-interface=pppoe-out1 protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1452 comment="clamp MSS for PPPoE"
   /ip firewall mangle add chain=forward in-interface=pppoe-out1 protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1452 comment="clamp MSS for PPPoE in"

   Если у вас не PPPoE или MTU пути оказался другим, замените имя интерфейса и пересчитайте значения: new-mss равен MTU минус 40, а нижняя граница в tcp-mss — new-mss плюс 1. Не добавляйте правила повторно: сначала проверьте /ip firewall mangle print. Добавляйте их только после того, как убедились, что причина в MTU.

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

• Torch на WAN вместо LAN. После NAT все потоки идут с адреса роутера, и узнать, кто загрузил канал, невозможно. Смотрите bridge.
• Диагностика без оглядки на нагрузку. Torch, sniffer и bandwidth-test отключают ускорение или забирают процессор и канал. Запускайте их на короткое время и с фильтрами.
• Одно правило журнала на несколько топиков. topics=info,warning,error не равно «или»: совпадут лишь записи, где есть все три топика. Делайте отдельное правило на каждый.
• Логи только в памяти. После перезагрузки журнал пуст, как раз тогда, когда он нужен. Пишите важные топики на диск или на syslog-сервер.
• SNMP с сообществом public и без ограничения адресов. Любой, кто достучится до порта 161, увидит всё о вашей сети. Смените имя, задавайте addresses, не включайте write-access и не открывайте порт наружу.
• Считать узел выключенным только потому, что он не отвечает на ping. Узел может просто не отвечать на ICMP. Проверьте ARP-ping, TCP-пробу Netwatch или попробуйте подключиться к его сервису.

Что дальше

• MikroTik с нуля 04. Firewall для начинающих — как читать счётчики правил и защищать сам роутер от доступа из интернета.
• MikroTik с нуля 09. Ограничение скорости: Simple Queue, PCQ и CAKE — что делать, когда Torch показал, кто занимает канал.
• MikroTik с нуля 10. Автоматический бэкап и обновление по расписанию — как сохранить конфигурацию, пока вы экспериментируете с диагностикой.
• MikroTik с нуля 12. Два провайдера: резервирование и маршрутизация по условиям — как роутер проверяет шлюзы провайдеров (check-gateway) и переключается на резервный канал; Netwatch из этой статьи можно использовать для оповещения о переключении.