Проброс портов MikroTik: dst-nat, firewall, CGNAT и безопасная проверка

Проброс порта в RouterOS состоит минимум из dst-nat и разрешения в forward chain. До настройки нужно убедиться, что у роутера есть достижимый публичный адрес и сервис безопасно слушает нужный порт. Публикация панели управления или RDP напрямую в интернет создаёт серьёзный риск.

1. Топология и параметры воспроизводимого примера

Топология, по которой можно пройти пакет от начала до конца

Рассматриваем RouterOS 7 с одним WAN и обычной маршрутизацией между WAN и LAN. Внешний адрес роутера — учебный 203.0.113.10, сервис публикуется на TCP/8443, внутренний сервер — 192.168.10.20:443. Разрешённый партнёр приходит с 198.51.100.25. Все внешние адреса примера заменяют фактическими; они не являются работающим тестовым сервисом.

Проброс — преобразование адреса и порта назначения, а не создание службы на сервере. Если сервер не слушает 443, firewall Linux отвергает источник или ответ уходит через другой шлюз, правильная NAT-строка не сделает соединение рабочим. Для VLAN, VRF, policy routing и нескольких WAN схема требует дополнительного анализа; пример не выдаётся за универсальный набор для любого роутера.

Запишите внешний интерфейс, публичный адрес, протокол, внешний порт, внутренний IP/порт и разрешённые источники. Пример: TCP/8443 на WAN → 192.168.10.20:443 только из адресов партнёра.

Рабочая схема и точные подстановки

Разбираем RouterOS7, IPv4 и один WAN. Публичный адрес роутера — 203.0.113.10, WAN входит в список WAN, сервер — 192.168.10.20/24, шлюз сервера — 192.168.10.1, внешний TCP8443 преобразуется в TCP443. Разрешён партнёр 198.51.100.25/32. Внешние адреса здесь документационные: замените их реальными перед запуском. LAN-интерфейс в примере — bridge-lan.

Маршрут запроса: партнёр → WAN8443 → dstnat → forward к 192.168.10.20:443 → firewall сервера → приложение. Ответ должен пройти через тот же MikroTik, чтобы conntrack выполнил обратное преобразование. Ни правила input, ни открытие Winbox не разрешают этот транзит. IPv6 разбирается отдельно: глобальный IPv6 не нуждается в таком IPv4 dstnat, но требует собственной политики firewall.

2. Публичный адрес, CGNAT, DDNS и IPv6

Почему NAT не создаёт публичный адрес

Сравните адрес WAN в /ip address print с адресом, который видит согласованный внешний сервис. Если WAN содержит RFC1918 или 100.64.0.0/10, а внешний адрес другой, upstream выполняет NAT. Это может быть ваш второй роутер или CGNAT провайдера. В первом случае настраивается вся цепочка устройств; во втором обычный входящий проброс на MikroTik часто невозможен без услуги провайдера или отдельной архитектуры доступа.

DNS A-запись лишь связывает имя с адресом. Она не открывает порт и не устраняет CGNAT. DDNS обновляет имя при смене адреса, но также не обеспечивает входящую достижимость. Если публичный адрес динамический, правило с жёстким dst-address перестанет совпадать после его изменения; заранее выберите обслуживаемый механизм актуализации, а не убирайте все ограничения ради одного теста.

Проверка IPv4 не проверяет IPv6. При наличии AAAA клиент может идти напрямую к глобальному адресу сервера, минуя описанный IPv4 NAT. Тогда нужна отдельная политика IPv6 firewall; исчезновение счётчика dstnat не является неожиданностью.

Сравните адрес WAN в RouterOS с адресом, видимым снаружи. Диапазоны RFC1918 и 100.64.0.0/10 на WAN обычно означают дополнительный NAT провайдера. В таком случае локальное правило не сделает порт доступным без услуги провайдера, VPN или reverse tunnel.

/ip/address/print detail
/ip/route/print where dst-address=0.0.0.0/0
/ip/cloud/print

CGNAT, двойной NAT и несколько WAN

Сначала определите реальный адрес интерфейса/PPPoE и активный маршрут. IP Cloud может показать внешний адрес, только если сервис уже настроен и обновлён; пустое поле не является доказательством отсутствия публичного IP. Не включайте сторонний DDNS лишь ради проверки без необходимости. Сверьте адрес с договором и наблюдением внешнего клиента.

