Расширенный NAT - Смешайте PAT с NAT

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

Вы можете создавать правила DNAT без соответствующего SNAT (или маскировки). Причина, по которой это не сделано, заключается лишь в том, что большинство NAT разработано для решения проблемы с подключением, из-за которой адреса на внутренней стороне NAT иначе не могли бы быть направлены извне. Если на самом деле хост 192.168.1.1 имеет маршрут обратно в 192.168.2.0/24 или что-то еще, вы действительно можете просто установить правило DNAT, если я вспомню:

iptables -t nat -A PREROUTING -s 192.168.2.0/24 -d 192.168.2.1 -j DNAT --to 192.168.1.1

Теперь остановитесь на мгновение и пока не делайте этого.

Это работает, когда 192.168.2.1 является адресом назначения (и создает странную причуду, из-за которой адрес, отвечающий на трафик, отличается от исходного пункта назначения). Я не думаю, что это то, что вы хотите сделать, из вашего описания, хотя я честно не уверен. Выполнение DNAT совсем не поможет, если хост 192.168.2.1 должен выступать в качестве маршрутизатора, а не пункта назначения. Если он должен действовать как маршрутизатор, NAT (или PAT) не поможет вообще.

Звучит так, как будто у вас есть VPN-трафик, который в конечном итоге соединяется с этой подсетью 192.168.2.0/24, если я правильно читаю вас и заполняю пробелы, как они есть, и ему нужно выйти в широкий мир или некоторое подмножество это через этот шлюз 192.168.1.1. В этом случае нужно просто назначить 192.168.2.1/24 (который, как я полагаю, вы установили в качестве шлюза по умолчанию на VPN-клиентах) вашему маршрутизатору, убедиться, что переадресация включена, и вы готовы к работе. -VPN-клиентам никогда не нужно беспокоиться о том, что следующий переход будет 192.168.1.1, как и их исходный шлюз не-VPN по умолчанию (домашний шлюз?); они совершенно не знают об этом, когда пакет проходит. Интернет-провайдеры используют такую ​​схему с адресами RFC1918 постоянно, чтобы не тратить случайно недостающие маршрутизируемые адреса; не обязательно, чтобы все маршрутизаторы вдоль пути имели уникальные адреса вообще (хотя, когда они есть, это значительно облегчает поиск неисправностей). Хитрость в том, что конечным точкам TCP-соединения не нужно ничего знать, кроме IP-адреса следующего перехода.

Если вы уже делаете это и у вас возникли проблемы, проверьте путь возврата. Скорее всего, ваш шлюз в 192.168.1.1 не выполняет NAT для этих адресов при отправке их трафика за пределы вашего NAT (который он по-прежнему будет видеть как 192.168.2.0/24), защищает их брандмауэром или не имеет соответствующего маршрута обратно до 192.168.2.0/24.

Если я неправильно понял ваше намерение по обоим пунктам, есть третье, что может вам помочь. Единственный способ указать шлюз в iptables - это цель TEE, которая клонирует пакет и маршрутизирует клон без изменений на некоторый произвольный хост. Однако вам придется как-то иметь дело с неклонированным пакетом. Эту цель можно добавить в цепочку mangle PREROUTING:

iptables -t mangle -A PREROUTING -s 192.168.2.0/24 -j TEE --gateway 192.168.1.1

Это странная вещь; это предназначено для регистрации трафика, а не маршрутизации его. Полагаю, вы могли бы избавиться от исходного пакета на более поздней стадии iptables, хотя это всего лишь беспорядок, и я действительно не рекомендую его.

В качестве случайной точки вы можете добавить дополнительные IP-адреса к интерфейсам, используя ip addr add команда. Не используйте net-tools (ifconfig); он древний и пропускает множество функций, и в долгосрочной перспективе он только даст вам головную боль.