дак у него не будет доступа в другие сегменты, если сеть mgmt и гостевая в разных л2 доменах + блокируется роутинг между этими сетями на л3, де факто может даже не узнать о существовании других сегментов.
который ломает qos, mangle, определенные типы правил фильтрации и чтобы все работало - сношаться с исключением из fasttrack трафика, требующего дополнительной обработки.
для того чтобы минимизировать ущерб в случае взлома или компрометации вай-фая, в противном случае, если рядом кто-то с адаптером в режиме мониторинга и умеет инжектировать пакеты - вы предоставляете злоумышленнику полный доступ для анализа, перехвата хэша пароля, дальнейшего брута и в случае успеха - управление вашей сетью :) поэтому сегментация считается правилом хорошего тона даже в рамках домашней локалки.
Настройка вызывает серьёзные вопросы с точки зрения архитектуры и практической применимости.
Во-первых, добавление sfp1 в отдельный bridge br-wan с включённой VLAN-фильтрацией - это технически бессмысленно. WAN интерфейс не участвует в L2-домене, и тем более не нуждается в VLAN-фильтрации на bridge. Если провайдер требует VLAN 100 - можно и нужно терминировать напрямую на sfp1 через /interface vlan, без лишнего обёртывания в мост.
Во-вторых, межвлановая фильтрация через firewall полностью отсутствует. Зачем тогда вообще вводить вланы если forward трафик между ними открыт? Это превращает вланы не в инструмент сегментации, а в декоративную маркировку. Такое решение особенно опасно, если в сети есть IoT, медиа-зоны и серверы. Сегментация без фильтрации - это косплей на безопасность.
Также вызывает сомнения подход к настройке Wi-Fi с управлением мощностью вручную и вообще отсутствие логики доступа к mgmt-сегменту опять же правилами firewall или хотя бы в /ip services avialable from <mgmt-сеть>.
В итоге получается псевдо-сегментированная сеть с кучей вланов, но без контроля доступа, без чёткой модели безопасности и с неоправданно усложнённой структурой. Если это учебная статья - стоит так и написать. Если практическая - рекомендую критически пересмотреть подход и почитать реальные кейсы проектирования сетей.
MikroTik позволяет строить сильные и чистые конфигурации, но здесь получилась сборка ради сборки. До production-уровня автор явно пока не дотягивает.
Прекрасно структурированное наблюдение за энтропией информационного пространства. Деградация форумов, исчезновение персональных сайтов и «оборотность» контента - это не просто технологический сдвиг, а смена культурной парадигмы. Мы перешли от архива к эфиру, от библиотекаря к сторителлеру, от мышления в статьях к мышлению в рилсах.
Возможно, интернет 2000-х был ближе к энциклопедии, а нынешний - к торговому центру. ИИ лишь усугубляет тренд, паразитируя на остатках старого контента, не создавая нового опыта.
Вопрос не в том, куда делся интернет, а в том, куда делся пользователь, который его создавал. Мы перестали «публиковать», начали «транслировать». А это уже не то же самое.
Да, отлично понимаю вас. Унаследованная инфраструктура, шаблоны, скрипты, привычки - всё это не меняется быстро, даже если новый подход объективно лучше.
В таком случае запланирую сравнительный тест в лабе: BVF против конфига с несколькими бриджами на железке без аппаратной разгрузки BVF.
Как найду подходящий девайс - проведу замеры. Ожидайте.
hEX(RB750Gr3) на RouterOS 7 поддерживает аппаратную разгрузку BVF.
По поводу производительности:
Подход с множеством бриджей наиболее активно задействует CPU, в особенности, если на железке реализован L3 фукнционал, а именно:
Межвлан трафик проходит через CPU трижды: vlan-интерфейс → бридж→ роутинг → другой бридж
Сравнительных тестов: множество бриджей vs. BVF пока не проводил, да и практического смысла в этом не вижу, BVF во всем лучше: более удобный менеджмент, лучше масштабируемость, более логичен в плане обработки трафика и сетевой архитектуры.
В 2025 вариант с множеством бриджей имеет право на реализацию лишь в кейсах, где по каким-то причинам админ не планирует обновлять железку до RouterOS 7 и сама железка уже давно настроена и активно эксплуатируется в проде.
Ниже скрины hEX из тестовой лабы, работающий как L3 ядро через BVF Нагрузка на роутер реализована тестом iperf между двумя ПК в разных вланах.
CPU загружен менее 50% при межвлан трафике более 800 мбит/с
3 - умеет гуглить, но пока не разобрался с list comprehension, вайбкодит 2 - не путает map() с lambda, 1 - прошёл тест от Минцифры и не обиделся, КМС - написал свой первый велосипед с asyncio, МС - понял, что всё это бессмысленно, и ушёл на Go Ждём нормативов, значков и торжественного построения. Ну и чтобы всё было как положено- обязательную переквалификацию. 😂
Да, VLAN — это лишь сегментация. Для полноценной изоляции ограничить межвлан трафик на MikroTik можно через firewall filter на L3 и bridge filter на L2, в статье это сознательно не затрагивалось, чтобы не уводить в сторону от базовой настройки.
Касаемо транка — согласен: «только нужные VLAN» на trunk-портах — в уточняющих комментариях выше именно это и показано.
Ещё уточню на примере статьи: Так как S1 не участвует в VLAN 20 и 30 как L3, добавлять bridge1 в tagged= для этих VLAN-ов нет необходимости — достаточно указать физические интерфейсы.
дак у него не будет доступа в другие сегменты, если сеть mgmt и гостевая в разных л2 доменах + блокируется роутинг между этими сетями на л3, де факто может даже не узнать о существовании других сегментов.
который ломает qos, mangle, определенные типы правил фильтрации и чтобы все работало - сношаться с исключением из fasttrack трафика, требующего дополнительной обработки.
для того чтобы минимизировать ущерб в случае взлома или компрометации вай-фая, в противном случае, если рядом кто-то с адаптером в режиме мониторинга и умеет инжектировать пакеты - вы предоставляете злоумышленнику полный доступ для анализа, перехвата хэша пароля, дальнейшего брута и в случае успеха - управление вашей сетью :) поэтому сегментация считается правилом хорошего тона даже в рамках домашней локалки.
Настройка вызывает серьёзные вопросы с точки зрения архитектуры и практической применимости.
Во-первых, добавление
sfp1в отдельный bridgebr-wanс включённой VLAN-фильтрацией - это технически бессмысленно. WAN интерфейс не участвует в L2-домене, и тем более не нуждается в VLAN-фильтрации на bridge. Если провайдер требует VLAN 100 - можно и нужно терминировать напрямую наsfp1через/interface vlan, без лишнего обёртывания в мост.Во-вторых, межвлановая фильтрация через firewall полностью отсутствует. Зачем тогда вообще вводить вланы если forward трафик между ними открыт? Это превращает вланы не в инструмент сегментации, а в декоративную маркировку. Такое решение особенно опасно, если в сети есть IoT, медиа-зоны и серверы. Сегментация без фильтрации - это косплей на безопасность.
Также вызывает сомнения подход к настройке Wi-Fi с управлением мощностью вручную и вообще отсутствие логики доступа к mgmt-сегменту опять же правилами firewall или хотя бы в /ip services avialable from <mgmt-сеть>.
В итоге получается псевдо-сегментированная сеть с кучей вланов, но без контроля доступа, без чёткой модели безопасности и с неоправданно усложнённой структурой. Если это учебная статья - стоит так и написать. Если практическая - рекомендую критически пересмотреть подход и почитать реальные кейсы проектирования сетей.
MikroTik позволяет строить сильные и чистые конфигурации, но здесь получилась сборка ради сборки. До production-уровня автор явно пока не дотягивает.
Прекрасно структурированное наблюдение за энтропией информационного пространства. Деградация форумов, исчезновение персональных сайтов и «оборотность» контента - это не просто технологический сдвиг, а смена культурной парадигмы. Мы перешли от архива к эфиру, от библиотекаря к сторителлеру, от мышления в статьях к мышлению в рилсах.
Возможно, интернет 2000-х был ближе к энциклопедии, а нынешний - к торговому центру. ИИ лишь усугубляет тренд, паразитируя на остатках старого контента, не создавая нового опыта.
Вопрос не в том, куда делся интернет, а в том, куда делся пользователь, который его создавал. Мы перестали «публиковать», начали «транслировать». А это уже не то же самое.
Большинству интересен контекст реального железа, а не виртуалки.
Да, отлично понимаю вас. Унаследованная инфраструктура, шаблоны, скрипты, привычки - всё это не меняется быстро, даже если новый подход объективно лучше.
В таком случае запланирую сравнительный тест в лабе: BVF против конфига с несколькими бриджами на железке без аппаратной разгрузки BVF.
Как найду подходящий девайс - проведу замеры. Ожидайте.
Спасибо за интересный и уместный вопрос.
hEX (RB750Gr3) на RouterOS 7 поддерживает аппаратную разгрузку BVF.
По поводу производительности:
Подход с множеством бриджей наиболее активно задействует CPU, в особенности, если на железке реализован L3 фукнционал, а именно:
Межвлан трафик проходит через CPU трижды:
vlan-интерфейс → бридж→ роутинг → другой бридж
Сравнительных тестов: множество бриджей vs. BVF пока не проводил, да и практического смысла в этом не вижу, BVF во всем лучше: более удобный менеджмент, лучше масштабируемость, более логичен в плане обработки трафика и сетевой архитектуры.
В 2025 вариант с множеством бриджей имеет право на реализацию лишь в кейсах, где по каким-то причинам
админ не планируетобновлять железку до RouterOS 7 и сама железка уже давно настроена и активно эксплуатируется в проде.Ниже скрины hEX из тестовой лабы, работающий как L3 ядро через BVF
Нагрузка на роутер реализована тестом iperf между двумя ПК в разных вланах.
Скоро, видимо, введут разряды Python разработчиков:
3 - умеет гуглить, но пока не разобрался с list comprehension, вайбкодит
2 - не путает
map()сlambda,1 - прошёл тест от Минцифры и не обиделся,
КМС - написал свой первый велосипед с asyncio,
МС - понял, что всё это бессмысленно, и ушёл на Go
Ждём нормативов, значков и торжественного построения. Ну и чтобы всё было как положено- обязательную переквалификацию. 😂
Спасибо, справедливые замечания.
Да, VLAN — это лишь сегментация. Для полноценной изоляции ограничить межвлан трафик на MikroTik можно через firewall filter на L3 и bridge filter на L2, в статье это сознательно не затрагивалось, чтобы не уводить в сторону от базовой настройки.
Касаемо транка — согласен: «только нужные VLAN» на trunk-портах — в уточняющих комментариях выше именно это и показано.
Наглядный пример как это выглядит на практике: (i use arch BTW)
Спасибо, весьма точное дополнение.
Ещё уточню на примере статьи:
Так как S1 не участвует в VLAN 20 и 30 как L3, добавлять
bridge1вtagged=для этих VLAN-ов нет необходимости — достаточно указать физические интерфейсы./interface bridge vlanadd bridge=bridge1 tagged=bridge1,ether5,ether4 untagged=ether1 vlan-ids=10
add bridge=bridge1 tagged=ether5 untagged=ether2 vlan-ids=20add bridge=bridge1 tagged=ether5,ether4 vlan-ids=30