Если на MikroTik 192.168.x.x, а сверху ваш модем с публичным адресом, понадобится отдельный проброс на модеме или согласованная смена режима. Если сверху CGNAT провайдера, локального правила недостаточно. При двух WAN ответ может уйти через другой канал: сначала решите симметрию маршрутов и policy routing, затем публикуйте сервис. Этот пример не добавляет универсальные mangle-правила для неизвестной многоканальной схемы.

3. Готовим сервер и его обратный маршрут

До NAT убедитесь, что сервис доступен с LAN, слушает нужный адрес и имеет локальный firewall. Закрепите IP через DHCP lease или статическую конфигурацию.

Test-NetConnection 192.168.10.20 -Port 443

Сервис должен отвечать до NAT

На Linux-сервере посмотрите слушатель и маршрут возврата:

sudo ss -lntp 'sport = :443'
ip route get 198.51.100.25

Ожидается слушатель на LAN-адресе или нужном wildcard и маршрут через 192.168.10.1. Только 127.0.0.1:443 извне недоступен. На Windows проверяйте Test-NetConnection с соседнего LAN-компьютера, не с самого сервера. Затем проверяйте HTTPS по рабочему DNS-имени и журнал приложения. TCP-успех без HTTP/TLS не завершает проверку.

Закрепите адрес DHCP reservation либо корректным статическим назначением вне динамического пула. Если host firewall ограничивает источники, помните: обычный dstnat сохраняет IP партнёра, поэтому правило сервера должно разрешать именно его. Делать общий srcnat, чтобы скрыть неправильный gateway сервера, означает потерять полезный источник в логах.

4. Safe Mode и сохранение текущей конфигурации

Экспортируйте firewall и сохраните полный backup по процедуре организации. Запишите счётчики текущих правил и используйте уникальный comment.

/export file=before-port-forward
/ip/firewall/nat/print stats
/ip/firewall/filter/print stats

Safe Mode и контроль существующих правил

На RouterOS7 экспорт по умолчанию скрывает чувствительные значения; show-sensitive для этой задачи не нужен. Скачайте экспорт в защищённое хранилище, не оставляйте единственную копию на роутере. Binary backup имеет отдельные требования к восстановлению и может содержать секреты.

/system/resource/print
/interface/list/member/print where list=WAN
/ip/firewall/filter/print detail
/ip/firewall/nat/print detail
/export file=before-port-forward

Откройте Terminal и включите Safe Mode через Ctrl+X; дождитесь соответствующей отметки. При нештатном обрыве внесённые в этом режиме изменения откатываются. Сохраните доступ через LAN/консоль. Найдите конкретное terminal drop в chain forward; в дальнейшем он обозначен уникальным comment FINAL-DROP-FORWARD. Это placeholder для уже существующего правила, не инструкция добавлять новый drop. При несовпадении комментария команды размещения нельзя выполнять.

5. Трансляция пакета и создание dst-nat

Что происходит с заголовками: до NAT, в forward и обратно

Первый SYN приходит с назначением 203.0.113.10:8443. После dst-nat его назначение становится 192.168.10.20:443. Source IP партнёра в обычном входящем сценарии сохраняется. Проверка forward поэтому видит внутренний адрес и порт 443, а не публичные 8443.

На WAN:
198.51.100.25:51000 → 203.0.113.10:8443  TCP SYN

После dst-nat, перед сервером:
198.51.100.25:51000 → 192.168.10.20:443  TCP SYN

Ответ сервера до обратного преобразования:
192.168.10.20:443 → 198.51.100.25:51000  TCP SYN/ACK

Ответ на WAN после обработки установленного NAT-соединения:
203.0.113.10:8443 → 198.51.100.25:51000  TCP SYN/ACK

Это объясняет выбор цепочки: служба находится за роутером, поэтому пакет проходит forward. input предназначен для трафика к самому роутеру. Если публикация не совпала с dst-nat, исходное назначение может остаться адресом роутера — это уже другой путь, и открывать его input «на всякий случай» не надо.

Механизм преобразования первого пакета описан в NAT, порядок обработки — в Packet Flow.

Правило должно быть привязано к WAN interface list, протоколу и порту. Если известны источники, ограничьте их address-list.

Полный порядок создания и включения приведён ниже; сначала проверьте отсутствие дубликатов.

