Два MikroTik: резервный канал без двойного NAT

Чтобы при использовании резервного канала 192.168.10.0 не появлялся двойной NAT, маскарадинг нужно выполнять только на том MikroTik, который реально уходит в интернет; роутер‑пересыльщик по линку 192.168.10 должен явно исключаться из src‑nat. Простое и надёжное решение — привязать masquerade к реальным WAN‑интерфейсам и добавить mangle‑правило (mark‑connection) + верхнее srcnat‑исключение для трафика, идущего через link между A и B. Ниже — мотивировка, проверенные варианты (быстрый фикс и надёжная схема), готовые команды для RouterOS и тесты.

---

Содержание

• Проблема — почему возникает двойной NAT
• Принцип решения: NAT только на egress‑роутере
• Быстрый фикс — ограничить masquerade по интерфейсу
• Надёжное решение: mark‑connection + исключение из srcnat (рекомендуется)
• Опция: policy‑routing (routing‑mark) + NAT по routing‑mark (сложнее, но гибче)
• 1:1 NAT и доступность сервисов при failover — что учесть
• Тестирование и отладка — команды и чеклисты
• Источники
• Заключение

---

Проблема — почему возникает двойной NAT

При текущей настройке оба устройства делают masq (маскарадинг) — на A и на B. Почему так бывает? Часто из‑за одной из причин:

• правило src‑nat написано слишком общо (например, по src‑address) и не связано с реальным WAN‑интерфейсом, поэтому маскарадинг выполняется для любого исходящего трафика, в том числе того, что уходит по линку 192.168.10;
• интерфейс между роутерами случайно добавлен в interface‑list WAN; тогда правило out‑interface-list=WAN маскирует и трафик, идущий к соседу;
• порядок правил NAT позволяет сначала примениться маскарадингу на роутере‑пересыльщике, а затем — на egress‑роутере.

В итоге: клиент из 192.168.1.0/24 → A → (перенаправлен в сторону 192.168.10.2) → B → интернет — и оба роутера делают SNAT, получаем double NAT. Это причиняет проблемы с трассировкой, VoIP, UPnP, играми и пр.

Источник с похожими подходами и примерами политики и mangle: MikroTik Wiki и практические инструкции (см. ниже) — полезно сверяться при адаптации конфигурации: https://mikrotik.wiki/wiki/Готовые_решения:Настройка_двух_Интернет-каналов_(резервирование)

---

Принцип решения: NAT только на egress‑роутере

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

1. Жёстко привязать masquerade к реальным WAN‑интерфейсам (out-interface или out-interface-list=WAN) и убедиться, что link 192.168.10 не включаетcя в WAN list. (быстрый фикс)
2. На роутере‑источнике пометить соединения, которые будут идти по линку к соседу (mangle mark‑connection в chain=forward либо prerouting), и добавить сверху в таблицу NAT правило, которое запрещает SNAT для таких connection‑mark; затем оставить маскарадинг только на локальном WAN. (рекомендуется)
3. (Опционально, более сложный) Ввести policy‑routing (routing‑mark) для явного контроля, по каким таблицам идёт трафик, и делать src‑nat только для пакетов с определённым routing‑mark. Это даёт гибкость (несколько провайдеров, тонкая маршрутизация), но требует аккуратного управления failover (check‑gateway/netwatch или скрипты). Подробнее — примеры решения и разъяснения в презентациях MUM и статьях: https://mum.mikrotik.com/presentations/RU16/presentation_3819_1475562317.pdf

В большинстве реальных развертываний сочетание (1) + (2) даёт надёжный результат без сложных скриптов.

---

Быстрый фикс — ограничить masquerade по интерфейсу

Если вам нужно срочно убрать двойной NAT — выполните простые изменения:

• Убедитесь, что интерфейс между роутерами (например, ether3) НЕ в interface list WAN.
• Удалите или замените универсальные правила srcnat (например, по src‑address) и сделайте маскарадинг только на физическом WAN‑интерфейсе.

Пример (адаптируйте имена интерфейсов под вашу схему):

Для MikroTik A (предположим: ether1 = ISP1, ether2 = LAN‑bridge (192.168.1.0/24), ether3 = link to B 192.168.10.1):

/interface list add name=WAN
/interface list member add interface=ether1 list=WAN # только ISP интерфейс в WAN

