Короткий ответ

Если роутер пингуется с 192.168.88.0/24 и WinBox на 192.168.88.1:8291 открывается только оттуда, проблема почти всегда в input: accept только in-interface=bridge / list LAN, а вы пришли из VLAN, wg0 или соседней подсети. Цель — добавить узкий accept для management-сети или VPN, а не accept на in-interface=ether1.

Параллельно проверьте /ip service: winbox/ssh с address=192.168.88.0/24 отрежут даже «правильный» filter, если вы в 10.10.10.0/24 за WireGuard. Это не повод включать WinBox на 0.0.0.0/0.

Симптомы и как отличить

Откуда заходитеWinBoxВывод
ПК в bridge LANдаinput LAN жив
Тот же ПК, IP 203.0.113.10неттак и должно быть
Хост за wg0 10.10.10.2нетнет accept input с wg0 / нет service address
MAC Neighbors, IP нетfilter/service по IPWinBox не подключается
Ниоткуда, даже LANвырезали LAN acceptконсоль / MAC, затем чинить input

Отличите от полного «нет интернета»: транзит forward может работать при мёртвом управлении из VPN.

Возможные причины

  1. Filter input accept только in-interface-list=LAN, VPN-интерфейс не в LAN.
  2. /ip service set winbox address=192.168.88.0/24 без подсети админов.
  3. Переименовали bridge, list LAN пустой.
  4. Drop invalid + асимметричный заход через второй WAN.
  5. После «hardening» запретили всё, забыли management VLAN.
  6. allowed-address на пользователе /user.

Диагностика

С места, где работает (LAN), снимите картину. Если LAN тоже мёртв — только MAC-WinBox/консоль.

/ip service print
/ip firewall filter print stats where chain=input
/interface list member print
/user print
/ip neighbor print

Проверка, слушает ли служба:

/ip service set ssh disabled=no
/ip service print

Порт WinBox по умолчанию 8291, SSH 22. Смена порта без документации — частая причина «timeout с VPN».

С клиента, которому нужно управление:

nc -vz 192.168.88.1 8291
nc -vz 192.168.88.1 22

Timeout — filter/маршрутизация. Connection refused — служба disabled или не тот порт. Успех TCP без логина — уже не firewall.

Смотрите counters input drop в момент попытки. Методика — firewall counters.

Решение

Сценарий A. Управление из WireGuard

Добавьте wg0 в list, не в WAN:

/interface list member add list=LAN interface=wg0

Либо точечно, лучше для аудита:

/ip firewall filter
add chain=input action=accept in-interface=wg0 src-address=10.10.10.0/24 comment=mgmt-wg

И service:

/ip service
set winbox address=192.168.88.0/24,10.10.10.0/24
set ssh address=192.168.88.0/24,10.10.10.0/24

Туннель должен маршрутизировать 192.168.88.1 — иначе это site-to-site маршруты, не input.

Сценарий B. Management VLAN

Accept in-interface=vlan99-mgmt в input выше drop. Адрес управления повесьте на VLAN-интерфейс, не на untagged bridge, если включён vlan-filtering.

Сценарий C. Случайно вырезали LAN accept

Верните defconf-логику: established,related; затем accept ICMP (по политике); accept in-interface-list=LAN; затем drop. Не копируйте «drop all input» без LAN-исключения.

Сценарий D. /user allowed-address

/user set admin allowed-address=192.168.88.0/24,10.10.10.0/24

Пустой allowed-address = без ограничения. Слишком узкий — отказ даже при зелёном filter.

Как проверить, что проблема устранена

  1. WinBox/SSH с LAN как раньше.
  2. WinBox/SSH с админ-VPN.
  3. С внешней проверки (или с телефона вне Wi‑Fi) TCP 8291 на 203.0.113.10 — timeout/drop, не login prompt.
  4. /ip firewall filter print stats на новом accept растут только с VPN/LAN.

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

Если не помогло

  • Маршрут к 192.168.88.1 с удалённой стороны идёт в интернет, не в туннель — routing, не MikroTik input.
  • RoMON/MAC работает, IP нет — L3/filter/service.
  • После смены порта забыли новый в клиенте WinBox.
  • www открыт, WinBox нет — разные /ip service; не лечите включением www-ssl в интернет.

Профилактика

  • Отдельный address-list mgmt-allowed.
  • Управление только LAN + admin VPN.
  • Тест «с телефона LTE на публичный IP» после каждой дырки в input.
  • Backup до hardening.

Как не открыть WAN, проверяя доступ из «другой сети»

Частая ошибка: админ сидит в VLAN 20 (10.0.20.0/24), а LAN-list содержит только bridge без vlan20. Пинг до 192.168.88.1 может идти через маршрутизацию между VLAN (forward), а WinBox — это input. Поэтому «сеть вроде одна» в голове и две цепи на роутере.

Сделайте временный management VLAN членом list LAN или узкий accept:

/interface list member add list=LAN interface=vlan20-mgmt
/ip service set winbox address=192.168.88.0/24,10.0.20.0/24,10.10.10.0/24
/ip service set ssh address=192.168.88.0/24,10.0.20.0/24,10.10.10.0/24

Проверка с телефона в LTE обязательна: TCP 8291 на 203.0.113.10 должен остаться закрытым. Если для теста вы добавили accept с ether1, удалите его в том же окне, не «завтра». Для подрядчика выдайте peer WireGuard с allowed-address=/32, а не dstnat 8291.

Если после добавления VLAN WinBox с access-порта исчез — смотрите bridge VLAN filtering: CPU мог выпасть из management VLAN. Safe Mode при любых правках input и bridge.

Дополнительно проверьте /tool mac-server mac-winbox: если allowed-interface-list не содержит новый mgmt-порт, аварийный MAC-вход с ноутбука в серверной тоже пропадёт. Это не повод добавлять ether1 в LAN.

FAQ

Почему ping на 192.168.88.1 с VPN есть, а WinBox нет?

ICMP accept, TCP 8291 нет. Или service address не включает VPN-подсеть.

Безопасно ли открыть WinBox на WAN с сильным паролем?

Нет. Пароль перебирают, WinBox-баги случаются. Нужен VPN. Даже address= на один «домашний» IP провайдера ломается при смене DHCP.

MAC WinBox с WAN возможен?

MAC-доступ — L2. С интернета его нет. Если «MAC с WAN» вдруг есть, ether1 в общем L2 с атакующим — авария топологии.

Нужно ли менять порт 8291?

Снижает шум сканеров, не заменяет VPN и filter. Если меняете — документируйте.

SSH ключи вместо пароля решают input drop?

Нет. Сначала TCP должен дойти. Ключи — слой /user ssh-keys, после сети.