Добавление выключенного правила и allowlist

Создайте отдельный список источников, затем выключенный dstnat. Уникальные комментарии позволяют найти только изменения этой публикации. Пример предназначен для одного запуска; перед повтором проверьте отсутствие дубликатов.

/ip/firewall/address-list/add list=pub8443-partners address=198.51.100.25/32 comment="PUB8443-PARTNER"
/ip/firewall/nat/add chain=dstnat in-interface-list=WAN dst-address=203.0.113.10 protocol=tcp dst-port=8443 src-address-list=pub8443-partners action=dst-nat to-addresses=192.168.10.20 to-ports=443 disabled=yes comment="PUB-HTTPS-8443"

Список WAN должен содержать интерфейс, на котором реально приходит пакет, например PPPoE, а не только физический ether1. Явный dst-address исключает попадание чужого транзита на тот же порт. При динамическом WAN это значение нужно поддерживать либо использовать отдельно спроектированный сценарий без фиксированного адреса. Если ранее есть широкое matching dstnat, оно перехватит первый пакет: проверьте порядок до включения.

6. Forward: точное разрешение и порядок правил

Порядок фильтров важнее их красивых комментариев

В типовом stateful firewall established/related разрешаются, invalid отбрасываются, затем идут точные разрешения новых соединений и общий запрет. Если разрешение публикации стоит после совпадающего drop, оно не сработает. Если перед ним стоит широкое «accept all dstnat», точное разрешение может быть избыточным и не ограничивать фактический доступ.

Перед добавлением посмотрите весь forward, включая jump-цепочки. Найдите место, где реально принимается решение для нового соединения. Наш якорь FINAL-DROP-FORWARD — условие примера, а не стандартный комментарий, который есть на каждом MikroTik. Его не следует создавать вместе с новым drop, если это поменяет существующую политику сети.

Точность проверяют по адресу сервера, порту после трансляции, TCP, WAN и разрешённому списку источников. Правило connection-nat-state=dstnat само по себе разрешает любую совпавшую публикацию, если дополнительных ограничений нет. На сервере также нужен свой host firewall: его правила увидят исходный IP партнёра, если вы специально не применили src-nat.

Dst-nat не заменяет filter. Разрешающее правило ставят до общего drop и ограничивают connection-nat-state.

Ниже правило создаётся выключенным и размещается перед проверенным drop.

Сверьте порядок правил, а не только их наличие.

Размещение forward перед подтверждённым drop

В forward назначение уже преобразовано: здесь нужен 443 и 192.168.10.20, а не внешний 8443. У вас должны оставаться штатные правила established/related и drop invalid. Найдите якорь и убедитесь, что результат — ровно одно нужное правило в forward:

/ip/firewall/filter/print detail where comment="FINAL-DROP-FORWARD"

Только после проверки имени/позиции добавьте разрешение выключенным перед этим правилом:

/ip/firewall/filter/add chain=forward in-interface-list=WAN connection-nat-state=dstnat protocol=tcp dst-address=192.168.10.20 dst-port=443 src-address-list=pub8443-partners action=accept disabled=yes place-before=[find where comment="FINAL-DROP-FORWARD"] comment="ALLOW-PUB-HTTPS-8443"
/ip/firewall/filter/enable [find where comment="ALLOW-PUB-HTTPS-8443"]
/ip/firewall/nat/enable [find where comment="PUB-HTTPS-8443"]

Если в вашей политике имеется общее accept connection-nat-state=dstnat, учтите его при тесте отрицательного источника: опубликованный сервис не должен стать доступен через другое широкое NAT-правило. Сохранение Safe Mode выполняется Ctrl+X после приёмки. Простое наличие нового accept в конце списка после drop не даёт доступа.

7. Внешний тест TCP, TLS и HTTP

Проверяем TCP-рукопожатие, а затем HTTPS

Тестировать нужно из внешней сети, например с согласованного партнёрского узла. Запуск с самого роутера и тест из LAN проверяют другие ветви packet flow. Укажите реальное DNS-имя, которое содержится в сертификате, и порт публикации:

curl --connect-timeout 5 --max-time 15 --resolve service.example.com:8443:203.0.113.10 https://service.example.com:8443/

