Проброс портов на MikroTik: как настроить перенаправление через NAT

Проброс порта (port forwarding) на MikroTik — это правило трансляции адресов (NAT) в firewall, которое направляет входящее соединение с внешнего адреса и порта роутера на конкретный хост и порт внутри локальной сети. Технически это одно правило в таблице /ip firewall nat с действием dst-nat.

Ниже — как настроить проброс через терминал RouterOS: минимальное рабочее правило, разбор его параметров, проброс на несколько WAN, заворот трафика на сам роутер (redirect), доступ к сервису изнутри сети (hairpin) и проверка, что порт действительно открылся. Команды даны для RouterOS 7.x; в Winbox те же поля находятся в разделе IP — Firewall — NAT.

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

По умолчанию хосты за роутером выходят в интернет, но снаружи к ним не подключиться: приватные адреса вида 192.168.88.10 в интернете не маршрутизируются. Проброс — это исключение, которое роутер делает для одного порта: пакет на внешний порт он перенаправляет на внутренний хост.

Механизм называется NAT и делится на две цепочки. dstnat меняет адрес и порт получателя (для входящих подключений — это и есть проброс). srcnat меняет адрес отправителя (для выхода из локальной сети наружу). Легко перепутать четыре близких действия — развели их в таблице.

Дальше подробно разберем проброс (dst-nat) как основной сценарий заголовка, а src-nat/masquerade покажем кратко в конце — это отдельная задача (выход наружу, а не вход внутрь).

Минимальное рабочее правило проброса

Начнем с одной команды, которую можно скопировать в терминал и поправить под себя. Пробросим внешний TCP-порт 47383 на внутренний хост 192.168.88.10, порт 3389 (удаленный рабочий стол, RDP):

/ip firewall nat
add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=47383 \
    action=dst-nat to-addresses=192.168.88.10 to-ports=3389 \
    comment="RDP -> PC"

Теперь то же правило по параметрам:

• chain=dstnat — правило подмены получателя; оно срабатывает до маршрутизации пакета.
• in-interface-list=WAN — трафик пришел с внешнего интерфейса. Для одного канала можно указать конкретный интерфейс: in-interface=ether1. Без этого условия правило рискует срабатывать и на локальном трафике.
• protocol=tcp и dst-port=47383 — внешний порт, по которому стучатся снаружи.
• action=dst-nat, to-addresses — внутренний хост, to-ports — его реальный порт.

Внешний порт намеренно взят нестандартным (47383, а не 3389). Стандартный порт RDP постоянно перебирают боты, поэтому наружу его лучше не выставлять — подмена порта немного снижает шум атак (но не заменяет пароль и ограничение по адресам). Тот же шаблон работает для любого сервиса: для веб-камеры или видеосервера меняем dst-port и to-ports на нужный (например, 9786), а to-addresses — на адрес устройства.

Не забыть про firewall filter

Частая причина «правило есть, а проброс не работает» — трафик режет фильтр (/ip firewall filter), а не NAT. В стандартном наборе RouterOS проброшенные соединения проходят: правило, отбрасывающее входящие с WAN, содержит условие connection-nat-state=!dstnat, то есть dst-nat-трафик под него не попадает.

Но если вы правили фильтр вручную и добавили общий drop для входящих с WAN, поставьте выше него разрешающее правило именно под свой проброс:

/ip firewall filter
add chain=forward action=accept connection-state=new \
    in-interface-list=WAN protocol=tcp dst-port=3389 \
    dst-address=192.168.88.10 comment="allow forwarded RDP"

Обратите внимание: в фильтре dst-port и dst-address — это уже внутренние значения (3389 и адрес хоста), потому что цепочка forward видит пакет после подмены получателя в dstnat.

Проброс на несколько внешних каналов

Если провайдеров или внешних интерфейсов несколько, не дублируйте правило под каждый. Соберите интерфейсы в список и сошлитесь на него одним условием in-interface-list:

/interface list
add name=WAN comment="uplinks"
/interface list member
add list=WAN interface=ether1
add list=WAN interface=ether2

После этого правило проброса из предыдущего раздела с in-interface-list=WAN уже покрывает оба канала — отдельного правила на второй WAN не нужно. Новый провайдер добавляется одной строкой в члены списка, правила проброса при этом не трогаем.

Заворот трафика на сам роутер (redirect)

redirect — частный случай dstnat: он направляет трафик не на внутренний хост, а на сам роутер. Типовое применение — заставить все устройства сети пользоваться DNS роутера, даже если в настройках клиента прописан чужой DNS:

/ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=redirect to-ports=53 \
    comment="force local DNS"
add chain=dstnat protocol=tcp dst-port=53 action=redirect to-ports=53

Здесь два правила, потому что DNS ходит и по UDP, и по TCP (крупные ответы, зонные передачи). Клиент считает, что отвечает его DNS-сервер, а фактически отвечает роутер. У redirect нет to-addresses — адресом назначения всегда становится сам роутер, задается только to-ports.

Доступ к сервису изнутри сети (hairpin NAT)

Отдельная частая жалоба: проброс работает снаружи, но из локальной сети по внешнему адресу сервис не открывается. Причина в маршрутизации: пакет из LAN на внешний IP роутера возвращается напрямую, минуя обратную трансляцию, и клиент отбрасывает ответ. Лечится добавлением srcnat-правила (hairpin):

