Лучший способ сегментировать трафик, VLAN или подсеть?

VLAN и подсети решают разные проблемы. VLAN работают на уровне 2, тем самым изменяя широковещательные домены (например). Принимая во внимание, что подсети являются Уровнем 3 в текущем контексте

Одним из предложений было бы на самом деле реализовать оба

Например, VLAN 10 - 15 для разных типов устройств (Dev, Test, Production, Users и т. Д.)

VLAN 10, у вас может быть подсеть 192.168.54.x/24 VLAN 11, у вас может быть подсеть 192.168.55.x/24

И так далее

Это потребует, чтобы у вас был маршрутизатор в вашей сети, хотя

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

Ваши 200 узлов поместятся в /24, но это, очевидно, не даст вам много возможностей для роста

Судя по всему, вы уже используете разные подсети для разных типов устройств. Так почему бы не придерживаться этого? При желании вы можете привязать каждую подсеть к VLAN. Сегментация уровня 2 приведет к тому, что поведение вашей сети изменится по сравнению с тем, как она ведет себя в настоящее время.

Вы должны изучить потенциальное влияние этого

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

Обычно вы создаете VLAN в Ethernet и сопоставляете IP-подсети 1-к-1 на них. Есть способы этого не делать, но, придерживаясь строго "простого" мира, вы создадите VLAN, придумаете подсеть IP для использования в VLAN, назначите некоторый маршрутизатор IP-адрес в этой VLAN, подключите этот маршрутизатор к VLAN (с физическим интерфейсом или виртуальным субинтерфейсом на маршрутизаторе), подключите некоторые хосты к VLAN и назначьте им IP-адреса в определенной вами подсети, а также направьте их трафик в VLAN и из нее.

Не следует начинать подсеть в локальной сети Ethernet, если у вас нет веских причин для этого. Две лучшие причины:

• Смягчение проблем с производительностью. Локальные сети Ethernet не могут масштабироваться бесконечно. Чрезмерное вещание или переполнение кадров в неизвестные места назначения ограничат их масштаб. Любое из этих условий может быть вызвано слишком большим одиночным широковещательным доменом в локальной сети Ethernet. Широковещательный трафик легко понять, но затопление кадров в неизвестные места назначения немного более неясно. Если вы получаете так много устройств, что ваши таблицы MAC коммутатора переполнены, коммутаторы будут вынуждены заполнять не широковещательные кадры по всем портам, если назначение кадра не соответствует ни одной записи в таблице MAC. Если у вас есть достаточно большой один широковещательный домен в локальной сети Ethernet с профилем трафика, на котором хосты общаются редко (то есть достаточно редко, чтобы их записи устарели из таблиц MAC на ваших коммутаторах), то вы также можете получить чрезмерное переполнение кадров,

• Желание ограничить / контролировать трафик, перемещающийся между хостами на уровне 3 или выше. Вы можете провести некоторую хакерскую проверку трафика на уровне 2 (например, ebtables для Linux), но с этим трудно справиться (поскольку правила привязаны к MAC-адресам, а изменение сетевых карт требует изменений правил), что может привести к действительно странному поведению (выполнение Прозрачное проксирование HTTP на уровне 2, например, странно и забавно, но совершенно неестественно и может быть очень не интуитивно понятным для устранения неполадок), и, как правило, это трудно сделать на более низких уровнях (потому что инструменты уровня 2 подобны ручкам и раскачивается при решении проблем уровня 3+). Если вы хотите контролировать трафик IP (или TCP, или UDP и т. Д.) Между хостами, а не атаковать проблему на уровне 2, вам следует подсеть и прикрепить межсетевые экраны / маршрутизаторы с ACL между подсетями.

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

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

Как только вы узнаете, как движется трафик в вашей локальной сети, вы можете начать думать о подсетях из соображений производительности.

Что касается "безопасности", вам нужно знать много нового о прикладном программном обеспечении и о том, как оно работает, прежде чем вы сможете продолжить.

Несколько лет назад я разработал дизайн LAN/WAN разумного размера для медицинского Заказчика, и меня попросили разместить списки доступа на объекте уровня 3 (модуль супервизора Cisco Catalyst 6509), чтобы контролировать трафик, перемещающийся между подсетями с помощью функции " инженер ", который мало понимал, какого рода работа на самом деле требовалась, но был очень заинтересован в" безопасности ". Когда я вернулся с предложением изучить каждое приложение для определения необходимых портов TCP/UDP и хостов назначения, я получил шокированный ответ от "инженера", заявив, что это не должно быть так сложно. Последнее, что я слышал, они запускают объект уровня 3 без списков доступа, потому что они не могут заставить все свое программное обеспечение работать надежно.

Мораль: если вы действительно собираетесь попытаться получить доступ к пакетному и потоковому доступам между виртуальными локальными сетями, будьте готовы приложить немало усилий с прикладным программным обеспечением и изучить / проанализировать, как это происходит по проводам. Ограничение доступа хостов к серверам часто может быть достигнуто с помощью функции фильтрации на серверах. Ограничение доступа по проводам может дать ложное чувство безопасности и утешить администраторов в самодовольство, когда они думают: "Мне не нужно настраивать приложение безопасно, потому что хосты, которые могут общаться с приложением, ограничены". сеть"." Я бы посоветовал вам проверить безопасность конфигурации вашего сервера, прежде чем я начну ограничивать обмен данными между хостами по проводам.

В 99% случаев подсеть должна быть эквивалентна VLAN (т. Е. Каждая подсеть доступа должна соответствовать одной и только одной VLAN).

Если у вас есть хосты из более чем одной IP-подсети в одной и той же VLAN, вы отказываетесь от назначения VLAN, поскольку две (или более) подсети будут находиться в одном широковещательном домене.

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

Я в основном согласен с Дэвидом Пашли:

1. Я использую один /16 для всего.
   • но он разделен на несколько VLAN, соединенных программным мостом на машине с Linux.
   • на этом мосту у меня есть несколько правил iptables для фильтрации доступа между группами.
   • Независимо от того, как вы сегментируете, используйте диапазоны IP для группировки, это облегчает реструктуризацию и особые случаи.