Умный дом, если смотреть честно, обычно не умный. Он просто сетевой. А значит, его главная суперспособность не включать свет по хлопку, а тихо жить в вашей локалке рядом с ноутбуком, NAS и рабочими папками. И да, я прекрасно понимаю, что «лампочка же маленькая, что она сделает». Именно поэтому она и опасна: маленькая, массовая, с редкими обновлениями и с очень бодрой любовью к интернету.
Задача простая: IoT-устройства (камеры, лампы, розетки, колонки, пылесосы, датчики) должны жить отдельно и не иметь маршрута к вашему ноутбуку. При этом телефон, как пульт управления, чаще всего должен иметь доступ к умному дому. И вот здесь начинается взрослая часть разговора: «гостевая сеть» на роутере не всегда решает всё, а иногда решает слишком много и ломает обнаружение устройств.
Что именно мы защищаем и от чего
Я исхожу из приземленного сценария, без кино про хакеров. Любое IoT-устройство может быть взломано через уязвимость, слабый пароль, кривой облачный сервис, подмену DNS или просто потому, что производитель забыл про него на следующий день после релиза. Дальше начинается латеральное перемещение по сети: скан портов, попытки войти в админки, поиск SMB-шар, проба стандартных паролей, атаки на принтеры и роутеры. И всё это внутри вашей «домашней уютной» сети.
Нормальная архитектура делает так, чтобы зараженное устройство было почти бесполезным: оно может выйти в интернет (если нужно) и говорить с контроллером умного дома, но не может видеть ноутбуки, серверы, NAS, камеры наблюдения с архивом и прочие вещи, которые обычно не хочется объяснять потом самому себе.
- Цель: IoT не видит вашу основную сеть.
- Цель: гости не видят вашу основную сеть и друг друга.
- Компромисс: телефон может управлять IoT, но с минимальными лазейками.
Три уровня изоляции: от простого к правильному
Сразу о главном: «гостевая сеть» на большинстве домашних роутеров это не магия, а один из вариантов сегментации. Иногда это отдельная подсеть с запретом доступа к LAN. Иногда это просто галочка «изоляция клиентов», которая не дает устройствам на этом Wi-Fi общаться друг с другом, но при этом они все равно видят вашу локалку через роутер. Поэтому первое правило: не верьте названию, верьте тому, что реально происходит на уровне подсетей и правил файрвола.
Уровень 1. Изоляция клиентов (AP isolation)
Работает так: устройства на одном SSID не могут напрямую общаться между собой. Это полезно для гостей, но почти бесполезно против сценария «IoT лезет к ноутбуку», потому что ноутбук обычно сидит в другой сети или на другом SSID, а маршрутизация через роутер остается возможной.
Уровень 2. Гостевой SSID с запретом доступа к LAN
Это уже лучше. Роутер делает отдельную подсеть, выдает ей DHCP и режет доступ к вашей домашней подсети. Проблема в том, что некоторые прошивки режут слишком грубо: вместе с LAN отваливается локальное обнаружение устройств, кастинг, HomeKit и часть сценариев умного дома.
Уровень 3. VLAN/сегменты плюс правила файрвола
Это то, что реально работает и масштабируется. У вас есть отдельный сегмент для IoT (и, при желании, отдельный для гостей). Между сегментами стоят правила: кто кому может, по каким протоколам и в каком направлении. Не «доверяй», а «разрешай только необходимое». Наука скучная, зато надежная.
Быстрый практический рецепт для большинства домашних роутеров
Если у вас обычный роутер без VLAN-меню, чаще всего можно сделать приличную схему и без фанатизма.
Шаг 1. Сделайте отдельный SSID для IoT
Назовите его как угодно, хоть “iot_2g”. В идеале используйте 2.4 ГГц, потому что многие IoT живут там. Пароль отдельный, не совпадает с основным.
Шаг 2. Включите режим гостевой сети именно для IoT-SSID
Ищите опции вроде “Access Intranet: Disable”, “Allow access to local network: Off”, “Guest network isolation”. Смысл один: IoT должно ходить в интернет (если надо), но не в вашу домашнюю подсеть.
Шаг 3. Включите изоляцию клиентов для гостевой сети
Это не про безопасность от ноутбука, а про гигиену: чтобы устройства IoT не болтали друг с другом без необходимости. Камера не должна дружить с розеткой просто потому, что они на одном Wi-Fi.
Шаг 4. Проверьте, что реально получилось
Не на уровне «галочки», а руками. Подключите телефон к основной сети и попробуйте пропинговать устройство IoT по его IP. Потом наоборот: подключите телефон к IoT-SSID и попробуйте достучаться до ноутбука в основной сети.
Из полезного софта: nmap для проверки видимости хостов и портов, Wireshark если хочется понять, что именно летает по сети, Fing как быстрый бытовой «сканер сети» на телефоне.
Если после шага 2 управление умным домом «вдруг перестало находить устройства», вы уперлись в протоколы обнаружения. Это нормально, просто у протоколов обнаружения плохие манеры.
Типовые грабли: почему после изоляции всё ломается
Большая часть «магии» умного дома это не облако, а локальное обнаружение. Оно любит широковещание и мультикаст, а гостевые сети и VLAN как раз это режут. Самые частые виновники:
- mDNS (UDP 5353, 224.0.0.251) используется HomeKit, AirPrint, часть Matter/Thread шлюзов, многие приложения производителей.
- SSDP/UPnP (UDP 1900, 239.255.255.250) используется для Chromecast, DLNA и прочих «найди меня в локалке».
- SMB/Bonjour и другие «удобные» штуки, которые не должны жить в гостевой сети.
Есть три разумных подхода, без религии:
- Подход A: телефон на время настройки подключаете к IoT-SSID, настраиваете устройства, потом возвращаете телефон в основную сеть. Работает, если управление дальше идет через облако.
- Подход B: делаете отдельный «управляющий» сегмент (или просто разрешаете телефону доступ к IoT по правилам), но не наоборот.
- Подход C: настраиваете мосты обнаружения (mDNS reflector, SSDP relay) строго между нужными сегментами. Это самый правильный и самый капризный вариант.
Если вам нужен HomeKit/Chromecast между сегментами, готовьтесь к тому, что «просто гостевая сеть» может не потянуть. Тогда переходим к нормальной сегментации.
Нормальная сегментация: IoT VLAN, гостевой VLAN и жесткий файрвол
Я люблю решения, которые можно объяснить самому себе через месяц. Поэтому базовая схема такая:
- LAN (Trusted): ноутбуки, рабочие станции, NAS.
- IoT: умный дом и устройства, которым доверять нельзя.
- Guest: гости и «временные» устройства.
Правила простые:
- Guest: только в интернет, без доступа к LAN и IoT, плюс изоляция клиентов.
- IoT: в интернет по минимуму (часто достаточно DNS, NTP, HTTPS), доступа к LAN нет.
- LAN: может ходить в IoT (для управления), но только по нужным портам и направлениям.
Ниже два практичных примера. Это не единственно верный путь, но он рабочий.
Вариант 1. OpenWrt (типовой домашний роутер на альтернативной прошивке)
Документация: OpenWrt VLAN, OpenWrt firewall.
<!-- Идея: отдельная зона firewall для IoT, запрет в LAN, разрешение в WAN -->
# /etc/config/firewall (фрагменты)
config zone
option name 'iot'
list network 'iot'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
config forwarding
option src 'iot'
option dest 'wan'
# Разрешаем LAN -> IoT (управление), но не IoT -> LAN
config forwarding
option src 'lan'
option dest 'iot'
# Минимально полезные сервисы для IoT (если режете input)
config rule
option name 'Allow-DHCP-IoT'
option src 'iot'
option proto 'udp'
option dest_port '67-68'
option target 'ACCEPT'
config rule
option name 'Allow-DNS-IoT'
option src 'iot'
option proto 'tcp udp'
option dest_port '53'
option target 'ACCEPT'
Если нужен mDNS между LAN и IoT: в OpenWrt часто ставят пакет “avahi-daemon” в режиме reflector или отдельный mDNS-repeater. Делайте это осознанно, потому что это именно «дырка для удобства». Разумный компромисс: разрешать mDNS только из LAN в IoT, а не наоборот, и только если без этого реально больно.
Вариант 2. MikroTik (если хочется контроля и терпения)
Смысл тот же: отдельный bridge/VLAN для IoT, отдельный DHCP, дальше фильтр на forward chain. Справочник: MikroTik Documentation.
<!-- Идея: запрет IoT -> LAN, разрешение LAN -> IoT, IoT -> WAN -->
# Пример логики правил (псевдо-конфиг, адаптируйте под свои интерфейсы)
# 1) Запрет IoT к LAN
/ip firewall filter add chain=forward src-address=192.168.50.0/24 dst-address=192.168.10.0/24 action=drop comment="IoT to LAN drop"
# 2) Разрешение LAN к IoT (управление)
/ip firewall filter add chain=forward src-address=192.168.10.0/24 dst-address=192.168.50.0/24 action=accept comment="LAN to IoT allow"
# 3) Разрешение IoT в интернет (через NAT обычно и так пойдет)
/ip firewall filter add chain=forward src-address=192.168.50.0/24 out-interface=WAN action=accept comment="IoT to WAN allow"
Если у вас UniFi, логика та же: Networks (создать VLAN), WiFi (привязать SSID к VLAN), затем Firewall Rules. У Ubiquiti это делается довольно человечески, но «магические» сервисы типа mDNS нужно включать отдельно и аккуратно. Документация: UniFi Help Center.
Проверка: как убедиться, что умный дом действительно не видит ноутбук
Я всегда делаю проверку в две стороны. Это важно: запрет «IoT к LAN» не равен запрету «LAN к IoT».
- Тест 1: подключитесь к IoT Wi-Fi и попробуйте открыть веб-интерфейс вашего роутера в LAN, NAS, принтера. Должно не открываться.
- Тест 2: подключитесь к IoT Wi-Fi и попробуйте просканировать LAN подсеть через nmap. Хосты не должны обнаруживаться.
- Тест 3: подключитесь к основной сети и проверьте, что управление умным домом работает. Если нет, смотрите в сторону mDNS/SSDP и модели управления (облако vs локалка).
Полезная привычка: закрепить IP-адреса (DHCP reservation) для ключевых устройств IoT. Так проще писать правила и отлавливать странности. И да, если устройство требует доступ к вашему NAS по SMB, это не «умный дом», это приглашение к неприятностям. Лучше прокинуть данные через контроллер, шлюз или отдельный сервис, чем раздавать IoT прямой доступ к файлопомойке.
Минимальный набор «чтобы жить спокойно»
Если вы хотите без фанатизма, но с ощутимым эффектом, я бы сделал так:
- Отдельный SSID для IoT, отдельный пароль.
- Отдельная подсеть для IoT (не просто изоляция клиентов).
- Запрет IoT к LAN на уровне роутера.
- Разрешение LAN к IoT только при необходимости.
- Для гостей отдельный SSID + изоляция клиентов + запрет к LAN и IoT.
В качестве приятного бонуса можно добавить локальный DNS-фильтр типа Pi-hole или AdGuard Home и направить IoT через него. Это не панацея, но иногда внезапно показывает, сколько лишнего в интернет пытается уйти «просто датчик температуры».
И последнее. Без мистики и без веры в добрых производителей: сеть нужно проектировать так, как будто любое устройство может оказаться враждебным. Это не паранойя, это статистика. Чем меньше поверхностей соприкосновения между IoT и вашими рабочими устройствами, тем меньше шансов однажды обнаружить, что «лампочка» внезапно стала самым активным участником вашей домашней кибержизни.