Команда только обращается к указанному сервису; пример адреса нужно заменить. --resolve задаёт IP для конкретного имени и порта, сохраняя hostname для TLS. Не добавляйте -k в итоговую приёмку: тогда потеряется проверка доверия и имени. Ответ HTTP 401 может означать, что сеть и TLS работают, но приложение требует входа; timeout и ошибка сертификата относятся к другим стадиям.

Для сопоставления разрешённая короткая запись пакетов на сервере:

sudo tcpdump -ni eth0 -c 30 'tcp port 443 and host 198.51.100.25'

Замените eth0 интерфейсом сервера. SYN, SYN/ACK и ACK показывают стадии рукопожатия. Дамп может содержать служебные сведения; не собирайте весь трафик сервера вместо узкого фильтра.

Тест из LAN на публичный адрес проверяет hairpin NAT, а не обычный входящий поток. Используйте мобильный интернет или внешний пробник с разрешённого IP. Одновременно смотрите counters и connections.

/ip/firewall/nat/print stats where comment="PUB-HTTPS-8443"
/ip/firewall/filter/print stats where comment="ALLOW-PUB-HTTPS-8443"
/ip/firewall/connection/print detail where dstnat=yes

Новое соединение, счётчики и обратный поток

Проверяйте с разрешённого внешнего IP, не через внутренний Wi-Fi. Используйте адрес сервиса с TLS, соответствующим сертификату; пример PowerShell проверяет только транспорт:

Test-NetConnection public-service.example.com -Port 8443 -InformationLevel Detailed

В RouterOS рассматривайте conntrack по флагу dstnat и подробному выводу, а не поиском внутреннего IP в исходном dst-address:

/ip/firewall/connection/print detail where dstnat=yes

Исходное назначение хранит публичный адрес/порт, внутренний сервер отражается в ответной стороне записи. В разных выпусках адрес и порт могут выводиться отдельно. seen-reply и established подтверждают обратные пакеты. Растущий NAT-counter без ответа — повод исследовать forward, маршрут и сервер; отсутствующий NAT-counter — WAN, адрес, allowlist или upstream.

NAT выбирается на первом пакете соединения, поэтому после изменения тестируйте новый flow. Для немедленного отзыва уже активного доступа сначала определите конкретную conntrack-запись и удалите только её по ID. Массовый remove [find] оборвёт другие сеансы и не нужен.

8. Hairpin NAT и split DNS

Почему hairpin требует обработки ответа

Клиент LAN 192.168.10.30 обращается к публичному 203.0.113.10:8443. Роутер меняет назначение на 192.168.10.20:443. Если оба устройства находятся в одной подсети и источник сохранён, сервер отвечает клиенту напрямую: ответ приходит от внутреннего адреса, хотя клиент ожидает публичный endpoint. Это нарушает ожидания соединения.

Узкий hairpin src-nat заставляет сервер вернуть ответ через роутер, который восстановит ожидаемую пару адресов. Побочный эффект: сервер видит адрес роутера, а не реального LAN-клиента. Это учитывают в логах и ограничениях приложения. Для серверов в отдельной маршрутизируемой подсети проблема прямого обхода может отсутствовать; hairpin masquerade не добавляют автоматически в любую сеть.

Альтернатива — split DNS и прямое внутреннее подключение. Но DNS не меняет TCP-порт: имя, разрешившееся в 192.168.10.20, при URL с :8443 всё равно приведёт на порт 8443. Нужно согласовать внутренний listener либо URL.

Если внутренние клиенты должны использовать публичное DNS-имя, предпочтите split DNS. Hairpin NAT нужен не всегда и добавляет сложность. Не добавляйте общий masquerade без ограничения адресов и назначения.

Hairpin: отдельный LAN-сценарий

При split DNS внутренняя запись сервиса указывает прямо на 192.168.10.20; если клиент использует :8443, сам сервер тоже должен принимать 8443 либо внутренний URL должен быть 443. Один DNS не переводит порты.

Для hairpin к тому же публичному 8443 нужен отдельный LAN dstnat и узкий srcnat. Пример только для клиентов той же подсети, которые иначе получили бы ответ напрямую мимо роутера:

/ip/firewall/nat/add chain=dstnat in-interface=bridge-lan src-address=192.168.10.0/24 dst-address=203.0.113.10 protocol=tcp dst-port=8443 action=dst-nat to-addresses=192.168.10.20 to-ports=443 disabled=yes comment="PUB8443-HAIRPIN-DST"
/ip/firewall/nat/add chain=srcnat out-interface=bridge-lan src-address=192.168.10.0/24 dst-address=192.168.10.20 protocol=tcp dst-port=443 connection-nat-state=dstnat action=masquerade disabled=yes comment="PUB8443-HAIRPIN-SRC"

