knowledge-base/projects/benilux/wifi-segmentation-concept.md

date, type, status, tags, aliases

date	type	status	tags	aliases
2026-06-01	concept	draft	benilux unifi vlan segmentation wifi security openwrt	Бенелюкс сегментация WiFi Benelux WiFi segmentation

Концепция: сегментация Wi-Fi в Бенелюксе (хозяева / персонал / гости)

Статус — ЧЕРНОВИК-КОНЦЕПЦИЯ. Изменения в боевую сеть НЕ внесены. Внедрять по фазам, в согласованное окно, с проверкой и откатом на каждом шаге.

Решения Олега (2026-06-01): персонал = только интернет (без принтера/папки); podkop для гостей/персонала — решается при внедрении; внедрение отложено — пока согласуем концепцию с Александром.

1. Задача

Александр хочет развести по разным сетям и правилам три категории пользователей:

• Хозяева — расширенный доступ ко всему (умный дом, камеры, NAS, медиа, принтеры, интернет).
• Домработники / персонал — только интернет. Без умного дома, камер, принтеров, хозяйских устройств.
• Гости — только интернет, изоляция от всех и друг от друга.

Сейчас все на одном SSID Kesco-Home в одной плоской сети 192.168.1.0/24 — ноутбуки хозяев, телефоны гостей, камеры, KNX, охранка Paradox, Miele, NAS видят друг друга на L2.

⚠️ Поправка по «DoS из-за работников»

Задокументированный инцидент ../../decisions/2026-05-20-benelux-compromise — внешний брут WAN-SSH (1qaz!QAZ) → спам-релей с публичного IP. Это не работники. Он уже закрыт (SSH с WAN снят, PasswordAuth off, nft-drop). «Тормоза сети» у клиента = следствие того релея либо забивание канала кем-то изнутри. Сегментация не про тот инцидент, но закрывает другой реальный класс угроз: скомпрометированный гость / уволенный работник / заражённое IoT внутри LAN. Дополнительно от «внутреннего DoS» (забивание канала) защищает SQM + rate-limit (см. §6).

2. Текущее состояние (риски плоской сети)

• Один L2-домен: телефон гостя в одном бродкаст-сегменте с камерами Protect, KNX/Jung, Wirenboard, охранкой Paradox 192.168.1.12, NAS, хозяйскими маками.
• Один общий PSK на всех → уволили работника = надо менять пароль всем, включая хозяев.
• ~55 устройств, куча IoT с заводскими прошивками (Reolink ×5, Imilab/Xiaomi, Dahua, Miele ×2, Mi TV) — типичные цели ботнетов; любое из них видит хозяйские ноуты.
• UniFi-управление (Cloud Key, свитчи, точки) в той же подсети, что и пользователи.

3. Архитектурная особенность объекта (читать перед внедрением!)

Шлюз — Cudy TR3000 (OpenWrt), а НЕ UniFi. USG удалён. Значит роли:

Слой	Делает	Что именно
UniFi (Cloud Key + AP + свитчи)	контроль Wi-Fi	SSID, тег VLAN на SSID, client-isolation на точке, bandwidth-профили
Cudy / OpenWrt	роутинг + безопасность	терминация VLAN (802.1q), DHCP на каждую подсеть, inter-VLAN firewall (вся изоляция), NAT, rate-limit, SQM

Следствия, которые ломают «накликать в UniFi и забыть»:

1. Сети VLAN20/30/40 в контроллере UniFi создаются типом «VLAN Only» — без UniFi-DHCP и без UniFi-gateway. DHCP/шлюз отдаёт Cudy. Иначе — двойной DHCP и конфликт.
2. Транк Cudy ↔ US-24-Pro должен нести теги 20/30/40 (native = VLAN1 хозяев). Порты UniFi по умолчанию пропускают все сети («All»), но native network порта должен совпасть с VLAN1. Это точка №1 для ошибок.
3. Весь путь кадра «AP → промежуточные свитчи → Cudy» должен пропускать теги (trunk «All» на всех аплинках).
4. VLAN ID на UniFi-сети ДОЛЖЕН совпадать с подсетью на Cudy (VLAN20→192.168.20.1 и т.д.).
5. Captive-portal для гостей у UniFi работает в AP-enforced режиме (точка сама перехватывает) — он не требует UniFi-шлюза, так что доступен. Но для Фазы 1 достаточно отдельного PSK.

4. Целевая модель — 4 сегмента