/ip firewall nat remove [find comment=“old-masq”] # аккуратно — сначала просмотрите список
/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade comment=“masquerade on ISP1”

Для MikroTik B (ether1 = ISP2, ether2 = LAN2, ether3 = link to A):

/interface list add name=WAN
/interface list member add interface=ether1 list=WAN

/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade comment=“masquerade on ISP2”

Проверьте, что интерфейс ether3 (192.168.10.x) НЕ в list WAN. Это часто решает проблему. Но если исходные правила были более хитрыми, лучше перейти к варианту с mangle (см. ниже).

Источник с похожим советом: https://www.dmosk.ru/miniinstruktions.php?mini=mikrotik-reserv

---

Надёжное решение: mark‑connection + исключение из srcnat (рекомендуется)

Схема: помечаем соединения, которые будут идти на соседний роутер (через inter‑router link), и добавляем в начало таблицы NAT правило, которое запрещает SNAT для этих соединений. Остальные (обычные) пакеты маскируются на локальном WAN.

Пример конфигурации (точно адаптируйте имена интерфейсов под вашу сеть):

MikroTik A (исходные сети: LAN A = 192.168.1.0/24, linkA = ether3 = 192.168.10.1, ISP = ether1):

/ip firewall mangle
add chain=forward src-address=192.168.1.0/24 out-interface=ether3 action=mark-connection new-connection-mark=toB_conn passthrough=yes comment=“mark conn if will be forwarded to B”

/ip firewall nat
add chain=srcnat connection-mark=toB_conn action=accept comment=“do NOT NAT traffic forwarded to B (top rule)”
add chain=srcnat out-interface=ether1 action=masquerade comment=“masquerade only on ISP1”

MikroTik B (LAN B = 192.168.2.0/24, linkB = ether3 = 192.168.10.2, ISP = ether1):

/ip firewall mangle
add chain=forward src-address=192.168.2.0/24 out-interface=ether3 action=mark-connection new-connection-mark=toA_conn passthrough=yes comment=“mark conn if will be forwarded to A”

/ip firewall nat
add chain=srcnat connection-mark=toA_conn action=accept comment=“do NOT NAT traffic forwarded to A (top rule)”
add chain=srcnat out-interface=ether1 action=masquerade comment=“masquerade only on ISP2”

Пояснения:

• mark‑connection в chain=forward настраивается для пометки именно пробрасываемых (forwarded) соединений; мы смотрим на out‑interface=link. Если пакет будет отправлен к соседу, соединение помечается.
• Первое правило в srcnat (connection-mark=…) «принимает» (accept) пакет в контексте таблицы NAT — то есть дальше маскарадинг для этого соединения не выполняется на данном роутере.
• Второе правило маскирует всё, что реально уходит в провайдера (out‑interface=ISP).
• Если трафик идёт A→B→ISP2, он не маскируется на A (благодаря accept), и маскируется один раз на B. Аналогично в обратном направлении.

После внесения правил убедитесь, что правило с connection‑mark стоит выше (раньше) правила masquerade. Команды /ip firewall nat print помогут проверить порядок — в случае необходимости переместите правило: /ip firewall nat move 0

Этот подход описан и обсуждается в практических решениях MikroTik (пример подхода mangle+policy): https://mikrotik.wiki/wiki/Готовые_решения:Настройка_двух_Интернет-каналов_(резервирование) и в разборе failover/notification: https://mum.mikrotik.com/presentations/RU16/presentation_3819_1475562317.pdf

---

Опция: policy‑routing (routing‑mark) + NAT по routing‑mark (сложнее, но гибче)

Если вы используете несколько WAN и хотите явно управлять, какой трафик идёт через какого провайдера, используйте routing‑mark (PBR). Тогда NAT можно привязать к routing‑mark (или к out‑interface). Это полезно при сложной балансировке/политиках.

Пример (упрощённо):

/ip firewall mangle
add chain=prerouting src-address=192.168.1.0/24 dst-address=!192.168.10.0/24 action=mark-routing new-routing-mark=to_ISP1 passthrough=yes

/ip route
add dst-address=0.0.0.0/0 gateway=<ISP1_GW> routing-mark=to_ISP1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=192.168.10.2 distance=2