Проверьте LAN-forward и порядок NAT, затем отдельно включайте правила и тестируйте. Hairpin скрывает реальный IP внутреннего клиента от сервера. Если LAN-forward у вас закрыт, потребуется согласованное узкое разрешение; WAN-accept выше к этому потоку не применяется. Не включайте hairpin, если он не нужен.

9. Диагностика conntrack, счётчиков и FastTrack

Conntrack, FastTrack и повторный тест после изменения

NAT применяется к первому пакету соединения, а последующие пакеты используют сохранённое состояние. После правки правила уже открытая сессия может продолжить старое преобразование. Закройте клиентское соединение и создайте новое; если требуется удалить запись conntrack, сначала найдите только запись этого теста.

Не выполняйте очистку всей таблицы соединений на рабочем маршрутизаторе ради одной публикации: это затронет VPN и пользовательские сеансы. Счётчик NAT отражает совпадение первых пакетов, а не весь объём передачи. Connection tracking поясняет stateful обработку.

FastTrack может обходить часть обычной обработки и менять наблюдаемые счётчики. Запущенный диагностический инструмент также может влиять на ускорение. Отсутствие ожидаемого полного объёма в одном счётчике не является самостоятельным доказательством потери пакетов. Для измерения производительности и для проверки доступности нужны разные опыты.

Используйте TLS, MFA, патчи, журналы и ограничение источников. Для RDP, Winbox, SSH и административных панелей предпочтителен VPN. NAT не является защитой приложения.

Диагностический журнал без потока лишних сообщений

На время теста используйте counters и точечный захват трафика. Если включаете логирование filter, ограничьте его конкретным flow и небольшим окном; бесконтрольный log для всего WAN быстро заполняет хранилище. FastTrack влияет на наблюдаемость последующих пакетов, поэтому отсутствие каждого пакета в counters не означает потери при работающем соединении.

Проверьте TLS-цепочку, актуальность приложения и вход только необходимым пользователям. NAT меняет адрес, но не устраняет SQL injection, слабый пароль или неисправную MFA. Для администрирования используйте VPN вместо ещё одного открытого порта.

10. Отзыв доступа и эксплуатационные проверки

Минимальная эксплуатационная документация публикации

Оставьте запись: внешний FQDN/IP/порт, внутренний IP/порт, разрешённые источники, владелец сервиса, комментарии правил, срок необходимости, положительный и отрицательный тест. Проверьте, что сервер имеет фиксированный адрес либо управляемую DHCP reservation. Изменившийся адрес сервера превращает старую публикацию в правило для другого устройства.

При отзыве доступа сначала отключают связанные NAT и точное разрешение forward, затем проверяют новую внешнюю попытку. Удалять весь allowlist с чужими публикациями или общие stateful правила не требуется. Для административных RDP, SSH и Winbox предпочтительнее отдельный управляемый канал доступа, а не бесконтрольное выставление этих сервисов через такой пример.

Проверьте разрешённый и запрещённый источник, нужный протокол, журнал сервиса и отсутствие побочного доступа. Для возврата отключите правила по comment и повторите внешний тест.

/ip/firewall/nat/disable [find comment="PUB-HTTPS-8443"]
/ip/firewall/filter/disable [find comment="ALLOW-PUB-HTTPS-8443"]

Положительная и отрицательная приёмка

Зафиксируйте четыре результата: внешний разрешённый источник проходит 8443; внешний посторонний не проходит; соседний внешний порт закрыт; обычные LAN/VPN-сервисы продолжают работать. Дополнительно проверяйте реальный запрос приложения и, если включён, hairpin. Укажите какой IP видит сервер в журнале.

При возврате выключите только уникальные добавленные правила, включая hairpin, и точечно завершите их активные conntrack-сеансы после согласования. Удаление allowlist выполняется только когда он больше не используется. Восстановление полного binary backup требуется при отдельном отказе, а не как обычный способ убрать два правила. MikroTik — управление конфигурацией, текущая документация connection tracking.

Источники: MikroTik — RouterOS NAT, MikroTik — Firewall.