VLAN	Сегмент	Подсеть (на Cudy)	SSID	Шифрование	Кто
1 (native)	Owners + инфраструктура	192.168.1.0/24 (как есть)	Kesco-Home	WPA2/WPA3-PSK	хозяева, умный дом, камеры, NAS, принтеры, UniFi-mgmt
20	Staff (домработники)	192.168.20.0/24	Kesco-Staff	WPA2-PSK (свой пароль)	персонал
30	Guest (гости)	192.168.30.0/24	Kesco-Guest	WPA2/WPA3-PSK или captive	гости
40	IoT (Фаза 2)	192.168.40.0/24	— (в осн. проводные) / Kesco-IoT	WPA2-PSK	камеры не-UniFi, KNX-шлюзы, Miele, ТВ, бытовуха

Подсети .20/.30/.40 сейчас свободны и НЕ анонсируются в NetBird (коллизий с Знаменское/НИИКН по 192.168.1.0/24 не добавляют). Третий октет = VLAN ID — мнемонично.

Принцип Фазы 1 (хирургический): не трогаем 192.168.1.0/24 — хозяева, умный дом, камеры, статические IP, KNX, охранка, сканирование в папку, медиа остаются как есть и продолжают работать. Только добавляем два изолированных сегмента Staff + Guest. Минимальный риск для рабочей инфры.

graph TD
    WAN[Интернет / WAN] --> CUDY[Cudy TR3000 / OpenWrt<br/>шлюз · DHCP · firewall · podkop]
    CUDY -->|trunk: native VLAN1 + tag 20,30,40| SW[UniFi US-24-Pro<br/>+ 7 свитчей]
    SW --> APS[13× UniFi U6 AP<br/>по комнатам]

    APS -.SSID Kesco-Home / VLAN1.-> OWN[👑 Хозяева + инфра<br/>192.168.1.0/24<br/>доступ ко всему]
    APS -.SSID Kesco-Staff / VLAN20.-> STAFF[🧹 Персонал<br/>192.168.20.0/24<br/>интернет + принтер]
    APS -.SSID Kesco-Guest / VLAN30.-> GUEST[👥 Гости<br/>192.168.30.0/24<br/>только интернет, изоляция]
    APS -.VLAN40 Фаза2.-> IOT[📷 IoT / камеры / KNX<br/>192.168.40.0/24]

    OWN ==>|разрешено| STAFF
    OWN ==>|разрешено| GUEST
    OWN ==>|разрешено| IOT
    STAFF -.X блок.-> OWN
    GUEST -.X блок.-> OWN
    GUEST -.X блок.-> STAFF
    IOT -.X блок.-> OWN

    classDef own fill:#d4edda,stroke:#28a745
    classDef staff fill:#fff3cd,stroke:#ffc107
    classDef guest fill:#f8d7da,stroke:#dc3545
    classDef iot fill:#d1ecf1,stroke:#17a2b8
    class OWN own
    class STAFF staff
    class GUEST guest
    class IOT iot

5. Матрица доступа (firewall на Cudy)

Источник ↓ \ Назначение →	Интернет	Owners LAN	Staff	Guest	IoT	Принтер M775	UniFi mgmt
Owners	✅ (podkop)	✅	✅	✅	✅	✅	✅
Staff	✅	❌	(изоляция*)	❌	❌	❌ (по запросу→§10)	❌
Guest	✅	❌	❌	❌ (client-isolation)	❌	❌	❌
IoT	⚠️ мин.	❌	❌	❌	(изоляция*)	❌	❌

* client-isolation внутри сегмента: гости не видят друг друга (L2 на AP + L3 reject на Cudy). Для Staff — на выбор (изолировать безопаснее; если нужен общий доступ к принтеру по mDNS — нужен avahi-reflector только до IP принтера).

На входе в DHCP/DNS: Staff/Guest зонам разрешён только udp/67-68 (DHCP) и 53 (DNS) к Cudy — больше ничего к самому роутеру (LuCI/SSH/Clash-API :9090 закрыты от этих зон).

podkop (обход блокировок):

• Owners — через podkop (как сейчас).
• Staff — прямой интернет без podkop (меньше нагрузки на туннель). [развилка]
• Guest — по желанию хозяев: прямой ИЛИ через podkop, если хотят чтобы у гостей соцсети/YouTube открывались. [развилка]

6. Anti-DoS / комфорт канала

«DoS» в быту = кто-то забил канал или открыл тысячи соединений. Меры:

1. SQM/cake на WAN Cudy — честное разделение полосы, один клиент не задушит остальных. Лучшая защита от «внутреннего DoS».
2. Bandwidth-профили UniFi (User Group) на SSID: Guest напр. 20/20 Мбит/с на клиента, Staff 50/50, Owners без лимита.
3. nftables conntrack-лимит на Cudy: ct count per-IP + SYN-rate limit на forward из Guest/Staff (заслон от шторма соединений).
4. Client-isolation на гостевом WLAN (L2) — гости не атакуют друг друга и не сканируют сегмент.
5. WAN уже закрыт после инцидента (это и была настоящая «атака»). Доступ к роутеру (SSH/LuCI) — только LAN/NetBird.

