7bd229e387
UniFi VLAN + firewall на Cudy; персонал=только интернет, внедрение отложено Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
177 lines
17 KiB
Markdown
177 lines
17 KiB
Markdown
---
|
||
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
|