/ip firewall nat
add chain=srcnat routing-mark=to_ISP1 action=masquerade comment=“masq when routing-mark=to_ISP1”

Минусы и нюансы:

• Требуется корректная настройка маршрутов с routing‑mark и внимательное тестирование failover (check‑gateway/netwatch или скрипты для переключения).
• Это даёт большую гибкость, но и повышает сложность (см. презентацию MUM для примеров автоматизации): https://mum.mikrotik.com/presentations/RU16/presentation_3819_1475562317.pdf

---

1:1 NAT и доступность сервисов при failover — что учесть

Если у вас есть серверы в LAN A и важно сохранить публичный IP при переключении на B — простого способа «поделиться» публичным IP между разными провайдерами нет без BGP/аренды IP или DNS‑фейловера. Возможные варианты:

• На B сделать src‑nat (1:1) для исходящих соединений из нужного хоста A, чтобы исходящие пакеты имели публичный IP B; команда пример:
  /ip firewall nat add chain=srcnat src-address=192.168.1.100 action=src-nat to-addresses=<B_public_IP> comment=“1:1 SNAT для hostA”
  Это решает исходящий NAT, но входящие подключения на старый IP A будут недоступны, если DNS не переключён.
• Для входящих сервисов — используйте динамический DNS, DNS‑failover или внешний балансировщик; либо арендованный IP/транзит (BGP) — это выходит за RouterOS.

Источник с практическими замечаниями по 1:1 и NAT: https://serveradmin.ru/rezervnyj-wan-kanal-v-mikrotik-i-pereklyuchenie-na-nego/

---

Тестирование и отладка — команды и чек‑листы

После внесения изменений проверьте порядок и попадание правил:

• Просмотр правил NAT и порядка:
  /ip firewall nat print

• Просмотр mangle и connection‑marks:
  /ip firewall mangle print
  /ip firewall connection print where connection-mark=toB_conn

• Отладка: инициируйте исходящий трафик из LAN A (например, curl или ping к 8.8.8.8) и на обоих роутерах смотрите active connections и адрес источника перед/после NAT. На B ожидаете, что source будет 192.168.1.x до NAT и уже B_public после NAT.

• Удаление состояния соединений после правок (иначе старые connection entries могут мешать тестам):
  /ip firewall connection remove [find where src-address~“192.168.1.”]

• Тесты failover:

1. Отключите WAN1 на A — A начнёт слать трафик через 192.168.10.2 (distance=2).
2. На A убедитесь, что connection‑mark для новых соединений ставится и что A не делает masq (см. /ip firewall nat counters).
3. На B убедитесь что masq срабатывает (счётчик правил NAT) и внешний IP — B_public.

Полезные команды для проверки:

• /ip firewall nat print stats
• /ip firewall connection print where src-address~“192.168.1.”
• /tool sniffer quick ip-protocol=icmp (проследить ICMP)

Если видите, что оба роутера маскируют — вернитесь к проверке: 1) порядок правил NAT; 2) interface‑lists (link не должен быть в WAN); 3) совпадение имён интерфейсов в правилах (частая ошибка).

---

Источники

1. MikroTik Wiki — Настройка двух интернет‑каналов (резервирование)
2. MUM‑презентация: Резервирование каналов и уведомления
3. Практическая инструкция: Настройка резервирования на MikroTik (dmosk)
4. Примеры и скрипты: резервный WAN в MikroTik (serveradmin)
5. Практическое описание настройки двух провайдеров и резервного канала (weblance)

---

Заключение

Коротко: самый быстрый и безопасный путь убрать двойной NAT — сделать masquerade жёстко привязанным к реальным WAN‑интерфейсам и убедиться, что линк 192.168.10 не маркирован как WAN. Для надёжности рекомендую добавить mangle (mark‑connection) + верхнее srcnat‑исключение для трафика, который будет уходить через соседний роутер — тогда NAT будет выполняться ровно один раз, на том MikroTik, который реально выходит в интернет. Если нужна более сложная логика (policy routing, сохранение публичных IP) — переходите к routing‑mark и/или 1:1 SNAT, но учтите дополнительные сложности и тестирование (check‑gateway/netwatch, DNS/входящие сервисы). Указанные команды можно использовать как шаблон — адаптируйте имена интерфейсов и сети под вашу топологию и протестируйте на внепиковом окне.