Mikrotik VPN с настройкой IKEv1

Во-первых, нельзя сделать 1:1 NAT между двумя /24 с одной стороны и одним /24 с другой стороны. Поэтому вам потребуется еще одна подсеть-алиас, например 10.10.10.0/24. Во-вторых, в netmap нет никакой магии, просто помните, что его нужно использовать в обеих цепочках: chain=srcnat и chain=dstnat, чтобы достичь полной прозрачности между подсетями, т.е. клиенты на одном конце VPN-туннеля могли инициализировать соединения с серверами на другом конце и наоборот. Если нет необходимости в полной прозрачности и все клиенты находятся на вашей стороне, то в netmap нет смысла, и вы можете использовать обычный src-nat, скрывая обе подсети за одним адресом. В-третьих, действие правила происходит только в том случае, если пакет соответствует всем условиям соответствия, так что вы можете использовать netmap для каждой подсети выборочно, только если удаленный конец соединения находится в какой-то подсети, доступной через VPN: /ip firewall nat add chain=srcnat src-address=172.16.1.0/24 dst-address-list=remote-vpn-subnets action=netmap to-addresses=10.10.10.0/24 add chain=srcnat src-address=172.16.2.0/24 dst-address-list=remote-vpn-subnets action=netmap to-addresses=10.10.33.0/24 add chain=dstnat dst-address=10.10.10.0/24 src-address-list=remote-vpn-subnets action=netmap to-addresses=172.16.1.0/24 add chain=dstnat dst-address=10.10.33.0/24 src-address-list=remote-vpn-subnets action=netmap to-addresses=172.16.2.0/24 Я намеренно ссылаюсь на src-address-list/dst-address-list, а не на in-interface/out-interface, потому что мы говорим здесь о чистом IPsec. Правила выше должны быть на правильных позициях в своих соответствующих цепочках, чтобы их не затеняли более общие правила.

Что я не написал изначально, так это то, что настройки netmap выше позволяют удаленной стороне взаимодействовать только с вашими 172.16.1.0/24 и 172.16.2.0/24. Но если вашей стороне нужно общаться с 172.16.1.0/24 и 172.16.2.0/24 на их стороне, нужно использовать другой набор правил netmap, помимо тех, что уже показаны, чтобы назначить некоторые псевдонимы удаленным 172.16.1.0/24 и 172.16.2.0/24, которые не конфликтуют ни с чем на вашей стороне. Это можно сделать на вашей стороне, но это намного сложнее, чем если сделать это на удаленной, потому что dst-nat выполняется только тогда, когда пакет поступает в маршрутизатор, а src-nat только когда пакет покидает маршрутизатор. Вам нужно будет использовать политику маршрутизации (которая не имеет ничего общего с политиками IPsec), чтобы предотвратить маршрутизацию пакетов с вашей локальной сети обратно в локальную сеть после того, как они будут подвергнуты dst-nat к 172.16.[12].0/24 сразу при входе в маршрутизатор, и политики IPsec должны быть ограничены конкретными удаленными направлениями, иначе ваш локальный трафик может быть украден из-за этих политик.

Да, но в данном сценарии (хост с вашей стороны является инициатором/клиентом, а хост на удаленной стороне является респондентом/сервером) правило action=netmap в цепочке srcnat на вашей стороне гарантирует, что респондент/отправитель увидит запрос как исходящий от 10.10.10.5. Поэтому удаленный хост ничего не знает о 172.16.1.5 с вашей стороны, он видит только 10.10.10.5. Не знаю, в курсе ли вы, как работает NAT, но цепочки src-nat и dst-nat таблицы NAT рассматриваются только для первого пакета каждого соединения, и если правило в соответствующей таблице совпадает и задает действие NAT, то необходимая обработка (src-nat, dst-nat или оба) фиксируется в контексте, связанном с этим отслеживаемым соединением, так что все последующие пакеты, относящиеся к этому соединению, обрабатываются аналогичным (или зеркальным, в зависимости от их направления) образом. Таким образом, ответы на src-nated запросы автоматически становятся "un-src-nated".