MikroTik с нуля 05. Проброс портов и hairpin NAT

В этой статье мы откроем наружу сервер, который стоит в локальной сети: сделаем так, чтобы к 192.168.88.10 можно было подключиться из интернета по HTTPS (защищённый веб-протокол, порт 443), а также по SSH (защищённое удалённое управление через командную строку) через нестандартный внешний порт 2222. Для этого используется проброс портов: правило NAT (Network Address Translation, трансляция сетевых адресов), которое подменяет адрес назначения пакета. Затем разберём самую частую «загадку» проброса: почему снаружи всё работает, а из своей же локальной сети по внешнему адресу сайт не открывается. Исправить это можно двумя способами: через собственную DNS-запись на роутере (split DNS) или через hairpin NAT («заворот» трафика обратно в локальную сеть).

После прочтения у вас будут: рабочие правила проброса, понимание того, как они связаны с firewall из статьи 04, список источников, которым разрешено администрирование, и набор команд для проверки. Отдельно разберём ситуацию, когда проброс невозможен в принципе, потому что провайдер выдал «серый» адрес.

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

• Роутер MikroTik с RouterOS 7, настроенный по статье 03: порт ether1 смотрит к провайдеру, локальная сеть 192.168.88.0/24 работает через bridge, есть списки интерфейсов LAN и WAN.
• Firewall из статьи 04 (в том виде, как он описан там, вместе с правилом «drop new from WAN not DSTNATed»).
• Сервер в LAN с адресом 192.168.88.10, шлюзом по умолчанию 192.168.88.1 и работающими службами HTTPS (TCP 443) и SSH (TCP 22). Не забудьте, что у самого сервера может быть собственный брандмауэр.
• Адрес сервера не должен меняться. Он входит в пул DHCP из канона (192.168.88.10-192.168.88.254), поэтому закрепите его статической арендой, как в статье 03 (/ip dhcp-server lease add address=192.168.88.10 mac-address=<MAC_СЕРВЕРА> server=dhcp1; имя сервера dhcp1 смотрите в /ip dhcp-server print), либо задайте адрес на самом сервере вручную вне пула. Иначе роутер может выдать 192.168.88.10 другому устройству, и проброс уйдёт не туда.
• Белый (публичный) IPv4-адрес на ether1. Как это проверить, описано ниже в разделе про CGNAT; если адрес «серый», проброс не заработает, сколько ни настраивай.
• Для проверки снаружи: телефон в мобильной сети (не в вашем Wi-Fi) или любой узел вне вашей сети.

В примерах внешний адрес роутера: 203.0.113.2. Это адрес из диапазона для документации; у вас будет свой. Адрес 192.0.2.50 в примерах означает «ваш» удалённый компьютер, с которого вы администрируете сервер.

Как пакет проходит через роутер

Подробная схема прохождения пакета разобрана в статье 04 (раздел «Как пакет проходит через роутер»). Для проброса важны четыре вывода:

• dstnat выполняется до принятия решения о маршрутизации и до цепочки forward: роутер сначала подменяет адрес и порт назначения, и только потом пакет идёт дальше.
• Фильтр forward видит пакет уже после подмены, то есть с внутренним адресом и внутренним портом сервера (192.168.88.10, порт 22, а не 2222).
• Решение о подмене принимается по первому пакету соединения и запоминается в таблице отслеживания соединений (connection tracking). Ответные пакеты сервера автоматически получают обратную подмену, отдельного «обратного» правила писать не нужно.
• Из этого следует условие: ответ обязан пройти через роутер. Шлюзом сервера должен быть 192.168.88.1.

Шаг 1. Пробрасываем HTTPS

Правила проброса обычно не затрагивают доступ к самому роутеру, но ошибка в условиях (см. предупреждение ниже) может перехватить и управляющий трафик. Поэтому, особенно при удалённой работе, включите Safe Mode, как описано в статье 02: так любая опечатка откатится сама, если связь оборвётся.

Добавляем правило:

/ip firewall nat add chain=dstnat action=dst-nat in-interface-list=WAN protocol=tcp dst-port=443 to-addresses=192.168.88.10 to-ports=443 comment="dstnat https to server"

Разберём каждое поле:

Поле	Значение	Зачем
chain=dstnat	цепочка подмены адреса назначения	правило срабатывает до маршрутизации
action=dst-nat	подменить адрес и/или порт назначения	именно на значения из to-addresses и to-ports
in-interface-list=WAN	пакет пришёл с интерфейса из списка WAN	ограничивает правило трафиком из интернета
protocol=tcp	протокол	dst-port работает только вместе с protocol=tcp или udp
dst-port=443	порт, на который пришёл пакет	«внешний» порт
to-addresses=192.168.88.10	новый адрес назначения	куда отправить пакет
to-ports=443	новый порт назначения	«внутренний» порт

Если не указать to-ports, порт останется прежним. Мы пишем его явно, чтобы правило читалось без догадок.

Какое условие выбрать: WAN, dst-address или local

Есть три способа сказать «это пакет, адресованный мне снаружи»:

• in-interface-list=WAN: пакет пришёл со стороны провайдера. Самый простой вариант, подходит и при динамическом адресе от провайдера, потому что сам адрес в правиле не фигурирует. Это наш основной вариант.
• dst-address=203.0.113.2: пакет адресован конкретному внешнему адресу. Подходит, если адрес статический или если у роутера несколько внешних адресов, а пробросить нужно только один. При смене адреса правило придётся править.
• dst-address-type=local: адрес назначения принадлежит самому роутеру (назначен на одном из его интерфейсов). Это «любой адрес роутера», в том числе внутренний 192.168.88.1. Условие удобно при динамическом внешнем адресе, когда нужно поймать и обращения из LAN (см. hairpin ниже), но его надо ограничивать дополнительно. Подробнее см. ниже, шаг 4, вариант Б.

Комбинировать условия можно: например, in-interface-list=WAN вместе с dst-address=203.0.113.2 означает «пришло с интернета на этот адрес».

Как проверить

Выполните проверку с телефона в мобильной сети: откройте https://203.0.113.2/ (подставьте свой внешний адрес). Должна открыться страница сервера (браузер может предупредить о сертификате, если сертификат выпущен на доменное имя). На роутере проверьте счётчик правила:

/ip firewall nat print stats where chain=dstnat

В столбце PACKETS у правила проброса должно появиться ненулевое значение. Учтите: NAT видит только первый пакет соединения, поэтому счётчик показывает примерно число новых соединений, а не объём трафика.

Шаг 2. Нестандартный внешний порт: 2222 снаружи, 22 внутри

Часто SSH выставляют не на стандартном порту, чтобы отсечь часть автоматических сканеров. Это не защита (сканеры проверяют и другие порты), а лишь способ уменьшить шум в журналах. Для проброса меняем внешний и внутренний порты:

/ip firewall nat add chain=dstnat action=dst-nat in-interface-list=WAN protocol=tcp dst-port=2222 to-addresses=192.168.88.10 to-ports=22 comment="dstnat ssh 2222 to server 22"

Подключаться теперь нужно так: ssh -p 2222 пользователь@203.0.113.2. Обратите внимание, что у сервера порт остаётся стандартным: он ничего не знает про 2222.

Сразу переходите к следующему шагу: открывать SSH всему интернету не стоит.

Шаг 3. Ограничиваем, кто может подключаться

Для служб администрирования лучше всего открывать их только с известных адресов. На роутере это делается через список адресов (address list) и условие src-address-list. Создайте список с адресами, откуда вы администрируете сервер:

/ip firewall address-list add list=ssh-admins address=192.0.2.50 comment="admin host"

Добавьте это условие в правило из шага 2 одной командой (правило находим по комментарию):

/ip firewall nat set [find comment="dstnat ssh 2222 to server 22"] src-address-list=ssh-admins

Теперь подмена выполняется только для пакетов с адресов из ssh-admins. Для всех остальных пакет на порт 2222 не получает dstnat и остаётся адресованным самому роутеру (203.0.113.2). Он попадает в цепочку input и отбрасывается там последним правилом («drop everything else» в наборе из статьи 04). Правило forward «drop new from WAN not DSTNATed» страхует от другого случая: попыток с WAN достучаться транзитом до внутренних адресов (например, если провайдер маршрутизирует вам целую подсеть). Для посторонних хостов порт 2222 просто не отвечает.

Как проверить. С адреса 192.0.2.50 (то есть с компьютера, который вы внесли в список) выполните ssh -p 2222 пользователь@203.0.113.2: должен появиться запрос входа на сервере. С любого другого внешнего адреса порт 2222 не должен отвечать: соединение зависает и завершается по таймауту, потому что правило drop молча отбрасывает пакеты, не отправляя отказ. На роутере счётчик правила проброса вырастет только от ваших попыток.

