Это касается оценки рисков — настройка VLAN по умолчанию в зоне по умолчанию находится под контролем производителя, а не администратора. Один из рисков, который необходимо оценить, заключается в том, что следующее обновление может добавить или удалить правила по умолчанию в такой сетевой зоне по умолчанию. Другой риск, связанный с предыдущим, заключается в том, что вам может потребоваться контроль над тем, как зоны взаимодействуют друг с другом, но вы можете быть ограничены в этом отношении, даже если не сейчас, то с последующим обновлением. Вы можете упустить эту деталь обновления при чтении примечаний к выпуску. Например, в настоящее время по умолчанию любой VLAN в зоне "Внутренняя" имеет доступ ко всем VLAN в зоне "Внутренняя", VPN-зона имеет доступ к зоне "Внутренняя", а зона DMZ будет возвращать трафик в зону "Внутренняя". Другой риск заключается в том, что схема адресов по умолчанию VLAN в зоне по умолчанию известна, поэтому злоумышленнику будет легче проникнуть в сеть. Перечисленные риски — лишь первые вещи, которые приходят в голову. При тщательной оценке рисков можно будет выявить реальные риски и оценить их в соответствии с типом используемой конфигурации, что облегчит принятие решений о том, как смягчать (или принимать) риски. Насколько эти риски важны для вас (читателя)? Только вы можете это сказать. Это домашняя сеть? Это школьная сеть? Это сеть ресторана? Это офисная сеть? Это больничная сеть?

При создании правила разрешения в ZBF у вас есть возможность автоматически принимать обратный трафик — это создаст соответствующее правило в обратной зоне, но вы также можете создать новое правило в соответствующей зоне, которое будет принимать только трафик с установленным или связанным состоянием вручную. Можно представлять зоны как группу ваших VLAN.

Рассмотрим, например, две зоны — Trusted (доверенная) и Untrusted (недоверенная). Количество VLAN в каждой из них не важно для простых примеров. Между этими зонами существует четыре пары зон, каждая из которых имеет правило по умолчанию, которое блокирует весь трафик от зоны источника одной пары к зоне назначения другой пары. То есть, по умолчанию ни один VLAN ни в одной пользовательской зоне не сможет взаимодействовать с VLAN в другой пользовательской зоне, и VLAN не смогут взаимодействовать друг с другом в одной пользовательской зоне.  Правила по умолчанию работают по-разному, но их легко понять, изучив матрицу зон.

*   **Trusted/Trusted:** трафик, поступающий от любого VLAN в доверенной зоне к любому VLAN в доверенной зоне.
*   **Trusted/Untrusted:** трафик, поступающий от любого VLAN в доверенной зоне к любому VLAN в недоверенной зоне.
*   **Untrusted/Trusted:** трафик, поступающий от любого VLAN в недоверенной зоне к любому VLAN в доверенной зоне.
*   **Untrusted/Untrusted:** трафик, поступающий от любого VLAN в недоверенной зоне к любому VLAN в недоверенной зоне.

Если мы создадим простое правило разрешения для всего трафика в паре Trusted/Untrusted, то любой хост в любом VLAN, назначенном доверенной зоне, сможет получить доступ к любому хосту в любом VLAN, назначенному недоверенной зоне. Если установить флажок "разрешить обратный трафик", то UniFi создаст соответствующее правило разрешения с установленным/связанным состоянием в обратной группе пар для нас — Untrusted/Trusted в этом примере.

Конечно, возможно создать более специфическое и сложное правило в данной зоне, которое ограничит разрешенные действия до сети, IP-адреса, устройства, порта, состояния, расписания и т.д. (просто посмотрите на интерфейс, чтобы увидеть, сколько опций у вас есть). В данной зоне можно создать более одного правила, и такие правила будут обрабатываться классическим образом — поочередно, по их ID, пока не найдется подходящее (последнее — это правило по умолчанию, которое блокирует любой/любой трафик и всегда будет соответствовать, если ни одно из первых не подходит).

Все действительно просто и понятно, если продолжать учитывать матрицу, создаваемую зонами между собой. Самая сложная часть — понять, как сегментировать вашу сеть на основе ЗОН, а уже потом решить, какие VLAN следует поместить в каждую из них. Мой совет здесь — не думайте о том, какие устройства у вас есть, а думайте о том, что должно общаться с чем, или что нужно отделить от чего. Создавайте отдельные VLAN для конкретных целей, если такая потребность возникнет позже. С зонами нужно мыслить более широко. Зоны – это просто способ группировки VLAN, как VLAN — это способ группировки клиентов, но более общий.

