Метод реструктуризации сети для сети с двойным NAT
Из-за ряда неудачных решений по проектированию сети (в основном), принятых много много лет назад, чтобы сэкономить несколько долларов здесь и там, у меня есть сеть с явно неоптимальной архитектурой. Я ищу предложения по исправлению этой неприятной ситуации.
Мы некоммерческая организация с ИТ-отделом на базе Linux и ограниченным бюджетом. (Примечание: ни одно из оборудования Windows, которое у нас работает, не поддерживает связь с Интернетом, и у нас нет в штате администраторов Windows.)
Ключевые моменты:
- У нас есть главный офис и около 12 удаленных сайтов, которые фактически дублируют NAT в своих подсетях с помощью физически изолированных коммутаторов. (Нет VLAN и ограниченная возможность сделать это с текущими коммутаторами)
- Эти местоположения имеют подсеть «DMZ», которая подключена через NAT к идентично назначенной подсети 10.0.0 / 24 на каждом сайте. Эти подсети не могут взаимодействовать с DMZ в любом другом месте, потому что мы не маршрутизируем их куда-либо, кроме как между сервером и соседним «межсетевым экраном».
- В некоторых из этих мест есть несколько подключений к Интернет-провайдеру (T1, кабель и / или DSL), которые мы вручную маршрутизируем с помощью IP Tools в Linux. Все эти брандмауэры работают в сети (10.0.0 / 24) и в основном представляют собой межсетевые экраны «профессионального уровня» (Linksys, Netgear и т. Д.) Или DSL-модемы, предоставляемые провайдером.
- Подключение этих брандмауэров (через простые неуправляемые переключатели) - это один или несколько серверов, которые должны быть общедоступными.
- К подсети 10.0.0 / 24 главного офиса подключены серверы электронной почты, удаленная сеть VPN, VPN-сервер удаленного офиса, основной маршрутизатор для внутренних подсетей 192.168 / 24. Это должен быть доступ от определенных подключений ISP в зависимости от типа трафика и источника подключения.
- Вся наша маршрутизация выполняется вручную или с помощью операторов маршрута OpenVPN.
- Межведомственный трафик проходит через службу OpenVPN на главном сервере «Маршрутизатор», на котором задействовано собственное NAT.
- На удаленных сайтах установлен только один сервер на каждом сайте, и они не могут позволить себе несколько серверов из-за бюджетных ограничений. Эти серверы, все LTSP-серверы, несколько 5-20 терминалов.
- Подсети 192.168.2 / 24 и 192.168.3 / 24 в основном, но НЕ полностью, находятся на коммутаторах Cisco 2960, которые могут работать с VLAN. Остальные - это коммутаторы DLink DGS-1248, которым я не уверен, что достаточно доверяю для использования с VLAN. Существует также некоторая внутренняя озабоченность по поводу виртуальных локальных сетей, поскольку только старший сетевой персонал понимает, как это работает.
Весь обычный интернет-трафик проходит через маршрутизатор-сервер CentOS 5, который, в свою очередь, преобразует подсети 192.168 / 24 в подсети 10.0.0.0/24 в соответствии с настроенными вручную правилами маршрутизации, которые мы используем для направления исходящего трафика на правильное интернет-соединение на основе Операторы маршрутизации '-host'.
Я хочу упростить это и подготовить все для виртуализации ESXi, включая эти общедоступные сервисы. Есть ли недорогое решение, которое избавит от двойного NAT и немного вернет этот беспорядок, чтобы моя будущая замена не преследовала меня?
Базовая схема для главного офиса: 
Вот мои цели:
- Общедоступные серверы с интерфейсами в этой средней сети 10.0.0 / 24 должны быть перемещены в подсеть 192.168.2 / 24 на серверах ESXi.
- Избавьтесь от двойного NAT и поместите всю нашу сеть в одну подсеть. Насколько я понимаю, это то, что нам все равно нужно будет сделать в IPv6, но я думаю, что этот беспорядок стоит на пути.
1.) Прежде чем что-либо еще, уточните свой план IP-адресации. Перенумеровать сложно, но это необходимый шаг для создания работоспособной инфраструктуры. Отложите удобные большие, легко суммируемые суперсети для рабочих станций, серверов, удаленных сайтов (естественно, с уникальными IP-адресами), сетей управления, кольцевых проверок и т. Д. В RFC1918 много места, и цена приемлемая.
2.) Трудно понять, как разместить L2 в вашей сети, основываясь на схеме выше. VLAN может не понадобиться, если у вас есть достаточное количество интерфейсов в различных шлюзах, а также достаточное количество коммутаторов. Как только у вас появится чувство №1, возможно, имеет смысл вернуться к вопросу L2 отдельно. Тем не менее, VLAN не являются особенно сложным или новым набором технологий и не должны быть такими сложными. Некоторое базовое обучение необходимо, но как минимум возможность разделить стандартный коммутатор на несколько групп портов (то есть без транкинга) может сэкономить много денег.
3.) Хосты DMZ, вероятно, должны быть размещены в их собственных сетях L2 / L3, а не объединены с рабочими станциями. В идеале у вас должны быть пограничные маршрутизаторы, подключенные к устройству L3 (другой набор маршрутизаторов? Переключатель L3?), Который, в свою очередь, будет подключать сеть, содержащую ваши внешние серверные интерфейсы (хост SMTP и т. Д.). Эти хосты, вероятно, будут подключаться обратно к отдельной сети или (что менее оптимально) к общей подсети сервера. Если вы правильно расположили свои подсети, то статические маршруты, необходимые для направления входящего трафика, должны быть очень простыми.
3a.) Старайтесь держать сети VPN отдельно от других входящих сервисов. Это упростит мониторинг безопасности, устранение неполадок, учет и т. Д.
4.) За исключением консолидации ваших подключений к Интернету и / или маршрутизации одной подсети через несколько операторов (читай: BGP), вам понадобится промежуточный узел перед граничными маршрутизаторами, чтобы иметь возможность перенаправлять входящий и исходящий трафик соответствующим образом (как Подозреваю, что делаешь в данный момент). Это кажется большей головной болью, чем VLAN, но я полагаю, что все это относительно.