Добавить второй адрес в список можно так же, как первый. В записи списка допускается и подсеть, и диапазон, и DNS-имя (роутер сам разрешит его в адреса). Но если ваш адрес часто меняется, надёжнее не подстраивать список, а подключаться через VPN (см. статью 11).

Нужно ли отдельное правило в forward

Это справочный раздел: команды из него выполнять не нужно. Короткий ответ для конфигурации из статьи 04: нет, не нужно. Пакеты, адресованные самому роутеру, фильтруются в цепочке input, а идущие через роутер к внутренним адресам, в цепочке forward.

Цепочка forward из статьи 04 заканчивается правилом «drop new from WAN not DSTNATed»: оно отбрасывает новые соединения с WAN, кроме прошедших через dstnat (connection-nat-state=!dstnat читается как «не dstnat»). Соединения, которые обработало наше правило проброса, под отбрасывание не попадают. Правил после него нет, а пакет, не совпавший ни с одним правилом цепочки, по умолчанию пропускается.

Но так работает только потому, что в конце forward нет общего «drop всего остального». Если вы (или чужая инструкция) добавили в конец forward блокирующее правило, пробросам нужно явное разрешение выше него: dstnat пакет через фильтр не проводит, а фильтр останавливается на первом совпадении. Правило выглядит так:

/ip firewall filter add chain=forward action=accept connection-nat-state=dstnat connection-state=new in-interface-list=WAN protocol=tcp dst-address=192.168.88.10 dst-port=22,443 comment="allow dstnat to server"

Обратите внимание: в forward мы указываем внутренние адрес и порт сервера (192.168.88.10, порты 22 и 443), потому что к моменту фильтрации dstnat уже выполнен. Порт 2222 в этом правиле не встретится. Это одна из самых частых ошибок: человек пишет в forward внешний порт, и правило никогда не срабатывает.

Если у роутера заводская конфигурация, комментарии у правил другие (defconf: ...), а правило, отбрасывающее новые соединения с WAN без dstnat, называется иначе. Что делать с заводским набором, сказано в разделе «Минимальный набор правил» статьи 04. Команды этой статьи не ищут правила фильтра по комментарию, поэтому логика проброса от этого не меняется: просто проверьте по /ip firewall filter print, что в конце forward стоит правило, отбрасывающее новые соединения с WAN без dstnat.

Порядок важен: фильтр проходит правила сверху вниз и останавливается на первом совпадении, поэтому такое правило нужно поставить выше общего drop. Номера правил и их порядок посмотрите командой /ip firewall filter print; при добавлении можно задать place-before=<номер правила>.

Шаг 4. Доступ к серверу из локальной сети по внешнему адресу

Теперь самая коварная часть. Снаружи всё работает, но вы сидите в офисе, открываете https://203.0.113.2/ и сайт не грузится, хотя именно этот адрес вы раздали клиентам. Причина в том, как устроен NAT.

Почему не работает

Допустим, компьютер 192.168.88.20 обращается к 203.0.113.2:443:

1. Пакет приходит на роутер с интерфейса bridge. Наше правило проброса стоит на in-interface-list=WAN, поэтому для пакетов из LAN оно не срабатывает. Пакет, адресованный роутеру на порт 443, пойдёт в сам роутер (и получит ответ от его собственной службы, если она включена, или отказ).
2. Допустим, мы добавили dstnat и для LAN. Тогда роутер подменит адрес назначения на 192.168.88.10, а адрес источника оставит 192.168.88.20.
3. Сервер видит запрос от 192.168.88.20, который находится в той же подсети. Он отвечает напрямую, минуя роутер. Ответ приходит с адреса 192.168.88.10, тогда как клиент ждёт ответ от 203.0.113.2. Клиент его отбрасывает.

Есть два решения. Первое: вообще не пускать клиентов LAN на внешний адрес, пусть имя сервера внутри сети сразу превращается во внутренний адрес (split DNS). Второе: заставить сервер отвечать через роутер, подменяя адрес источника на адрес роутера (hairpin NAT, он же NAT loopback).

Вариант А. Split DNS: статическая запись на роутере (рекомендуем)

Обычно клиенты обращаются к серверу по имени, а не по IP. Если DHCP из статьи 03 раздаёт клиентам адрес роутера как DNS-сервер, можно сделать так, чтобы внутри сети имя сразу указывало на внутренний адрес сервера. Тогда клиенты LAN не ходят на внешний адрес, hairpin не нужен: трафик идёт напрямую, источник на сервере остаётся настоящим, а при смене внешнего адреса ничего переделывать не придётся.