7. Операционный плюс — посегментная ротация паролей

Отдельный PSK на каждый SSID. Уволили работника → меняете только Kesco-Staff, хозяев и гостей не трогаете. Гостям можно давать временный пароль / ваучер captive-portal и менять хоть еженедельно. Это и есть «разные правила» на входе.

8. План внедрения по фазам (с проверками)

Фаза 0 — подготовка (без даунтайма)

• Бэкап: UniFi (контроллер → Settings → Backup) + Cudy (/etc/config tar, особенно network, firewall, dhcp).
• Свериться live: число LAN-портов Cudy и какой порт идёт в US-24-Pro; текущая разметка транка.
• Проверка: восстановление из бэкапа понятно и доступно.

Фаза 1 — Guest + Staff (целевой результат запроса, низкий риск)

1. Cudy: интерфейсы staff (VLAN20, 192.168.20.1/24) и guest (VLAN30, 192.168.30.1/24); DHCP-пулы; firewall-зоны по матрице §5; SQM на WAN.
   • Проверка: с тестового устройства в каждом VLAN — есть IP/DNS/интернет; нет пинга в 192.168.1.0/24; нет доступа к LuCI/SSH Cudy.
2. Транк: порт Cudy→US-24-Pro = native VLAN1 + tagged 20,30; на UniFi аплинки «All».
   • Проверка: теги доходят до AP (клиент Staff/Guest получает адрес из нужной подсети, не из .1).
3. UniFi: сети Staff/Guest тип VLAN Only (ID 20/30); SSID Kesco-Staff, Kesco-Guest со своими PSK; на Guest — client-isolation + bandwidth-профиль. Staff по умолчанию = только интернет (принтер НЕ открываем).
   • Проверка: подключение к каждому SSID, попадание в правильный VLAN, изоляция, скорость-кап.
4. Документация: обновить ../../claude-memory/benelux-topology и README; пароли в credentials.

Фаза 2 — вынос IoT (рекомендуется, средний риск, отдельное окно)

• Перенести камеры не-UniFi (Reolink/Dahua/Xiaomi), KNX-шлюзы, Miele, ТВ в VLAN40; firewall: Owners→IoT allow, IoT→* reject (кроме нужного облака/NTP).
• ⚠️ Аккуратно: умный дом (Wirenboard/KNX) и охранка Paradox могут зависеть от L2-связности с хозяйскими контроллерами — проверять покомпонентно, не разом. Камеры UniFi Protect живут на Cloud Key и логически отдельны.
• Это и есть главный реальный анти-ботнет/анти-DoS выигрыш — заражённое IoT перестаёт видеть хозяев.

Фаза 3 — mgmt VLAN (опционально)

• Вынести UniFi-управление (Cloud Key, свитчи, точки) в отдельный VLAN. Риск потери управления при ошибке → только когда §1-2 устоялись.

9. Риски и откат

Риск	Митигирование
Ошибка в транке → пропал Wi-Fi/управление	Бэкап Cudy+UniFi; менять в окне; доступ к Cudy по NetBird (100.70.207.97) независимо от LAN
Двойной DHCP (UniFi поднял свой)	Сети в UniFi строго «VLAN Only»
Сломался умный дом при выносе IoT (Фаза 2)	Делать Фазу 2 отдельно, покомпонентно, с проверкой KNX/Paradox
Потеря удалённого доступа	NetBird на Cudy + LuCI по ключу не зависят от сегментации
Native VLAN mismatch	Явно задать native=VLAN1 на обоих концах транка

Откат: восстановить /etc/config/{network,firewall,dhcp} на Cudy + UniFi из бэкапа → возврат к плоской сети за минуты.

10. Открытые вопросы

Решено (2026-06-01):

• ✅ Персонал = только интернет. Принтер/папка/музыка не открываем. Если позже понадобится печать — точечный allow Staff→192.168.1.148:631/9100/443, обсудить отдельно.
• ⏸ podkop для гостей/персонала — решаем при внедрении (по умолчанию: хозяева через podkop, остальные прямой интернет).
• ⏸ Объём — сейчас только концепция, внедрение после согласования с Александром.

Ещё уточнить перед стартом:

1. Масштаб Фазы 1: подтверждаем «не трогаем 192.168.1.0/24, только добавляем Staff+Guest»? (рекомендую — да)
2. IoT (Фаза 2): включаем в план этого захода или строго Фаза 1?
3. Captive-portal для гостей (ваучеры, приветствие) или достаточно отдельного PSK на Kesco-Guest?

Связано

• README — топология объекта
• ../../claude-memory/benelux-topology — полная инвентаризация UniFi
• ../../decisions/2026-05-20-benelux-compromise — инцидент (внешний, не работники)
• credentials — доступы Cudy/UniFi