Может ли кто-нибудь сказать мне, каковы могут быть последствия наличия двух разных подсетей на одном коммутаторе, если VLAN не быть использованным?
Все будет работать так, как вы ожидаете. По сути, они просто разделяют широковещательный домен. Компьютеры в разных подсетях не будут использовать ARP в подсети, поэтому им все равно потребуется маршрутизатор (или встроенный объект уровня 3 в коммутаторе), чтобы «общаться» друг с другом.
Поскольку они совместно используют широковещательный домен, изоляция намного меньше (возможно, отсутствует), чем при использовании VLAN. Было бы легко подделать хосты ARP и MAC в любой подсети из любой подсети.
Если вы просто делаете это в лабораторных условиях, это, вероятно, нормально. Однако, если вам действительно нужна изоляция в производственном развертывании, вам следует использовать VLAN или отдельные физические коммутаторы.
Если вы не используете VLAN, человек может легко добавить 2 IP-адреса в свой интерфейс, например 192.182.0.1/24 и 172.16.0.1/24 чтобы он или она могли получить доступ к обеим сетям.
Используя VLAN, вы можете пометить порты коммутатора так, чтобы любой компьютер, настроенный для приема трафика только из VLAN, не мог получать какой-либо трафик (кроме направленного на него и имеющего правильную VLAN) независимо от того, как настроен локальный интерфейс ( сколько IP на интерфейсе).
По сути:
Во-первых, я не уверен, зачем вы это делаете для пользователей. Единственный сценарий, который я могу придумать, - это то, что у вас закончились IP-адреса в вашей текущей пользовательской подсети и вы не можете легко расширить текущую подсеть. В этом случае, я думаю, было бы хорошо добавить еще одну подсеть. Спуфинг становится не проблемой, когда вы используете IP-адреса таким образом, потому что обе подсети равны, поэтому у вас одинаковый риск подмены, независимо от того, используете ли вы одну подсеть или несколько. У меня есть один вопрос: как будет работать DHCP? Если ваши DHCP-области не являются смежными, и DHCP-сервер обслуживает IP-адреса на основе «вспомогательного» адреса маршрутизатора, не будут ли все запросы попадать в ту или иную область? Я полагаю, что это может не проблема, если ваш DHCP-сервер находится непосредственно в широковещательном домене, но это все еще есть для исследования.
Тем не менее, я действительно делаю это в продакшене для одного из своих приложений. У меня есть приложение, в котором географически разнесены бункеры, у каждого бункера свой / 27. Эти IP-адреса я считаю IP-адресами инфраструктуры. Они принадлежат этим серверам. Затем я направляю дополнительный / 29 в тот же широковещательный домен. Эта подсеть принадлежит приложению. При следующем обновлении оборудования я построю совершенно новый бункер с новым / 27, а затем изменю маршрут для приложения / 29 на нем. Поскольку этот / 29 обрабатывает связь с сетевыми элементами, это позволяет мне не перепрограммировать все сетевые элементы, если мы получаем новое оборудование или новое программное обеспечение, а использование того же широковещательного домена позволяет мне делать это без выделенного сетевого адаптера.
Мы реализовали это в нашей школе, потому что у нас заканчивались IP-адреса и мы предоставили новую подсеть для беспроводной секции, отлично работает в сети с 3000 пользователей, поскольку быстрое решение является плюсом, я согласен, что мы должны создать vlan, чтобы сохранить безопасность.
DHCP-сервер (Windows) должен иметь две карты nic, подключенные к одному коммутатору (наша виртуальная, поэтому это не имеет значения), чтобы выдавать IP-адреса беспроводной сети, вам придется использовать статические IP-адреса в «старой сети» , он не будет работать с двумя областями DHCP на одном коммутаторе.
Я только что потратил пару лет, пытаясь решить проблему как с телефонной системой poe, так и с компьютерной сетью на одном управляемом коммутаторе. Да, он должен работать без VLAN, но примерно раз в месяц он не работает и сбрасывает коммутатор, вызывая бесконечные проблемы с подключенным оборудованием. (перезагрузка телефонной системы, сброс маршрутизатора и случайный сброс переключателя) Это был кошмар для нас, поскольку мы искали аппаратную проблему, поскольку большинство считают, что переключатель может справиться с этим. Может быть, тупой переключатель, но управляемый переключатель - нет. Я пробовал несколько крупных производителей, и все они случайным образом сбрасывались в течение месяца :(
ВСЕГДА VLAN ВСЕГДА!