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

UniFi VLAN + firewall на Cudy; персонал=только интернет, внедрение отложено

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

projects/benilux/README.md

@@ -91,6 +91,10 @@ aliases: [Benilux, benilux, Бенелюкс, "OpenWrt Benilux"]
 
 - **2026-05-20** — компрометация через WAN-SSH brute-force; роутер несколько часов рассылал спам и брутил чужие SSH. Закрыто, см. [[decisions/2026-05-20-benelux-compromise]].
 
+## Планы / концепции
+
+- [[wifi-segmentation-concept]] — сегментация Wi-Fi на хозяев / персонал / гостей (UniFi VLAN + firewall на Cudy). Черновик 2026-06-01, внедрение отложено.
+
 ## Aliases для FTS
 
 `Benilux`, `Бенелюкс`, `OpenWrt Benilux`, `100.70.207.97`, `Истра-Benelux`, `КП Бенелюкс`, `Александр Бенелюкс`.

projects/benilux/wifi-segmentation-concept.md

@@ -0,0 +1,176 @@
+---
+date: 2026-06-01
+type: concept
+status: draft
+tags: [benilux, unifi, vlan, segmentation, wifi, security, openwrt]
+aliases: [Бенелюкс сегментация 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. Минимальный риск для рабочей инфры.
+
+```mermaid
+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