NAT доступ извне к одному и тому же локальному хосту через два независимых маршрутизатора

[driver_x]

Всех приветствую.
Прошу подсказки в решении задачи, которая для меня оказалась не такой просто как ожидалось.

Имеется маршрутизатор MikroTik ROSv6 (далее R1) с WAN интерфейсом и публичным адресом на нём (например 111.112.113.114), а также локальным интерфейсом и приватным адресом на нём (10.1.1.1/24). В локальной сети расположен хост (Server) с адресом 10.1.1.2/24, на котором определённый сервис прослушивает TCP порт (например 12345). Для доступа к этому хосту извне по публичному адресу и порту 12345 на R1 имеется правило DNAT. Такое решение успешно работает как и ожидается.

Не так давно возникла необходимость переноса хоста Server на другую локацию, которую обслуживает свой маршрутизатор, также MikroTik ROSv6(далее R2). Он имеет собственный публичный адрес (предположим 211.212.213.214) и выделенную под Server новую локальную сеть. В новой конфигурации предусмотрен такой же DNAT с внешнего адреса по TCP порту, согласно новой адресации. Сложность заключается в том, что этот Server будет переноситься последним из пула других хостов и на какое-то время он должен быть доступен как по текущему публичному адресу и порту 111.112.113.114:12345 так и по новому выделенному 211.212.213.214:12345 и сохранять текущий локальный адрес 10.1.1.2/24.

Для этих целей был настроен GRE тоннель между публичными адресами R1 и R2, назначены внутренние адреса 10.254.1.1/30 и 10.254.1.2/30 соответственно и добавлены маршруты в их локальные сети с двух сторон. Т.е. c R2 хост Server достижим по его текущему адресу 10.1.1.2. Задумка была следующая: входящие обращения на публичный адрес R2 по порту 12345 DNAT'ом пробрасывать через GRE на Server (одним правилом DNAT добавленным на R2). Очевидно отвечать нужно через тот же интерфейс маршрутизатора R1 (GRE интерфейс) с которого приходят запросы. Здесь уже без PBR не обойтись. В деталях диаграмму прохождения пакетов не понимаю, поэтому в моём представлении достаточно было двух правил Mangle на R1. 1. Использовать connection mark согласно заданным критериям. 2. Использовать mark routing на основании уже промаркированных соединений. Ну и добавить маршрут с соответствующим routing mark в GRE, чтобы пакеты по нему уходили обратно на R2.
Итого на R1 в IP=>Firewall=>Mangle
1.
chain=prerouting action=mark-connection new-connection-mark=conn-R2 passthrough=yes connection-state=new protocol=tcp dst-address=10.1.1.2 connection-mark=no-mark in-interface=gre-R2 dst-port=12345
2.
chain=prerouting action=mark-routing new-routing-mark=routing-R2 passthrough=no connection-mark=conn-R2
В таблице маршрутизации
dst-address=0.0.0.0/0 gateway=10.254.1.2 distance=1 scope=30 target-scope=10 routing-mark=routing-R2

Других правил Mangle или маршрутов с маркировкой в конфигурации нет.

В результате при обращении на внешний IP R2 соединение не устанавливается. В разделе Connections множество соединений с состоянием SYN SENT как на R1 так и на R2. Похоже ответа SYN ACK от хоста Server не происходит или он не доходит до источника. Вероятно это связано с моим непониманием что именно происходит с пакетами на каждом этапе при прохождении через R1.
Просьба указать куда копать.

Добавлю, что проблема не в фильтрации трафика на каком-то из участков, т.к. этот проект моделировался в том числе в EVE-NG лабе на микротах без дефолтной конфигурации, только с необходимым минимумом. Результат аналогичен конфигурации на реальном железе.
Если в таблицу маршрутизации R1 добавить маршрут к конкретному клиентскому внешнему IP с которого происходит подключение к R2, то соединение устанавливается (при условии, что маршрут с маркировкой conn-R2 отключен).

Возможно получилось сумбурно, поэтому во вложении прилагаю диаграмму топологии. На скрине diag02 цветными линиями упрощённо показан путь по которому, в моём понимании должны проходить пакеты.
Буду рад любым конструктивным комментариям на эту тему или альтернативным решениям.

[Chupaka]

2.
chain=prerouting action=mark-routing new-routing-mark=routing-R2 passthrough=no connection-mark=conn-R2

Здравствуйте. Это правило отправляет все пакеты соединения обратно в R2. Соединение TCP - двустороннее, и вам надо отправлять только то, что пришло от сервера. Допишите в правило какое-нибудь in-interface=!gre-R2, чтобы пришедшие от R2 пакеты не заворачивались обратно.

[driver_x]

Здравствуйте. Это правило отправляет все пакеты соединения обратно в R2. Соединение TCP - двустороннее, и вам надо отправлять только то, что пришло от сервера. Допишите в правило какое-нибудь in-interface=!gre-R2, чтобы пришедшие от R2 пакеты не заворачивались обратно.

Добрый день. Спасибо за отклик! Действительно, этот момент не учёл. С данной поправкой соединение работает как и должно.
Ещё раз спасибо!