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

Путаница в нескольких VLAN и группах пользователей

Развертываю и проектирую новую сеть для нашей сильно поврежденной конструкции. Я никогда не проектировал сеть с нуля самостоятельно. Вот простой пример:

Проблема, которая меня смущает, заключается в том, что я не хочу разрешать обычным пользователям доступ к продукту. но мне нужно разрешить им доступ к Exchange, Citrix, IM и нескольким другим серверам, которые классифицируются как производственные. Как люди обычно это делают? Могу ли я просто назначить там доступ к порту для VLAN 1, что вроде бы побеждает цель их наличия, или я должен отделить серверы, которые нужны обычным пользователям, и поместить их в VLAN 2? Моя последняя мысль: разрешить ли я им только внешний доступ к обмену, то есть RPC или HTTP?

Спасибо, парни

Короче говоря, устройства, которые маршрутизируют трафик между вашими различными подсетями (назначенными различным VLAN), должны применять политику безопасности связи. Как минимум, это означает использование маршрутизаторов (или устройств с функциями маршрутизатора), которые поддерживают списки управления доступом без сохранения состояния. Если вы хотите стать более привлекательным, вы можете использовать устройства с функцией фильтрации с отслеживанием состояния (типичные межсетевые экраны с отслеживанием состояния, iptables Linux и т. Д.).

Я думаю, у вас может быть упрощенное представление о том, что значит запретить «нормальным пользователям доступ к производственной среде». Путь, по которому вы идете, включает в себя схему различных протоколов (обычно портов TCP и UDP), с которыми клиентские приложения должны будут взаимодействовать на серверных компьютерах (некоторые из которых в случае Microsoft RPC являются динамическими по умолчанию. ). Как только вы выясните, как эта связь должна работать, вы создаете списки контроля доступа (или правила брандмауэра), чтобы разрешить требуемую связь, запрещая весь другой трафик.

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

В конце концов, вы можете обнаружить, что вам больше повезет с запуском правил брандмауэра на основе хоста и довольно снисходительным отношением к спискам управления доступом внутри VLAN / правилам брандмауэра, не обязательно потому, что это правильно, а потому что это выполнимо. делать. Удачи!

В качестве отступления: просмотр ваших запланированных подсетей, увеличивающихся в степени 10 в третьем октете, говорит о том же, что и ваше утверждение: «Я никогда не проектировал сеть с нуля, сам». Если вы хотите оставить место для роста в этих подсетях, подумайте о чем-то более похожем:

  • 10.10.0.0 / 19
  • 10.10.32.0 / 19
  • 10.10.64.0 / 19
  • 10.10.96.0 / 19

Даже если вы начнете использовать эти различные подсети как / 24, у вас будет место для каждой из них, чтобы вырасти до / 19 (с 4/19, доступными для будущего использования). С несмежными подсетями, которые вы предлагаете в своем ответе, вы тратите впустую пространство IP или создаете сети, которые нельзя суммировать с помощью одного маршрута CIDR.

Разумный план разделить ваши серверы по VLAN, но я согласен с @Evan в том, что попытка сделать это по портам практически невозможна, держите серверы для «реальных» пользователей полностью отдельно от серверов, используемых для разработки. Разработчики возненавидят это, но если возможно, полностью отключите их и их среду тестирования / разработки.

Технически было бы лучше избегать использования VLAN 1 для всего, что связано с пользователями или серверами, она часто используется как VLAN по умолчанию для ваших сетевых устройств.

Зависит от количества пользователей, но иметь хоть одного почти всегда плохо, даже если это «просто» DHCP-сервер.

Я в основном согласен с @Evan насчет подсетей, но не стал бы слишком увлекаться подсетями и придерживался / 24s. Если вам нужно больше хостов, добавьте еще одну VLAN, поэтому они существуют, и наличие дизайна, в котором вы не можете (или это слишком сложно) добавить еще один, является фундаментальным недостатком, который следует устранить как можно раньше.

Соглашение о нумерации для VLAN также должно отличаться от 1 (!), 2,3,4, использовать отдельные диапазоны для пользователей, серверов и разработчиков.