В UniFi есть следующие зоны по умолчанию:

*   **Internal:** по умолчанию все VLAN будут находиться в этой зоне. Думаю, Default network должен жить здесь.
*   **External:** устройства за WAN-интерфейсом, "Интернет".
*   **Gateway:** сам шлюз UniFi.
*   **VPN:** удаленные подключения, когда шлюз UniFi является VPN-сервером.
*   **Hotspot:** VLAN, настроенные как гостевые сети.
*   **DMZ:** VLAN с серверами, доступными из Интернета (например, веб-сервер, сервер электронной почты и т.д.).

Я думаю, что стандартный набор зон подходит для плоских сетей с гостевой сетью, некоторым NAS-сервером, доступным извне, и VPN-сервером, работающим на шлюзе UniFi.

Если бы мне пришлось просто сегментировать такую стандартную конфигурацию, я бы продолжил использовать Default network исключительно в Internal зоне для оборудования UniFi и создал бы хотя бы две новые зоны (возможно, больше по мере необходимости) с таким количеством VLAN, сколько мне нужно, чтобы устройства были отделены друг от друга, даже если они находятся в определенной зоне:

*   **Trusted zone:** для VLAN пользователей, VLAN детей, VLAN для всего остального, что я хотел бы поместить в отдельный VLAN и которому я доверяю.
*   **Untrusted zone:** для VLAN IoT, VLAN DoT, VLAN для всего остального, что я хотел бы поместить в отдельный VLAN, которому я не доверяю или хочу отделить от других VLAN, но при этом сохранить одинаковую связь со всех VLAN в Trusted zone.

Другие пользовательские зоны с их VLAN по мере необходимости — для VLAN, которые не являются достаточно доверенными или недостаточно недоверенными или которые должны быть отделены как от доверенных, так и от недоверенных VLAN, или просто от некоторых VLAN в Trusted или Untrusted зонах, таких как, возможно, система видеонаблюдения стороннего производителя, система контроля доступа, система управления электрическими воротами, серверы с гипервизорами и сети для виртуальных машин и т.д.

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

Что касается управления рассылкой, многоадресной рассылкой и прочим — ничего там не изменилось. Вам нужно разрешить mDNS (сейчас называется opt connectivity в hi, кажется) между конкретными VLAN в настройках сети, а затем создать правильные правила в брандмауэре, чтобы фактический трафик мог течь между VLAN, которые вы хотите — вы просто настраиваете эти правила так же, как и раньше, но размещаете их в правильных зонах, просматривая матрицу зон.

Удалите свой пост здесь, чтобы избежать путаницы. Используйте три точки в своём посте.

mDNS и UniFi сводят меня с ума. Вот мой пример, почему не стоит или стоит разделять IoT-устройства. Мои HomeKit-камеры должны видеть mDNS, исходящий от моих HomeKit-хабов, иначе они теряют соединение в HomeKit. Все мои остальные IoT-устройства — нет. HomeKit просто должен знать, что они существуют. Представь себе простой телефонный справочник. Если бы я поместил камеры в IoT VLAN, и какое-то IoT-устройство было скомпрометировано (привет, WeMo), то злоумышленник узнал бы о существовании всех моих IoT-устройств. В этом случае все IoT-устройства должны принадлежать к IoT VLAN, а камеры и устройства безопасности — к Security VLAN. Я считаю камеры и устройства домашней сигнализации более надежными, чем другие типы IoT-устройств. Думаю, это именно то, к чему стремится @Sawtaytoes. Некоторые производители более уважаемы и отзывчивы, чем другие. Главное — управлять сетью, не вдаваясь в микроменеджмент. В UniFi включение mDNS для VLAN Home, IoT и Security не решает проблему, так как все отражается везде. Потенциально скомпрометированное устройство, упомянутое выше, теперь узнает об устройствах в IoT, Home и Security, что, я согласен, минимальный риск, так как VLANs не позволяют открытую межсетевую связь. В любом случае, чем меньше риск — тем лучше.

