Назад | Перейти на главную страницу

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

Я только что настроил сервер Ubuntu как маршрутизатор с NAT / PAT и пытаюсь сделать следующее:

Я работаю в школе, которая разделила свою сеть на более мелкие сети, соединенные маршрутизаторами. Мне нужно создать IP-адрес, видимый во внутренней сети одной комнаты, который будет перенаправлять весь трафик на внешний IP-адрес.

Чтобы пояснить, это конфигурация:

NAT снаружи: eth1 - 192.168.1.254/24

NAT внутри: br0 - 192.168.2.10, маскировка включена

Мне нужно создать адрес, например 192.168.2.1, также для br0, который будет перенаправлять весь свой трафик на ip 192.168.1.1 и будет выглядеть так, как если бы этот IP-адрес напрямую подключен к сети, но на нем НЕ был бы включен маскарадинг. .

Основная идея состоит в том, что адрес маршрутизатора br0 должен быть установлен на 192.168.2.10, а также br0, чтобы иметь другой адрес, который не маскируется, и перенаправляет весь трафик на 192.168.1.1, который является адресом основного маршрутизатора. Причина этого в том, что br0 - это мост между физической сетью и VPN, доступ к которому будет осуществляться из-за маршрутизатора с тем же адресом, что и IP-адрес назначения NAT - 192.168.1.1. Поскольку я не могу гарантировать, что клиенты всегда могут выполнить команду «добавить маршрут», мне нужен способ обойти это.

Я узнал, как настроить вторичные IP-адреса для br0, и я настроил br0: 1 как 192.168.2.1, но я не могу перенаправить весь трафик на него на 192.168.1.1.

Заранее благодарю вас за вашу помощь.

То, что вы пытаетесь сделать, если я правильно вас понимаю, на самом деле является формой маршрутизации политики с участием некоторого 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 команда. Не используйте сетевые инструменты (ifconfig); он древний и лишен многих функций, и в конечном итоге вызовет у вас только головную боль.