Метод реструктуризации сети для сети Double-NAT

Из-за ряда неудачных решений по проектированию сети (в основном), принятых много лет назад, чтобы сэкономить несколько долларов, у меня есть сеть, которая определенно неоптимально спроектирована. Я ищу предложения по улучшению этой менее приятной ситуации.

Мы некоммерческая организация с ИТ-отделом на базе Linux и ограниченным бюджетом. (Примечание. Ни одно из оборудования Windows, которое у нас работает, не выполняет никаких действий, связанных с Интернетом, и у нас нет администраторов Windows.)

Ключевые моменты:

• У нас есть главный офис и около 12 удаленных сайтов, которые по сути удваивают NAT своих подсетей с физически разделенными коммутаторами. (Нет VLAN и ограниченные возможности сделать это с текущими коммутаторами)
• Эти местоположения имеют подсеть «DMZ», которая настроена на NAT в идентично назначенной подсети 10.0.0 / 24 на каждом сайте. Эти подсети не могут общаться с DMZ в любом другом месте, потому что мы не направляем их куда-либо, кроме как между сервером и смежным «брандмауэром».
• В некоторых из этих местоположений есть несколько подключений ISP (T1, Cable и / или DSL), которые мы вручную маршрутизируем с помощью IP Tools в Linux. Все эти брандмауэры работают в сети (10.0.0 / 24) и в основном представляют собой брандмауэры класса «pro-sumer» (Linksys, Netgear и т. Д.) Или предоставленные ISP модемы DSL.
• Подключение этих брандмауэров (через простые неуправляемые коммутаторы) представляет собой один или несколько серверов, которые должны быть общедоступными.
• К подсети 10.0.0 / 24 главного офиса подключены серверы для электронной почты, VPN для удаленных сотрудников, VPN-сервер удаленного офиса, основной маршрутизатор для внутренних подсетей 192.168 / 24. Это должен быть доступ из определенных подключений интернет-провайдера в зависимости от типа трафика и источника подключения.
• Вся наша маршрутизация выполняется вручную или с помощью операторов маршрута OpenVPN.
• Межведомственный трафик проходит через службу OpenVPN на главном сервере «Маршрутизатор», который имеет собственный NAT.
• Удаленные сайты имеют только один сервер, установленный на каждом сайте, и не могут позволить себе несколько серверов из-за бюджетных ограничений. Все эти серверы являются LTSP-серверами по 5-20 терминалов.
• Подсети 192.168.2 / 24 и 192.168.3 / 24 в основном, но НЕ полностью на коммутаторах Cisco 2960, которые могут выполнять VLAN. Остальные - коммутаторы DLink DGS-1248, которым я не уверен, что достаточно доверяю для использования с VLAN. Существует также некоторая внутренняя озабоченность по поводу сетей VLAN, поскольку только старший сотрудник сети понимает, как это работает.

Весь обычный интернет-трафик проходит через сервер-маршрутизатор CentOS 5, который в свою очередь превращает NAT из подсетей 192.168 / 24 в подсети 10.0.0.0/24 в соответствии с настроенными вручную правилами маршрутизации, которые мы используем для направления исходящего трафика на правильное интернет-соединение на основе операторы маршрутизации '-host'.

Я хочу упростить это и подготовить все для виртуализации ESXi, включая эти общедоступные сервисы. Есть ли недорогое или дешевое решение, которое избавило бы от Double-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, но я полагаю, что это все относительно.