---
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
шлюз · DHCP · firewall · podkop]
CUDY -->|trunk: native VLAN1 + tag 20,30,40| SW[UniFi US-24-Pro
+ 7 свитчей]
SW --> APS[13× UniFi U6 AP
по комнатам]
APS -.SSID Kesco-Home / VLAN1.-> OWN[👑 Хозяева + инфра
192.168.1.0/24
доступ ко всему]
APS -.SSID Kesco-Staff / VLAN20.-> STAFF[🧹 Персонал
192.168.20.0/24
интернет + принтер]
APS -.SSID Kesco-Guest / VLAN30.-> GUEST[👥 Гости
192.168.30.0/24
только интернет, изоляция]
APS -.VLAN40 Фаза2.-> IOT[📷 IoT / камеры / KNX
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