MikroTik: возврат трафика через тот же шлюз, которым он пришёл

Есть роутер MikroTik, на нём настроен port forwarding — пробрасываем какой-нибудь порт на внутренний сервер. Всё работает, пока роутер смотрит в интернет одним шлюзом. Но стоит появиться второму — резервному WAN, VPN-туннелю с BGP-маршрутами, неважно — и начинается классика: соединение устанавливается через WAN1, запрос доходит до сервера, а ответ уходит через WAN2. Клиент видит RST или просто ждёт до таймаута, потому что пакет пришёл с чужого IP.

Клиент → [WAN1] → MikroTik --dstnat--> 192.168.1.10
                                              ↓
Клиент ← [WAN2] ← MikroTik <-----------  ответ

Это асимметричная маршрутизация. Починить её можно аккуратно — не трогая таблицу main и не ломая остальной трафик.

Почему RouterOS так делает

Когда сервер отправляет ответный пакет, RouterOS смотрит в таблицу маршрутизации main и выбирает лучший маршрут до адреса назначения. Если в main несколько дефолтных маршрутов или BGP нагнал туда своих префиксов — роутер вполне законно отправит пакет через другой интерфейс. Он не обязан «помнить», откуда пришёл исходный запрос. Это нормальное поведение для L3-маршрутизатора, которое в данном случае нам мешает.

Решение: отдельная таблица маршрутизации для dstnat-трафика

Идея простая: помечаем только те соединения, которые вошли через WAN1 и прошли через dstnat, и для них принудительно указываем отдельную таблицу с единственным маршрутом — обратно через WAN1. Всё остальное идёт как шло.

Шаг 1 — создать отдельную таблицу маршрутизации

/routing table add name=via-wan1 fib

Шаг 2 — добавить в неё дефолтный маршрут через WAN1

/ip route add \
    dst-address=0.0.0.0/0 \
    gateway=<WAN1_GATEWAY> \
    routing-table=via-wan1

Шаг 3 — пометить нужные соединения через mangle

Здесь два правила, и важно понимать, зачем оба.

Первое правило срабатывает на входе через WAN1 и только на пакеты, которые уже прошли через dstnat. Оно ставит метку на всё соединение целиком:

/ip firewall mangle add \
    chain=prerouting \
    in-interface=<WAN1_INTERFACE> \
    connection-nat-state=dstnat \
    action=mark-connection \
    new-connection-mark=from-wan1-dstnat \
    passthrough=yes \
    comment="Mark dstnat connections from WAN1"

Второе правило работает уже без привязки к интерфейсу — оно ловит все пакеты помеченного соединения, включая ответные, которые приходят со стороны LAN, и проставляет им routing-mark:

/ip firewall mangle add \
    chain=prerouting \
    connection-mark=from-wan1-dstnat \
    action=mark-routing \
    new-routing-mark=via-wan1 \
    passthrough=no \
    comment="Route dstnat replies back via WAN1"

Шаг 4 — связать routing-mark с таблицей

/routing rule add \
    routing-mark=via-wan1 \
    action=lookup \
    table=via-wan1 \
    comment="dstnat reply via WAN1"

Что происходит внутри

Входящий пакет идёт по привычному пути: WAN1 → prerouting → dstnat меняет dst-адрес на 192.168.1.10 → mangle #1 ставит connection-mark=from-wan1-dstnat → mangle #2 ставит routing-mark=via-wan1 → пакет уходит на сервер.

Ответный пакет возвращается с сервера через LAN-интерфейс. В prerouting connection tracking видит, что это соединение помечено как from-wan1-dstnat, mangle #2 снова срабатывает и ставит routing-mark=via-wan1. Дальше routing rule направляет пакет в таблицу via-wan1, там единственный маршрут — через WAN1. В postrouting srcnat/masquerade подставляет публичный IP WAN1. Клиент получает ответ с того же адреса, с которого установил соединение.

Один нюанс, который часто упускают: connection-nat-state=dstnat проверяется уже после применения NAT-правил. К моменту, когда этот матч отрабатывает, RouterOS уже знает, что соединение прошло через dstnat. Именно поэтому первое mangle-правило фильтрует сразу по двум условиям — интерфейс и nat-state.

На что обратить внимание

Fasttrack. Если у вас настроен fasttrack (connection-state=established,related), он может обходить mangle. Это не теоретическая проблема — в типовых конфигурациях fasttrack включён по умолчанию. Убедитесь, что правило mark-routing с passthrough=no стоит в очереди раньше fasttrack, иначе установленные соединения будут проскакивать мимо.

Несколько внешних интерфейсов. Схема хорошо масштабируется: для WAN2 создаёте таблицу via-wan2, дефолт через второй шлюз, и аналогичную пару mangle-правил. Каждый интерфейс живёт в своей таблице, они не мешают друг другу.

BGP. Именно в BGP-окружениях эта проблема проявляется острее всего — BGP может перекрыть маршруты по умолчанию, и таблица main становится непредсказуемой с точки зрения выбора интерфейса. Изолированная таблица via-wan1 на это никак не реагирует.

Проверка

Смотрим, что соединения действительно получают нужную метку:

/ip firewall connection print where connection-mark=from-wan1-dstnat

Проверяем routing rule:

/routing rule print

Проверяем маршрут в изолированной таблице:

/ip route print where routing-table=via-wan1

Если ответные пакеты всё равно уходят не туда — первым делом смотрите порядок правил в mangle (/ip firewall mangle print). Скорее всего, fasttrack стоит раньше нужного правила.

Итог

Четыре команды, никаких изменений в main, остальной трафик не затронут.