Как пробросить порт через VPN между двумя MikroTik?
На маршрутизаторе с публичным адресом разрешите нужный порт и направьте трафик в VPN-туннель. На втором MikroTik создайте обратные правила NAT к внутреннему узлу. Перед проверкой сверьте адреса, интерфейсы, протокол TCP или UDP и ограничьте доступ доверенными источниками.
Читайте также
Задача: на центральном MikroTik есть публичный IPv4, а сервер находится в филиале за вторым маршрутизатором и CGNAT. Нужно принять подключение на публичный порт и доставить его через VPN к серверу. Само правило dst-nat решает только часть задачи: туннель должен передавать нужные адреса, firewall — разрешать транзит, а ответ — возвращаться через тот же маршрутизатор, который выполнил NAT.
Ниже — технический пример для RouterOS 7, IPv4 и уже работающего маршрутизируемого WireGuard-туннеля. Он не создаёт VPN с нуля и не заменяет существующий firewall. Все адреса демонстрационные; правила добавляются отключёнными для проверки перед включением.
1. Схема сети и исходные условия
Используем следующие параметры:
- R1, центральный MikroTik: публичный адрес 203.0.113.10, WAN-интерфейс ether1, VPN-интерфейс wg-branch, адрес туннеля 10.77.0.1.
- R2, филиал: VPN-интерфейс wg-hub, адрес туннеля 10.77.0.2, LAN-интерфейс bridge-lan, адрес LAN 192.168.20.1/24.
- Сервер: 192.168.20.10, TCP 443, шлюз по умолчанию 192.168.20.1.
- Разрешённый внешний клиент: 198.51.100.25; подключается к 203.0.113.10:8443.
Диапазоны 203.0.113.0/24 и 198.51.100.0/24 предназначены для документации. Замените их реальными адресами, а имена интерфейсов — своими. У R1 должна быть входящая доступность публичного адреса; при NAT перед R1 потребуется согласованный проброс на вышестоящем устройстве. CGNAT на стороне филиала не мешает этой схеме, если исходящий VPN уже установлен и поддерживается.
На обоих роутерах заранее проверьте обработку established,related и invalid в forward. Пример предполагает рабочую политику для ответного трафика, доступ между узлами туннеля и отсутствие конфликтующих маршрутов, RAW/notrack и NAT. Не включайте несколько вариантов конфигурации одновременно.
2. Как меняются адреса запроса и ответа
Возьмём TCP-соединение с исходным портом клиента 53000. До R1 приходит пакет 198.51.100.25:53000 → 203.0.113.10:8443. После DNAT назначение становится 192.168.20.10:443. После узкого SNAT источник становится 10.77.0.1; исходный порт обычно сохраняется, но NAT может изменить его при необходимости.
R2 получает уже внутренний пакет 10.77.0.1:53000 → 192.168.20.10:443 и маршрутизирует его в LAN. Сервер отвечает на 10.77.0.1 через свой шлюз R2; R2 доставляет ответ в туннель. На R1 connection tracking автоматически выполняет обратные преобразования: клиент получает ответ от 203.0.113.10:8443.
В упрощённом пути транзитного пакета RouterOS сначала применяет dst-nat, затем принимает решение маршрутизации, обрабатывает filter forward и src-nat. Поэтому правило forward на R1 проверяет адрес сервера после DNAT, но адрес клиента до SNAT. Основа — Packet Flow in RouterOS.
Туннель инкапсулирует этот внутренний пакет в собственный транспорт. Разрешение UDP-порта WireGuard в input и разрешение TCP-транзита в forward — разные задачи.
3. Подготовка: копия, маршруты и allowed-address
Перед изменениями сохраните экспорт и бинарную копию в Files, затем скачайте их с устройства. Экспорт без show-sensitive скрывает чувствительные параметры по умолчанию в RouterOS 7, но всё равно проверьте файл перед передачей. Бинарная копия может содержать секреты: используйте отдельный пароль и защищённое хранилище. Порядок описан в Configuration Management и Backup.
/export file=before-vpn-port-forwardНа R1 проверьте VPN, адреса и текущие маршруты:
/interface wireguard print detail
/interface wireguard peers print detail
/ip address print detail
/ip route print detail where dst-address=192.168.20.0/24Вывод peer может содержать чувствительные сведения: не публикуйте его без проверки. В allowed-address нужного peer на R1 должны присутствовать адрес R2 10.77.0.2/32 и сеть 192.168.20.0/24; на R2 — источник 10.77.0.1/32. allowed-address не создаёт IP-маршрут автоматически. При нескольких peer на одном интерфейсе проверьте отсутствие пересекающихся диапазонов. Значение параметра и примеры маршрутов — в документации WireGuard.
Если маршрута к LAN филиала ещё нет, добавьте на R1 отключённый маршрут:
/ip route add dst-address=192.168.20.0/24 gateway=wg-branch disabled=yes \
comment="AVG-VPNPF-route"Для такой WireGuard-схемы маршрут указывает интерфейс, а allowed-address выбирает peer для назначения. Адреса 10.77.0.1 и 10.77.0.2 должны уже иметь корректную связанность через туннель. Если сеть филиала совпадает с локальной сетью R1, сначала решите конфликт адресации: данный пример его не устраняет.
4. R1: DNAT публичного порта и узкий SNAT
Добавьте правила NAT на R1. Они ограничены входным интерфейсом, публичным адресом, источником, протоколом и портом:
/ip firewall nat add chain=dstnat action=dst-nat in-interface=ether1 \
src-address=198.51.100.25/32 dst-address=203.0.113.10 protocol=tcp \
dst-port=8443 to-addresses=192.168.20.10 to-ports=443 disabled=yes \
comment="AVG-VPNPF-dnat"
/ip firewall nat add chain=srcnat action=src-nat out-interface=wg-branch \
src-address=198.51.100.25/32 dst-address=192.168.20.10 protocol=tcp \
dst-port=443 connection-nat-state=dstnat to-addresses=10.77.0.1 disabled=yes \
comment="AVG-VPNPF-snat"SNAT здесь нужен, чтобы сервер отвечал VPN-адресу R1, а не внешнему клиенту через интернет филиала. У правила назначения dst-port=8443, у правила источника — уже внутренний dst-port=443. VPN-адрес статический, поэтому указан src-nat; masquerade не требуется.
Цена этого решения: сервер видит источником 10.77.0.1. Идентификация клиента по исходному IP в приложении теряется. Для нескольких разрешённых клиентов продумайте address-list и согласованно измените ограничения DNAT, SNAT и filter; не расширяйте только одно правило.
NAT применяется к первому пакету соединения, а дальнейшие пакеты используют состояние connection tracking. Поэтому изменение правила не переписывает уже открытые сессии. Механика и различия src-nat/masquerade — в документации NAT.
5. R1 и R2: разрешения в forward и порядок правил
На R1 разрешите новый транзит к серверу после DNAT:
/ip firewall filter add chain=forward action=accept connection-state=new \
connection-nat-state=dstnat in-interface=ether1 out-interface=wg-branch \
src-address=198.51.100.25/32 dst-address=192.168.20.10 protocol=tcp \
dst-port=443 disabled=yes comment="AVG-VPNPF-forward-r1"На R2 разрешите соответствующий транзит из туннеля в LAN:
/ip firewall filter add chain=forward action=accept connection-state=new \
in-interface=wg-hub out-interface=bridge-lan src-address=10.77.0.1/32 \
dst-address=192.168.20.10 protocol=tcp dst-port=443 disabled=yes \
comment="AVG-VPNPF-forward-r2"На R2 не добавляем connection-nat-state=dstnat. Преобразование выполнено на R1, и состояние его connection tracking не передаётся второму роутеру. На R2 это самостоятельное маршрутизируемое соединение. Сам matcher описан в справочнике firewall filter.
Команда add помещает правило в конец списка. До включения проверьте порядок в WinBox или терминале:
/ip firewall filter print detail
/ip firewall nat print detailРазместите новые разрешения перед блокирующими правилами нужной цепочки; NAT — перед более общими перекрывающими преобразованиями. Сохраните существующие защитные ограничения и рабочую обработку established,related. Если выше уже стоит широкое accept для всего VPN или DNAT, узкое правило ниже не ограничит его: оцените итоговую политику, а не только добавленную строку.
Для сервера настройте разрешение TCP 443 от 10.77.0.1 в локальном firewall. Открывать input на MikroTik для этого HTTPS-сервиса не нужно: назначение — сервер за R2.
6. Проверка и включение подготовленного варианта
Сначала, до публичного теста, проверьте с R1 доступность туннельного адреса R2:
/ping address=10.77.0.2 src-address=10.77.0.1 count=5После проверки и включения маршрута проверьте сервер с явно выбранным VPN-источником:
/ip route enable [find where comment="AVG-VPNPF-route"]
/ping address=192.168.20.10 src-address=10.77.0.1 count=5Если готовый маршрут уже существовал, команда enable не найдёт добавленного правила — это нормально. Для ping ICMP должен быть разрешён на сервере и по пути, включая forward R2; отсутствие ответа ещё не доказывает отсутствие TCP-доступа. Пакет, созданный самим R1, не проходит его forward, поэтому успешный ping не проверяет разрешение транзита на R1.
После проверки порядка правил включите на соответствующих устройствах:
/ip firewall filter enable [find where comment="AVG-VPNPF-forward-r2"]Это команда для R2. Затем на R1:
/ip firewall filter enable [find where comment="AVG-VPNPF-forward-r1"]
/ip firewall nat enable [find where comment="AVG-VPNPF-snat"]
/ip firewall nat enable [find where comment="AVG-VPNPF-dnat"]Тестируйте из внешней сети с разрешённым исходным адресом 198.51.100.25. Проверка из LAN по публичному адресу не соответствует in-interface=ether1 и потребует отдельного решения для внутреннего доступа.
Для HTTPS используйте доменное имя сервиса, которое разрешается в публичный адрес R1, и внешний порт 8443. Проверяйте сертификат и реальный запрос приложения: успешный TCP handshake ещё не подтверждает работоспособность HTTPS.
7. Диагностика: счётчики, conntrack и захват пакетов
На R1 посмотрите счётчики и состояние нужного соединения:
/ip firewall nat print stats where comment~"AVG-VPNPF-"
/ip firewall filter print stats where comment~"AVG-VPNPF-"
/ip firewall connection print detail where dst-address="203.0.113.10:8443"Счётчик NAT отражает попадание первых пакетов соединений, а не весь переданный объём. В conntrack сопоставьте исходную и ответную пары адресов, признаки NAT, TCP-state и seen-reply. Формат доступных полей сверяйте с установленной версией по Connection tracking.
Проследите один тестовый запрос по точкам:
- На WAN R1 должен появиться SYN на 203.0.113.10:8443.
- В туннеле после преобразований — запрос от 10.77.0.1 к 192.168.20.10:443.
- На LAN R2 — тот же запрос; сервер должен вернуть SYN-ACK либо диагностируемый отказ.
- На R1 должен прийти ответ из VPN, а наружу уйти ответ с публичного адреса и порта.
Для короткого наблюдения на VPN-интерфейсе R2:
/tool sniffer quick interface=wg-hub ip-protocol=tcp port=443Остановите просмотр Ctrl+C. На этом интерфейсе виден внутренний трафик туннеля; на WAN — его зашифрованный транспорт. Синтаксис и ограничения захвата описаны в Packet Sniffer.
Захват может влиять на ускоренную обработку, поэтому результат со включённым sniffer нельзя без проверки считать поведением обычного режима. Не выполняйте сброс всей таблицы соединений на рабочем маршрутизаторе ради одного теста. После правки NAT создайте новое соединение или удалите только точно определённую тестовую запись.
8. Как сохранить реальный IP клиента: вариант без SNAT
Если приложению нужен исходный адрес, можно оставить DNAT на R1 и отказаться от SNAT. Тогда R2 и сервер получают 198.51.100.25 → 192.168.20.10:443. Но для ответа на 198.51.100.25 нужен маршрут назад через R1; иначе R2 отправит пакет своему обычному провайдеру и соединение не соберётся.
Для единственного фиксированного клиента допустим отдельный маршрут /32 на R2 через VPN. В WireGuard allowed-address peer на R2 должен разрешать этот исходный адрес; filter на R2 тоже должен проверять 198.51.100.25 вместо 10.77.0.1. Сам сервер по-прежнему возвращает ответ через R2. Не смешивайте эти параметры с основным SNAT-вариантом.
Для произвольных внешних клиентов статических /32 недостаточно. Потребуется продуманная policy routing на R2: отметить входящее соединение из VPN и отправлять только его ответы через нужную таблицу. Нужно учесть локальные назначения, разрешённые адреса peer и работу FastTrack. Простой default route в VPN может неожиданно перенаправить весь интернет филиала.
Эту схему проектируют по действующему mangle/routing firewall, поэтому универсальный скрипт замены маршрутов здесь не приводится. Рекомендации по таблицам — в Policy Routing. FastTrack ориентирован на main; соединения, которым нужна другая таблица, исключают из ускорения по согласованной политике.
9. Двойной DNAT, FastTrack, MTU и частые ошибки
Нужен ли второй DNAT на R2? В основном примере нет: R1 уже указал конечный адрес сервера, и маршрут ведёт в LAN. Альтернативная схема — сначала перевести публичный порт в 10.77.0.2:55555, а затем на R2 сделать второй DNAT в сервер. Это допустимая отдельная архитектура, но у неё две независимые таблицы NAT, правила forward и проверки обратного пути. Добавлять второй DNAT к готовому прямому варианту не нужно.
SYN доходит, ответа нет. Проверьте слушающий порт, локальный firewall и шлюз сервера. Ответ идёт через WAN филиала — проверьте SNAT либо обратную маршрутизацию выбранного варианта.
NAT-счётчик нулевой. Проверяйте фактический WAN-интерфейс, публичный IP, исходный адрес теста, TCP/UDP и более ранние правила. VPN handshake не доказывает доступность публичного TCP-порта.
Счётчик forward на R2 нулевой. Проверьте входной интерфейс, источник после SNAT и ошибочный matcher dstnat. Проверьте также, не принимает ли пакет более раннее правило.
Работает только при захвате. Проверьте FastTrack, policy routing и путь пакетов. В базовом примере с main не требуется автоматически отключать FastTrack для всей сети. Но ускорение способно менять видимость трафика и обходить часть обработки; для IPsec, очередей и других схем исключения оцениваются отдельно.
TCP устанавливается, передача зависает. Проверьте MTU туннеля, PMTUD, ICMP-сообщения и повторные передачи. Не задавайте случайное MSS=1300: сначала измерьте проблему. Для WireGuard проверьте MTU интерфейса и при необходимости согласованное изменение MSS через mangle; параметр change-tcp-mss в PPP-профиле относится к PPP-туннелям и к WireGuard не применяется. Для UDP создавайте отдельные правила с protocol=udp; TCP-пример не описывает поведение любого UDP-приложения.
10. Безопасность, возврат изменений и приёмка
Публикуйте только нужный сервис для согласованных источников. Проброс через VPN не добавляет аутентификацию самому приложению. Для административного доступа часто удобнее подключение администратора к VPN, чем публикация RDP или интерфейса управления наружу.
У правил одинаковый префикс комментариев для поиска. Для прекращения новых подключений на R1 отключите DNAT, затем остальные добавленные элементы по необходимости:
/ip firewall nat disable [find where comment="AVG-VPNPF-dnat"]
/ip firewall nat disable [find where comment="AVG-VPNPF-snat"]
/ip firewall filter disable [find where comment="AVG-VPNPF-forward-r1"]
/ip route disable [find where comment="AVG-VPNPF-route"]На R2 отключение добавленного разрешения:
/ip firewall filter disable [find where comment="AVG-VPNPF-forward-r2"]Это откат только элементов примера, а не всех предварительных изменений allowed-address или порядка правил. Их исходные значения нужно записать отдельно. Существующие conntrack-сессии могут сохранять NAT после отключения правил: для полного прекращения тестового соединения завершите его и при необходимости удалите только проверенную запись. Не отключайте маршрут, если его уже используют другие сервисы.
Приёмка включает запрос приложения из разрешённой внешней сети, отказ для неразрешённого источника, проверку ответа через R1, отсутствие побочных изменений в филиале и тест без sniffer. Зафиксируйте версии RouterOS, итоговый порядок правил, результаты и способ возврата.
Примеры сверены с документацией RouterOS; это шаблон конфигурации для указанной топологии, а не отчёт о тестировании вашей сети. Для внедрения под действующий firewall обратитесь в АВАНГАРД ИТ.