Izolace Wi-Fi klientů mi vždy přišla jako trochu zvláštní funkce. Když ji zapnu na jednom AP, tak to v rámci tohoto konkrétního zařízení funguje. Klienti připojení k danému AP spolu nemohou komunikovat.
V síti s více AP už je to ale složitější. Druhé AP samo o sobě nepozná, jestli provoz přichází od Wi-Fi klienta přes jiné AP, nebo z běžné kabelové části sítě. Na úrovni samotného AP tedy nejde zajistit úplnou izolaci klientů napříč celou infrastrukturou.
Často se jako řešení zmiňuje VLAN. Samostatná VLAN pro hosty ale problém neřeší, protože všichni hosté jsou pořád ve stejné vrstvě 2 a mohou spolu komunikovat. Izolace na úrovni VLAN by fungovala jedině tehdy, pokud by měl každý klient vlastní VLAN. To je technicky možné, ale znamená to dynamické přidělování VLAN podle uživatele a tomu musí odpovídat celá síťová infrastruktura.
Takže jednoduché zapnutí „client isolation“ na jednotlivých AP řeší jen komunikaci klientů připojených ke stejnému AP. Pokud má být izolace skutečně plošná a zároveň má fungovat roaming, musí to být řešeno centrálně na úrovni celé sítě, ne jen lokální funkcí v přístupovém bodu.
Musí být řešeno obojí. Např. HPE Aruba má kromě "client isolation" ještě další nastavení "block intra-VLAN traffic". Z toho pak jde nastavit výjimky na MAC a/nebo IP adresy. Default je povolen provoz pouze na gateway -- a teď je právě otázka jestli jen podle IP nebo MAC.
Co článek zdá se vůbec neřeší, je další úroveň problémů která přijde v kombinaci s IPv6, hlavně SLAAC + Privacy Extensions. V tu chvíli může mít každý klient shora neomezený počet IPv6 adres, které si sám vytváří. Pak jsou některé ty rady z článku trochu k ničemu... Pro IPv4 je obvykle k dispozici nějaká analogie DHCP/IP-source-guard, která svazuje MAC a IP přidělenou z DHCP a řeší tak značnou část v článku popsaných problémů.
Konkrétně u HPE Aruba zrovna ta funkce "block intra-VLAN traffic" rozbíjí IPv6 Router Solicitation (RS), takže je v praxi nepoužitelná.
Pokud AP nemá funkci "block intra-VLAN traffic" nebo je takto rozbítá, lze to řešit použitím PVLAN na switchích mezi jednotlivými AP.
Podpora IPv6 first-hop security je i u enterprise WiFi řešení stále obvykle špatná. Potom je izolace klientů jediná možnost jak např. zajistit, aby klienti nemohli do sítě posílat rogue RA.
Zrovna Captive portal technicky až takový problém není. Musí ale fungovat čistě na bázi MAC adres, a tím pádem na prvním routeru nejblíže klientům. Různá řešení původně vyvinutá pouze pro IPv4 to tak mít nemusí. Pro vendory to zjevně není prioritní řešit. Z pohledu zákazníka je v případě výběru technologie problém jak tyto požadavky zformulovat a ověřit - z datasheetů a dokumentace nelze vycházet, nelze se opřít o konkrétní RFC a i při nějaké podpoře není zarušena funkce v kombinaci s jinými funkcemi...
Trochu problém je s různými způsoby randomizace MAC adres na straně WiFi klientů. Pokud to dělají moc agresivně, při každém připojení, je problém udržet identifikaci klienta. Ale to platí i bez IPv6.
IPv6 evangelisté by pro jeho větší rozšíření nejlépe udělali, kdyby vznikly nějaké "true IPv6 support" checklisty, testovací postupy a katalogy ověřených zařízení pro typické use cases. Na což by pak např. mohli odkazovat zadavatelé z řad veřejných institucí. Napsat do požadavků "plná podpora IPv6", a pak se nad konfigurací dodané technologie dohadovat co to znamená, nebo že podpora nějaká je, ale je děravá 10 let známým způsobem... to není dobrá cesta ani pro jednu stranu.
A je opravdu potřeba od sebe izolovat jednotlivé klienty? Důležité je hlavně oddělit nedůvěryhodné návštěvníky od míst, kde by mohli napáchat nějaké škody.
A ve chvíli, kdy se na to člověk podívá takhle, tak je z toho složitější problém. Protože najednou je třeba ty klienty nějak rozdělit a určit co můžou a co už ne.
"hlavně oddělit nedůvěryhodné návštěvníky od míst, kde by mohli napáchat nějaké škody."
To ale samo o sobě nestačí. Zkuste si představit hotel a jeho veřejnou Wi-Fi. To, že se host nedostane do účetnictví, je jedna věc, samozřejmá, doufám. Druhá věc je ale ochrana hostů mezi sebou.
Představte si, co to udělá s vaší pověstí, když tam někdo, klidně i nevědomky, připojí zavirovaný nebo botnetem napadený počítač či mobil a ohrozí ostatní hosty. Nikoho nebude zajímat, že za to hotel technicky nemůže.
Hotel je jen příklad. Totéž platí pro všechny veřejné Wi-Fi sítě.
Resis "problem", kterej neexistuje. Zkus si predstavi ze nekdo pripoji zavirovanej pocitac k internetu ....
Jo aha, takovych jsou miliardy.
Jeste lepsi jsou verejny (pripadne hotelovy) usb porty ...
Pokud poskytuju verejnou wifi, nezapinam na ni ani zadny sifrovani, proc jako? Je to proste public prostor, a ty se bud pripojis nebo nepripojis, to je ciste tvoje vec, stejne jako reseni zabezpeceni tvyho auta. Taky ti nikdo na parkovisti nestavi extra plot kolem tvyho milaska.
> Resis "problem", kterej neexistuje.
To, ze to ty tak vidis, neznamena, ze je to pravda.
> Zkus si predstavi ze nekdo pripoji zavirovanej pocitac k internetu .... Jo aha, takovych jsou miliardy.
Preto velka vacsina nie je pripojena napriamo, ale cez firewally, proxy atd.
> Jeste lepsi jsou verejny (pripadne hotelovy) usb porty ...
Ano. Ak potrebujem USB port tak pouzijem len hlupy nabijaci kabel, alebo pohladam zasuvku a do nej dam vlastny USB zdroj.
> Pokud poskytuju verejnou wifi, nezapinam na ni ani zadny sifrovani, proc jako? Je to proste public prostor, a ty se bud pripojis nebo nepripojis,...
Nechapes situaciu; ak hotel poskytuje wifi, tak ju poskytuje pre hosti ktorym ponuka pripojenie VON, nie pripojenie medzi sebou navzajom. A v pripade spominaneho hacku je to minimalne reputacne riziko pre hotel, bez ohladu na to ako by si sa ty zariadil. Tak ako v hoteli nemas zamky dveri za volitelny priplatok ale standard, takisto mas mat standardne zabezpecenie.
> to je ciste tvoje vec, stejne jako reseni zabezpeceni tvyho auta. Taky ti nikdo na parkovisti nestavi extra plot kolem tvyho milaska.
Ale ty si predsa tiez vyberas, kde parkujes - ci na zabezpecenom osvetlenom parkovisku alebo niekde medzi 20 vrakmi.