Smart home ve vlastní VLAN: jak oddělit IoT od počítače a zastavit telemetrii

Chytrá zařízení posílají data domů v pravidelných intervalech — typicky jde o heartbeat každých 30 až 300 sekund, často po nešifrovaném MQTT nebo HTTP. Pokud takové zařízení sdílí jednu síť s notebookem, NAS a routerem, má po kompromitaci přímou cestu ke všem těmto cílům. Řešením je přesunout IoT do samostatné VLAN s vlastním DHCP rozsahem a firewallovými pravidly, která povolí jen to, co zařízení skutečně potřebuje.

Krok 1: Inventura a pevné IP adresy

Než začnete cokoliv přepojovat, vypište si MAC adresy všech chytrých zařízení. Většina routerů je zobrazí v přehledu připojených klientů, u zařízení bez displeje pomůže sken sítě nástrojem arp-scan nebo nmap -sn 192.168.1.0/24. Následně v DHCP serveru nastavte statické lease podle MAC — potřebujete stabilní adresy, abyste mohli psát cílená firewallová pravidla. Zároveň si udělejte seznam toho, co zařízení reálně potřebuje: termostat potřebuje jen odchozí spojení na cloud, kdežto Chromecast nebo AirPlay reproduktor musí být objevitelný z telefonu v hlavní síti přes mDNS a SSDP.

Krok 2: Vyberte způsob izolace podle routeru

Pokud máte běžný router od operátora, VLAN pravděpodobně nenastavíte. Nejrychlejší dostupná varianta je hostovská Wi-Fi síť — ta obvykle vytváří samostatný subnet, ve kterém klienti nevidí do hlavní sítě. Pozor na dvě věci: některé routery mají volbu „povolit klientům navzájem se vidět“, kterou je vhodné vypnout, a hostovská síť často neumí mDNS přeposílání, takže Chromecast z telefonu vůbec neobjevíte.

Plnohodnotné VLAN vyžaduje router s podporou 802.1Q — OpenWrt, pfSense/OPNsense, Ubiquiti UniFi, TP-Link Omada nebo MikroTik. Podmínkou je i access point, který umí vysílat víc SSID s přiřazenou VLAN; většina AP pro UniFi a Omada to zvládá.

Krok 3: Vytvořte VLAN a rozsahy

Typické rozdělení vypadá takto: VLAN 1 pro důvěryhodná zařízení (192.168.10.0/24), VLAN 20 pro IoT (192.168.20.0/24), VLAN 30 pro hosty. V OpenWrt se to řeší přes bridge VLAN filtering — na portu k access pointu nastavíte tagged obě VLAN, na portu k počítači zůstane VLAN 1 untagged. Pak vytvoříte rozhraní br-lan.20 s vlastním DHCP poolem:

config interface 'iot'
  option proto 'static'
  option ipaddr '192.168.20.1'
  option netmask '255.255.255.0'
  option device 'br-lan.20'

Na AP potom vytvoříte druhé SSID (například „Domacnost-IoT“), přiřadíte mu VLAN 20 a nastavíte WPA2 nebo WPA3 s jiným heslem, než má hlavní síť.

Krok 4: Firewallová pravidla

Základní politika je jednoduchá: IoT může ven do internetu, nesmí do hlavní sítě, hlavní síť může za IoT jen na konkrétní porty. Ve OpenWrt to znamená vytvořit zónu iot s input REJECT a forward REJECT, povolit forwarding z iot do wan a přidat výjimky. Příklad pro Home Assistant na 192.168.10.5, který běží v důvěryhodné síti:

config rule
  option src 'lan'
  option dest 'iot'
  option proto 'tcp'
  option dest_port '8123'
  option target 'ACCEPT'

Pokud Home Assistant přesunete přímo do IoT VLAN, je konfigurace jednodušší — stačí mu povolit internet a jedním pravidlem i cestu do hlavní sítě. Izolace tím ale částečně trpí, protože kompromitovaný Home Assistant má otevřenou cestu dál.

Pro objevování zařízení (Chromecast, AirPlay, Sonos) je potřeba povolit mDNS 5353/UDP a SSDP 1900/UDP a nasadit reflector — v OpenWrt balíček umdns, na pfSense avahi-daemon s volbou reflector, v UniFi přepínač „Multicast DNS“. Bez něj telefon v hlavní síti Cast zařízení neuvidí. U Chromecastu je navíc potřeba TCP 8008, 8009 a UDP rozsah 32768–61000.

Krok 5: Zablokujte odchozí DNS a telemetrii

Dokud IoT zařízení používají váš DNS, máte přehled o tom, kam volají. Jenže řada z nich má adresu 8.8.8.8 zapečenou ve firmwaru. Řešením je přesměrovat veškerý provoz na portu 53 na váš resolver — v OpenWrt pravidlem s targetem DNAT:

config redirect
  option src 'iot'
  option proto 'tcp udp'
  option src_dport '53'
  option dest_ip '192.168.10.5'
  option dest_port '53'
  option target 'DNAT'

Současně zablokujte port 853 (DNS-over-TLS) a 443 směrem na známé DoH resolvery, jinak vám zařízení DNS obchází. Jako resolver použijte Pi-hole nebo AdGuard Home a v jejich logu uvidíte domény po jednotlivých IP adresách. Blokace telemetrie je pak otázka přidání domény na blacklist — počítejte ale s tím, že u některých zařízení blokace cloudu rozbije ovládání z mobilní aplikace.

Krok 6: Ověřte, co zařízení skutečně posílá

Předpoklady si ověřte měřením. Na OpenWrt routeru stačí tcpdump -i br-lan.20 -n -c 500 a uvidíte, na jaké IP adresy a porty zařízení míří. Pro dlouhodobý přehled je vhodnější nlbwmon nebo ntopng na pfSense. V logu Pi-hole zkontrolujte, kolik dotazů za hodinu jednotlivá zařízení generují — běžná chytrá zásuvka jich mívá několik desítek, IP kamera i několik stovek.

Druhá kontrola: z počítače v hlavní síti zkuste nmap -Pn 192.168.20.1. Pokud firewall funguje, uvidíte všechny porty filtrované. Z IoT VLAN zkuste totéž proti 192.168.10.1 — také nic. Nakonec ověřte, že mDNS reflector skutečně funguje: avahi-browse -a -t na počítači musí vypsat služby z IoT sítě.

Co si pohlídat později

Po každém updatu firmwaru zařízení zkontrolujte, jestli nezměnilo cloudové endpointy nebo nepřidalo nové porty. Stejně tak po výměně routeru nebo AP znovu projděte, které porty jsou tagged a které untagged — chyba v trunk portu je nejčastější důvod, proč IoT zařízení po migraci skončí omylem v hlavní síti.

Foto: Jakub Zerdzicki / Pexels