Роутер должен отвечать на DNS-запросы из локальной сети. Если вы выполнили шаг 6 статьи 03, это уже включено (проверьте /ip dns print: allow-remote-requests: yes). Если нет, включите:

/ip dns set allow-remote-requests=yes

Почему при этом нужен firewall из статьи 04 (чтобы роутер не стал открытым DNS-резолвером), объяснено в шаге 6 статьи 03.

Добавьте статическую запись. В примере используем зарезервированное имя files.example.com; подставьте реальное имя своего сервера, которое смотрит наружу на ваш внешний адрес:

/ip dns static add name=files.example.com address=192.168.88.10 comment="split dns for server"

Запись относится к типу A (по умолчанию). Роутер отвечает на запросы по этому имени сам и не пересылает их провайдерскому DNS.

Как проверить

На компьютере в LAN выполните nslookup files.example.com: в ответе должен быть адрес 192.168.88.10, а не внешний. Если компьютер продолжает получать внешний адрес, сбросьте его кэш (в Windows: ipconfig /flushdns) и кэш роутера:

/ip dns cache flush

Ограничения способа А, о которых стоит знать:

• Он работает только для обращений по имени. Если кто-то набирает https://203.0.113.2/, DNS не участвует, и без hairpin такое обращение не заработает.
• Клиент должен использовать DNS роутера. Если на компьютере прописан сторонний DNS или включён «безопасный DNS» (DoH, DNS через HTTPS) в браузере, запрос уйдёт мимо роутера.
• Если у имени есть IPv6-запись (AAAA) во внешнем DNS, то для неё вашей A-записи недостаточно: по документации, запросы других типов роутер передаёт вышестоящему серверу. Следите, чтобы клиенты не пошли по IPv6 в обход.

Вариант Б. Hairpin NAT (пропустите, если клиенты ходят на сервер по имени)

Hairpin нужен, когда обращение к серверу по внешнему IP-адресу из LAN неизбежно: так прописано в программе, в настройках устройства или в чужой инструкции. Нужны два правила: dstnat для обращений из LAN и srcnat для подмены источника.

/ip firewall nat add chain=dstnat action=dst-nat in-interface-list=LAN dst-address=203.0.113.2 protocol=tcp dst-port=443 to-addresses=192.168.88.10 to-ports=443 comment="hairpin dstnat https"

/ip firewall nat add chain=srcnat action=masquerade src-address=192.168.88.0/24 dst-address=192.168.88.10 out-interface-list=LAN protocol=tcp dst-port=443 comment="hairpin masquerade https"

Что здесь важно:

• В dstnat-правиле для LAN мы указываем конкретный dst-address=203.0.113.2. Без него правило поймало бы все HTTPS-запросы из LAN в интернет (см. предупреждение выше).
• В srcnat-правиле условия описывают пакет после подмены адреса назначения: dst-address=192.168.88.10 и внутренний порт 443. Исходящий интерфейс здесь bridge (он входит в список LAN), поэтому используется out-interface-list=LAN, а не WAN, как в обычном masquerade.
• Правило срабатывает только для обращений через роутер. Прямые подключения клиентов к 192.168.88.10 внутри одной подсети идут через коммутатор моста и до роутера не доходят, их это правило не затрагивает.
• Побочный эффект: для таких обращений сервер видит источником адрес роутера 192.168.88.1, а не реальный адрес клиента. Если сервер ведёт журнал по адресам, учитывайте это.

SSH из LAN через hairpin обычно не нужен: администратор в локальной сети подключается напрямую к 192.168.88.10:22.

Как проверить

С компьютера в LAN откройте https://203.0.113.2/ (подставьте свой внешний адрес). Страница сервера должна открыться. Затем убедитесь, что в списке соединений есть запись с подменой:

/ip firewall connection print where reply-src-address=192.168.88.10

В записи для обращения из LAN в поле SRC-ADDRESS вы увидите адрес клиента, в DST-ADDRESS внешний 203.0.113.2:443, а в REPLY-SRC-ADDRESS внутренний 192.168.88.10. Флаги s и d в левой колонке означают, что соединение прошло и через srcnat, и через dstnat (в справочнике это s - srcnat и d - dstnat).

По необходимости: динамический внешний адрес

Если адрес от провайдера меняется, вместо конкретного dst-address можно взять условие dst-address-type=local. Это правило заменяет dstnat-правило «hairpin dstnat https» выше (оба одновременно не нужны), srcnat-правило остаётся тем же:

/ip firewall nat add chain=dstnat action=dst-nat in-interface-list=LAN dst-address-type=local dst-address=!192.168.88.1 protocol=tcp dst-port=443 to-addresses=192.168.88.10 to-ports=443 comment="hairpin dstnat https dynamic ip"

Правило ловит обращения к любым адресам роутера, кроме 192.168.88.1 (иначе вы потеряли бы веб-интерфейс роутера на порту 443, если он включён). Но так будут перехвачены и обращения к другим адресам роутера, например к адресу на туннельном интерфейсе, поэтому вариант годится только для простых сетей.

По необходимости: сбросить старые соединения

Если новые правила «не видны» из-за старых записей и ждать их истечения неохота, удалите записи, относящиеся к вашему серверу:

/ip firewall connection remove [find reply-src-address~"192.168.88.10"]

Используется общий синтаксис remove [find ...], а оператор ~ означает сравнение по регулярному выражению. Для меню /ip firewall connection отдельно эта команда в руководстве не описана, поэтому, если она не сработает, просто подождите, пока записи истекут по таймауту. Команда закроет и текущие сессии к серверу. Не заменяйте условие на пустое [find]: это удалит вообще все соединения, включая вашу собственную сессию WinBox или SSH на роутер. Выполняйте её в Safe Mode или с локального компьютера.

Для большинства небольших сетей достаточно варианта А; hairpin NAT оставляйте для случаев, когда обращение по IP-адресу неизбежно.

Диагностика: куда пропал трафик

Если проброс не работает, идите по цепочке пакета и смотрите счётчики на каждом этапе. Перед проверкой обнулите счётчики NAT и фильтра, чтобы видеть свежие цифры:

/ip firewall nat reset-counters-all

/ip firewall filter reset-counters-all

Затем с внешнего узла (телефон в мобильной сети) попробуйте подключиться и посмотрите:

1. Счётчик dstnat-правила (/ip firewall nat print stats where chain=dstnat). Растёт: пакеты доходят и подменяются. Не растёт: до правила пакеты не доходят или не подходят под его условия. Проверьте внешний адрес, интерфейс, протокол, порт, src-address-list, а также нет ли выше другого правила, перехватывающего этот трафик.
2. Счётчики отбрасывающих правил фильтра. Если пакет адресован внешнему адресу самого роутера, а dstnat не сработал, он попадает в цепочку input и отбрасывается последним правилом («drop everything else»). Смотрите /ip firewall filter print stats where chain=input: если этот счётчик растёт в момент вашей попытки, а счётчик dstnat-правила нулевой, пакет пришёл, но под условия проброса не подошёл. Из интернета постоянно приходят чужие пакеты (сканеры), поэтому следите именно за изменением во время вашей попытки. Счётчик правила «drop new from WAN not DSTNATed» (/ip firewall filter print stats where chain=forward) растёт в другом случае: когда с WAN приходят транзитные пакеты сразу на внутренние адреса.
3. Список соединений (/ip firewall connection print where dst-port=443). Запись есть и при этом нет флага S (seen-reply): сервер не отвечает или отвечает мимо роутера. Проверьте шлюз на сервере и его собственный брандмауэр.
4. Журнал. Временно включите логирование нужного правила и смотрите /log print:

/ip firewall nat set [find comment="dstnat https to server"] log=yes log-prefix=dnat-https

После отладки обязательно отключите:

/ip firewall nat set [find comment="dstnat https to server"] log=no

Серые адреса и CGNAT: когда проброс невозможен

Бывает, что все правила написаны верно, счётчики на роутере остаются нулевыми, а снаружи ничего не видно. Частая причина: провайдер не выдаёт вам собственный публичный адрес. Вместо него вы получаете «серый» адрес: частный (10.x.x.x, 172.16-31.x.x, 192.168.x.x) или из специального диапазона 100.64.0.0/10, отведённого под CGNAT (Carrier-Grade NAT, NAT уровня оператора). Тогда настоящий публичный адрес принадлежит оборудованию провайдера, и его трансляция вам недоступна. В документации MikroTik сказано, что при CGNAT всё, что требует входящих соединений, ломается, а пробросить порты на своём роутере нельзя. Похожий эффект даёт и «двойной NAT»: другой роутер или модем провайдера стоит перед MikroTik и сам транслирует адреса. Тогда либо включите на нём режим моста (bridge mode), либо настройте проброс и на нём тоже.

Как проверить:

/ip address print where interface=ether1

