У меня есть довольно особенная проблема с маршрутизацией и NAT, которую я надеюсь как-нибудь исправить. Внутри моей компании мы запускаем суперсеть типа 192.168.0.0/21 (192.168.0.1 - 192.168.7.254). Все компьютеры имеют эту маску подсети, без необходимости маршрутизации для доступа к любому из других компьютеров внутри этого сегмента.
Для некоторых клиентов мы создали несколько туннелей IPSec между их и нашим межсетевым экраном. Кроме того, некоторые клиенты принимают трафик через туннель только для определенных IP-адресов источника из моей частной сети. Подобно клиенту A, он принимает трафик только на свои серверы (мы должны достичь, например, RDP, SAPGUI и т. Д.), Если источник находится между 192.168.1.1-192.168.1.10. Другой принимает только источник 192.168.3.0/24 и т. Д. Пока я справляюсь с этим, назначая IP-адрес из ответственного диапазона этому конкретному клиентскому ПК. Но сейчас это становится довольно громоздким и меняется в течение одного дня. Пользователь должен подключиться к клиенту A в 9 утра и к клиенту B в 11 утра ....
Чтобы быть более гибким, я подумал о централизации этого, установив какой-то маршрутизатор внутри моей локальной сети, и я сообщаю, что трафик к клиенту A должен проходить через интерфейс A, который имеет IP-адрес требуемого диапазона. Но также и NAT для трафика, чтобы скрыть реальный IP-адрес источника клиента.
Таким образом, я мог бы настроить некоторые конкретные маршруты для определенных пунктов назначения, которые будут проходить через этот маршрутизатор. Я бы устранил необходимость всегда переключать IP-адреса источника клиента в соответствии с потребностями. Но я боюсь, что я не смогу выполнить эту работу, так как моя маршрутизация снова будет из той же самой сети. Это не из моей локальной сети в клиентскую сеть, это делается через IPSec позже на моем брандмауэре, но мне просто нужно скрыть IP-адрес клиента, например 192.169.2.1/21, утверждая, что это 192.168.1.2/21
Любые идеи? Я подумал о Windows RRAS Server, но это хорошо для маршрутизации из одного сегмента в другой. Но внутри той же сети, просто переключая IP.
Я не могу не подчеркнуть, насколько плоха идея запускать / 21 внутренне, ЕСЛИ у вас достаточно хостов, чтобы использовать / 21.
Например, если вам нужен / 21 (2000+ хостов), a / 22 (1000+ хостов) недостаточно. Если вы используете / 21 с 10 хостами, это не имеет значения.
Если это ферма серверов, где широковещательный трафик низкий и понятный, то проблем нет.
Но если (как звучит), если вы используете / 21 с 1049+ рабочими станциями в одной подсети, у вас будут плохие времена. Ваш широковещательный трафик станет кошмаром, пронизанным спамом.
SNAT / MASQUERADING находится в POSTROUTING, поэтому маршрутизация по определению больше не является проблемой.
Вы даже можете изменить таблицу маршрутизации в одной из ваших локальных систем, чтобы она не пыталась доставлять пакеты для 192.168.0.0/21 локально по своей ссылке, а отправляла их на шлюз:
ip route del 192.168.0.0/21
Разумеется, на шлюзе вы должны разрешить пересылку в сети LAN. Но тогда вы можете использовать SNAT даже локально. Это, наверное, веселее, чем тестирование связи с клиентом. :-)