Перенаправление трафика на IPIP-туннель

Маршрутизатор не может отправить пакет с исходным IP A на целевой IP B, а затем получить ответный пакет на тот же целевой IP B, но уже с исходным IP C. Если ответный трафик отправляется на публичный IP маршрутизатора и не возвращается через туннель, маршрутизатор не сможет понять, на какой внутренний IP-адрес локальной сети нужно перенаправить этот трафик, потому что нет NAT-действия, чтобы это отменить.

Наверное, можно попробовать сделать исходящий NAT пакета через туннель на WAN-IP маршрутизатора с помощью src-nat и указания конкретного to-адреса (но при этом будет потерян внутренний исходный IP, как его видит другая сторона — от этого IPIP-туннель вообще теряет смысл). Однако я почти уверен, что трекинг соединений учитывает интерфейсы и всё равно отбросит возвратный трафик, если он придёт с неправильного интерфейса (WAN вместо туннеля).

Честно говоря, я думаю, что то, что ты пытаешься сделать, невозможно. А зачем тебе односторонний туннель?

Если вы делаете NAT через туннель, как он может быть односторонним? NAT подразумевает, что исходящий адрес на другом конце туннеля — это IP-адрес интерфейса туннеля. В вашем случае это приватный IP, значит ответный трафик должен идти обратно через туннель, иначе приемник будет недоступен. Моя работа — на 90% Cisco. Может быть, если вы выложите конфигурацию Cisco-to-Cisco, я смогу помочь. Я не занимаюсь контрактами, поэтому не могу обещать оперативный ответ.

Понятно.  
/ip firewall nat  
add chain=srcnat out-interface=ipip1 action=src-nat to-address=222.154.xxx.15  

Это выполняет такой же тип NAT, как и ваши маршрутизаторы Cisco. Однако я совсем не уверен, что это сработает на RouterOS. Попробуйте — может и получится. Вы уже отправляете трафик через IPIP-туннель, а это правило NAT выполнит такое же преобразование исходящего адреса, как на Cisco, так что этот участок вы полностью дублируете.  

Мне кажется, что хотя стек NAT Cisco, видимо, может обработать обратный трафик, стек NAT RouterOS может не суметь «понять», что этот обратный трафик относится к тому же соединению. Я думаю, что отслеживание соединений (connection tracking), отвечающее за привязку пакетов к потокам, а значит — за правильное «откат» исходящего NAT на обратном пути, тоже учитывает входящие и исходящие интерфейсы при принятии решения.  

Поскольку входящий интерфейс для обратного трафика не совпадает с исходящим интерфейсом, через который ушёл исходный пакет, этот обратный трафик могут просто отбросить из-за невозможности сопоставить его с каким-либо потоком.  

Однако могу ошибаться полностью и безвозвратно, так что попробовать точно стоит. Если не сработает, то я не вижу, как можно реализовать ваше Cisco-решение на RouterOS, просто потому что стеки NAT у них немного отличается по функционалу.

Так что обратный трафик всё же проходит? Просто хочу уточнить, потому что это полезно знать.