Вторая проблема в том, что один из телевизоров в IoT VLAN передает _airplay._tcp и _raop._tcp и его нельзя отключить. Для простоты представим, что я хочу AirPlay на него. Я создаю правило, разрешающее необходимые порты с Home в IoT и разрешаю Establish & Related. Проблема в том, что обратный трафик не принимается как Established или Related, и, следовательно, соединение не удается. Это то, на что ссылается @athurdent. По сути, открываешь ящик Пандоры, который открывать не стоит. Вам, возможно, придется это повторять, когда устройство обновляет свою прошивку или функции. Открывая этот ящик, я пришел к возможности разрешить эти порты с телевизора на VLAN Home, тем самым создав дыру между двумя VLAN. Этот вариант контрпродуктивен, поскольку цель состояла в изоляции VLAN, и он мне не понравился. В качестве альтернативы, фильтр отражения мог бы предотвратить их отражение, что, насколько я знаю, невозможно через UniFi UI. Там уже подключен AppleTV к этому телевизору, так что мне не нужно и не хочется, чтобы телевизор отображался в меню AirPlay. Мы используем некоторые встроенные функции телевизора, поэтому он нужен в сети.

Решение: VLAN Home и Security: Включена отражение mDNS для Home и Security через UniFi.
Решение: VLAN Home и IoT: Я запускаю Avahi в контейнере на хосте Proxmox, который соединяет VLAN Home и IoT, но заблокирован только для отражения mDNS с IoT в Home. Я исключаю _airplay._tcp и _raop._tcp из отражения. Весь остальной трафик заблокирован, за исключением критических обновлений контейнера.

Итог: Устройства на VLAN Home и Security знают друг о друге через mDNS. Устройствам на VLAN Security не разрешено инициировать связь с устройствами на VLAN Home. VLAN Home инициирует всю связь с VLAN Security. Разрешен трафик Established & Related, возвращающийся в обратном направлении.

Устройства IoT знают только об остальных IoT-устройствах в той же VLAN через mDNS. Они ничего не знают об устройствах на VLAN Home или VLAN Security. VLAN Home инициирует всю связь с VLAN IoT. Разрешен трафик Established & Related, возвращающийся в обратном направлении.

Вот почему я говорил про устройства, зависящие от mDNS, а не про те, что используют облако. Например, робот-пылесос Roborock – гибрид. От него легко отделить от локальной сети, и он будет работать в 99%, потому что вся коммуникация для запуска уборки основана на облаке. А вот получить последние 1% работы на отдельной сети может быть весьма забавно – это такой пульт управления в стиле радиоуправляемой машинки, который зависит от локальной связи. Apple Home у меня не работает на 100% с повторяющимся mDNS на отдельной сети: передача музыки с iPhone на HomePod – это лотерея. Просто отвратительно. Поэтому все эти IoT-штуки у меня в одной сети, и я никогда не буду пытаться их разделять.

Обычно IoT-устройства, зависящие от mDNS, разрабатываются и тестируются на плоских сетях. Любая попытка изолировать их с помощью правил брандмауэра требует обширных знаний об их сетевой реализации и всегда является своего рода обходным решением. Так что, чтобы добиться желаемого, обычно нужно глубоко погрузиться в сетевую реализацию этих устройств и выяснить, как они общаются, например, с помощью tcpdump. Также учитывайте, что сейчас большинство из них используют IPv6 (например, Thread). Поэтому, возможно, вам потребуется работающий IPv6 (Unicast routing и Multicast routing) на каждой сети, чтобы общение работало так, как задумано.

Мой ответ, который напрямую на вопрос не отвечает, таков: не думайте об IoT-устройствах как о "не телефонах и не компьютерах", думайте об IoT-устройствах как о тех, которые сначала подключаются к облаку, а потом возвращаются в дом. У меня есть сеть Devices of Things для всех устройств, которым нужно общаться по протоколам multicast: телевизоры, телефоны, стереоаппаратура и т.д. Выключатели и лампочки, которые не используют "хаб", все подключаются к IoT-сети. Компьютеры, принтеры и серверы, которым не нужен доступ к устройствам multicast, подключаются к отдельной "доверенной" сети. Просто мои мысли на этот счет. Я изначально пытался сделать все креативно и сложно, но понял, что это просто не стоит хлопот. Как говорится, на вкус и цвет товарищей нет.

Зачем сегментировать по брендам?

Твои коммутаторы и точки доступа могут находиться в другом VLAN и в другой зоне. Им нужен только доступ к шлюзу. Мой VLAN по умолчанию — Black Hole. У него нет внешнего доступа и доступа к каким-либо другим VLAN или шлюзам, кроме его собственного.