/ip firewall nat
add chain=srcnat action=masquerade protocol=tcp dst-port=3389 \
    src-address=192.168.88.0/24 dst-address=192.168.88.10 \
    comment="hairpin RDP"

Правило говорит: если запрос к внутреннему хосту пришел из самой локальной сети, подменить и адрес отправителя — тогда ответ пойдет обратно через роутер. Нужно это только при обращении к своему сервису по внешнему адресу изнутри; снаружи проброс работает и без hairpin.

Как проверить, что порт открылся

Проверять проброс снаружи (с телефона по мобильному интернету или онлайн-сканером портов) — самый надежный способ, потому что из локальной сети внешний путь не воспроизводится. Но сперва убедитесь, что сам сервис вообще слушает свой порт на внутреннем хосте: если сервис не запущен, проброс исправен, а подключения нет.

Логику проверки «слушает ли порт и отвечает ли» удобно показать на локальном примере: поднимем сервис на порту и проверим его так же, как проверяют доступность порта извне.

import socket
import threading

# Поднимаем локальный TCP-сервис на порту 9786 - имитация сервиса за роутером
srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("127.0.0.1", 9786))
srv.listen(1)
srv.settimeout(3)


def serve_once():
    try:
        conn, _ = srv.accept()
        conn.sendall(b"OK")
        conn.close()
    except OSError:
        pass


threading.Thread(target=serve_once, daemon=True).start()


def port_open(host, port, timeout=2.0):
    try:
        with socket.create_connection((host, port), timeout=timeout) as s:
            s.settimeout(timeout)
            return s.recv(2) == b"OK"
    except OSError:
        return False


print("порт 9786 (сервис поднят):", port_open("127.0.0.1", 9786))
print("порт 9787 (никто не слушает):", port_open("127.0.0.1", 9787))

Вывод программы:

порт 9786 (сервис поднят): True
порт 9787 (никто не слушает): False

Открытый порт отвечает установленным соединением, закрытый — отказом (False). Так же ведет себя внешний сканер: True на внешнем IP роутера означает, что цепочка «внешний порт — dstnat — хост — сервис» цела. Если сервис локально слушает, а снаружи порт закрыт — проблема в правиле dstnat, фильтре или на стороне провайдера.

Если не получилось, идите по симптомам. Снаружи порт закрыт, а сервис слушает — проверьте in-interface/in-interface-list и что внешний IP роутера «белый» (провайдер не держит вас за своим NAT). Соединение устанавливается, но сервис не отвечает — неверный to-addresses/to-ports или сервис не запущен. Работает снаружи, но не из LAN — добавьте hairpin.

Выход в интернет: src-nat и masquerade

Проброс пускает трафик снаружи внутрь. Обратная задача — выпустить локальную сеть в интернет — решается цепочкой srcnat. При статическом внешнем IP используют src-nat с явным адресом:

/ip firewall nat
add chain=srcnat action=src-nat out-interface=ether1 \
    to-addresses=203.0.113.5 comment="static WAN"

При динамическом внешнем IP адрес заранее неизвестен, поэтому берут masquerade — он подставляет текущий адрес выходного интерфейса автоматически:

/ip firewall nat
add chain=srcnat action=masquerade out-interface-list=WAN \
    comment="LAN -> internet"

masquerade удобнее для меняющегося адреса, но при большом числе соединений (например, много PPPoE-сессий) он чуть тяжелее для процессора, чем src-nat с фиксированным адресом, — на стабильном канале предпочтительнее второй вариант.

Выводы

• Проброс порта на MikroTik — это одно правило dst-nat в /ip firewall nat: внешний порт роутера направляется на внутренний хост и его реальный порт.
• Не путать четыре действия NAT: dst-nat (вход внутрь), redirect (заворот на сам роутер), src-nat и masquerade (выход наружу при статическом и динамическом внешнем IP).
• Частые причины «правило есть, а не работает»: режет firewall filter, указан не тот входящий интерфейс или у роутера серый IP за NAT провайдера.
• Несколько WAN покрываются одним правилом через in-interface-list; доступ к сервису по внешнему адресу изнутри сети требует hairpin-правила (src-nat/masquerade).
• Проверять проброс надежнее снаружи, предварительно убедившись, что сам сервис слушает свой порт на внутреннем хосте.

Где применяется и что учить дальше

Проброс портов и NAT — повседневная работа сетевого инженера: доступ к внутренним сервисам (RDP, веб-панели, видеонаблюдение, игровые серверы), объединение офисов, публикация сервисов за одним белым IP. За этими же правилами стоят более общие темы — маршрутизация, firewall, VPN и диагностика соединений, без которых проброс превращается в набор заклинаний.

FAQ

Чем dst-port в правиле dstnat отличается от to-ports? dst-port — внешний порт, по которому обращаются снаружи; to-ports — реальный порт сервиса внутри сети. Они могут совпадать или различаться (как 47383 снаружи и 3389 внутри).

Почему проброс не работает, хотя правило добавлено? Чаще всего внешний IP роутера серый (вы за NAT провайдера) — тогда проброс невозможен без белого IP или VPN. Реже режет firewall filter или указан не тот входящий интерфейс.

Нужно ли отдельное правило для UDP, если сервис работает по TCP? Нет. Правило с protocol=tcp пробрасывает только TCP. Если сервис использует и UDP (игры, VoIP, DNS), добавьте второе правило с protocol=udp.