Расширенный NAT — микс PAT с NAT

Расширенный NAT — микс PAT с NAT

Я только что настроил Ubuntu Server как маршрутизатор с 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. Поскольку я не могу гарантировать, что клиенты всегда смогут выполнить команду "route add", мне нужен способ обойти это.

Я узнал, как настроить вторичные IP-адреса для br0, и настроил br0:1 как 192.168.2.1, но мне не удаётся перенаправить весь трафик на него на 192.168.1.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команды. Не используйте net-tools (ifconfig); он устарел и не имеет многих функций, и в долгосрочной перспективе только доставит вам головную боль.

Связанный контент