Если адрес получен по DHCP, посмотрите и его:

/ip dhcp-client print

Сравните адрес на ether1 с тем, что показывает любой сервис «мой IP» на компьютере из вашей сети. Если адреса различаются, то перед вами NAT провайдера, и проброс на вашем роутере не поможет. То же самое, если адрес на ether1 частный или из 100.64.0.0/10.

Что можно сделать:

• Заказать у провайдера «белый» (публичный) адрес. Обычно это отдельная услуга, часто платная; иногда нужен статический адрес.
• Вынести точку входа на внешний хост. Арендуйте виртуальный сервер с публичным адресом, соедините его с офисом туннелем WireGuard и выполняйте проброс на нём. Роутер сам инициирует туннель наружу, поэтому CGNAT не мешает. На внешнем хосте нужны dstnat на адрес сервера (он должен входить в AllowedIPs, список адресов, которые WireGuard пропускает через данного пира, см. статью 11) и srcnat (masquerade) в сторону туннеля, чтобы сервер ответил обратно в туннель, а не через обычный выход в интернет. Недостаток: в журналах сервера не видны настоящие адреса клиентов. Вариант без masquerade (policy routing) заметно сложнее; близкие приёмы маршрутизации по условиям разобраны в статье 12. Настройка самого внешнего хоста выходит за рамки серии.
• Не открывать сервис наружу вовсе, а подключаться к нему через VPN-доступ в офис (тоже статья 11).

Безопасность: что открывать нельзя

Проброс порта — это дыра в защите, которую вы пробиваете осознанно. Правила здравого смысла:

• Открывайте только то, что действительно нужно, и только нужные порты. Не пробрасывайте диапазоны «на всякий случай».
• Не выставляйте наружу RDP (удалённый рабочий стол Windows, TCP 3389) и SMB (сетевые папки Windows, TCP 445) напрямую. Эти службы постоянно сканируются и атакуются, а уязвимости в них находят регулярно. Для удалённой работы используйте VPN.
• Не пробрасывайте порты управления: WinBox (8291), доступ к веб-интерфейсам камер, принтеров и NAS, базы данных. Если доступ нужен, давайте его через VPN или с ограничением по адресам, как в шаге 3.
• Службы администрирования закрывайте списком src-address-list. Для SSH используйте ключи вместо паролей и отключите вход по паролю на самом сервере.
• Следите за обновлениями выставленного наружу сервера: он принимает соединения от всех.
• UPnP (автоматический проброс портов по запросу программ из LAN) в RouterOS по умолчанию выключен. Не включайте его без необходимости: тогда любая программа внутри сети сможет открыть порт наружу без вашего ведома.
• Периодически просматривайте список правил: /ip firewall nat print. Забытые «временные» пробросы — вещь неприятная.

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

• Правило проброса без «привязки» к внешней стороне (нет in-interface-list=WAN, dst-address или dst-address-type=local). Результат: перехватывается весь исходящий трафик клиентов LAN на этот порт.
• Неверный интерфейс или список. Указали in-interface-list=LAN для проброса из интернета или опечатались в имени WAN. Проверьте /interface list member print: ether1 должен входить в WAN. Если выход в интернет устроен через PPPoE или VPN от провайдера, входящим интерфейсом будет не ether1, а, например, pppoe-out1: именно он должен входить в список WAN, иначе in-interface-list=WAN не сработает.
• Во forward указан внешний порт. К моменту фильтрации порт и адрес уже подменены, правило нужно писать на внутренние значения (например, 22, а не 2222).
• Разрешающее правило в forward стоит ниже общего drop и никогда не срабатывает. Порядок сверху вниз имеет значение; смотрите print и place-before.
• Сервер отвечает мимо роутера: у сервера не тот шлюз, или он подключён к другой подсети. Признак: в /ip firewall connection у записи нет флага S.
• Не учли старые записи соединений после изменения NAT и решили, что правило не работает. Проверяйте новым подключением. А если и после этого пусто, проверьте, не «серый» ли у вас адрес (раздел про CGNAT выше).

Что дальше

• MikroTik с нуля 04. Firewall для начинающих — если хотите вернуться к устройству правил фильтрации и цепочки forward.
• MikroTik с нуля 08. Диагностика и мониторинг — инструменты, которые помогают быстро найти, где теряется трафик.
• MikroTik с нуля 11. WireGuard: доступ в офис и туннель между офисами — безопасная альтернатива открытым портам и выход из ситуации с CGNAT.