Dst-nat при возврате пакета.

[WormBlast]

Перед мной поставлена хитрая задача решить вопрос работы сети при условии что на 2ух интерфейсах микрота одинаковые под-сети. При этом в обеих под-сетях есть устройства с одинаковым IP. инерфейсы могут между собой не общаться, но определённое устройство должно иметь доступ к определённому хосту в соседнем интерфейсе. При этом этот хост именно с тем ip которое есть в нашей же под-сети. Уже не первый день пробую разные варианты. Успешные попытки были, но при этом полностью надёжной и стабильной работы получить не удалось. Придумал идею создать виртуальные ип на роутере и их перенаправлять с помощью маркировки. В итоге получилось так что маркированный (Mark routing) пакет меняет src и dst адреса, отправляет пакет на нужный интерфейс. Хост отвечает на наш подставленный адрес. Пакет возвращается обратно, я его мечу и остаётся только поменять dst на нужный хост. И тут застрял. Обратный dst-nat не в какую не хочет отрабатывать. Что только уже не пробовал. Может кто подскажет как заставить дст-нат работать или другую схему решения вопроса.
Варианты поменять ip хостов или под-сетей не предлагать.
Заранее спасибо за помощь.
Ниже приложу тестовый конфиг последней попытки

Код: Выделить всё

[/interface bridge
add name=bridge_LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/routing table
add fib name=To_10.0.0.100
add fib name="From 0.110"
/interface bridge port
add bridge=bridge_LAN ingress-filtering=no interface=ether2
add bridge=bridge_LAN ingress-filtering=no interface=ether3
add bridge=bridge_LAN disabled=yes ingress-filtering=no interface=ether4
/ip settings
set max-neighbor-entries=8192
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/interface ovpn-server server
set auth=sha1,md5
/ip address
add address=172.16.0.1/24 interface=bridge_LAN network=172.16.0.0
add address=172.16.1.1/24 interface=bridge_LAN network=172.16.1.0
add address=10.10.10.1/24 interface=bridge_LAN network=10.10.10.0
/ip dhcp-client
add interface=ether1
/ip firewall filter
add action=accept chain=forward in-interface=bridge_LAN routing-mark=\
    To_10.0.0.100
add action=accept chain=forward in-interface=ether4 routing-mark="From 0.110"
add action=drop chain=forward in-interface=bridge_LAN out-interface=ether4
add action=drop chain=forward in-interface=ether4 out-interface=bridge_LAN
/ip firewall mangle
add action=mark-routing chain=prerouting comment=Send dst-address=10.0.0.100 \
    new-routing-mark=To_10.0.0.100 passthrough=yes
add action=mark-routing chain=prerouting comment=Recive dst-address=10.0.0.101 \
    new-routing-mark="From 0.110" passthrough=yes
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=dst-nat chain=dstnat routing-mark=To_10.0.0.100 to-addresses=\
    172.16.0.110
add action=src-nat chain=srcnat dst-address=172.16.0.110 out-interface=ether4 \
    to-addresses=10.0.0.101
add action=dst-nat chain=dstnat routing-mark="From 0.110" to-addresses=\
    172.16.0.110
add action=dst-nat chain=dstnat dst-address=10.0.0.101 to-addresses=\
    172.16.0.110
/ip route
add disabled=no dst-address=172.16.0.110/32 gateway=ether4 routing-table=\
    To_10.0.0.100
add disabled=no dst-address=172.16.0.110/32 gateway=bridge_LAN routing-table=\
    "From 0.110"
/system identity
set name=RouterOS
/tool romon
set enabled=yes

На скриншоте видна проблема о которой идёт речь


Тут примерная схема. Схема слегка с лишними извращениями но суть в том что определённое устройство с бриджа должно мочь достучаться до eth4 172.16.0.110/ При этом доступа до хоста 172.16.0.110 у нас нету

[xvo]

Если соединения всегда инициируются только с одной стороны - должно хватить и первых двух правил NAT.
Обратные пакеты для уже открытых соединений и так должны возвращаться к нужным адресам.