Unifi vlan guests a pristup do LAN
Dostal som zase raz za ulohu jednu lakocinku. Zakaznik si zmyslel, ze chce hostov z wifi pustat na svoj lokalny server. Momentalne su hostia na vlan11 a tak idu z AP na gw (MT) a do netu. Na LAN pristup nemaju, pretoze ako som zistil AP zahadzuje vsetky packety smerujuce na LAN, respe, ked som tcpdumpoval linuxovy server na LAN nic k nemu ndorazilo a ked som torchoval na MT tiez nebolo vidiet, ziadne prichadzajuce packety. Normalny klienti z AP sa dostanu vsade, takze logicky som usudil, ze to priamo nejako blokuje Unifi AP, ktore by sa vsak podla vsetkeho malo spravat ako bridge, ale bohuzial tomu tak nie je.
AKo docielim, aby wifi klienti z guest siete, ktory su vlanovany az po gw sa dostali na linuxovy server, ktory je tiez zapojeny do gw (default vlan1, cize nezvlanovany).
Jedine co ma napadlo je nejaka reverzna proxy.
Asi som to nepochopil, lebo nevidím žiadny problém. Ak ti obe vlany prichádzajú na router, tak tam doplníš pravidlo pre prístup. Problém bude asi len v AP, treba ho dať do do normálneho režimu, nech nič nefiltruje.
Na Unifi controleri/ap sa neda nic take nastavit. Na toto maju ubnt svoje zariadenia (usgw, pripadne switche).
Na Mikrotiku je třeba, jak správně píše čitatel, vytvořit pravidla pro routování a firewalling mezi vlan11 a vlan1
Naco pravidlo, ked v route table je rozsah vlan11 aj normálny lan rozsah a forward nemam dropovany? To mi moc logiku nedava. Navyse preco torch nevidí ziadne prichadzajuce packety z.vlan11 smerom do lan?
jestli to navazuje na toto: https://pc.poradna.net/questions/2720378-hybridna-vlan-na-mt tak si myslím, že tam máš něco blbě. (to jsem ti psal už tehdy).
pokud chceš řízeně propojovat VLANy, musí to být až na k tomu určeném routeru.
edit: používat vlany a pak to nechat bez kontroly - to taky nechápu...
Pokud je to v Unifi skutečně nastavené, jako Guest síť, pak pro Guest síť je jako defaultní následující přístup:
(ono to i dává smysl, díky tomu může Guest síť mít společnou síť jako běžní uživatelé, přesto hosti nebudou mít přístup do místní sítě ale pouze na internet)
Kromě DNS a DHCP serveru mají zakázáno přistup do všech IANA privátních rozsahů (192.168.0.0/16,10.0.0.0/8,172.16.0.0/12) viz screenshot. Tato pravidla jsou vynucována v EBtables (L2 packet filter) přímo na samotném accesspointu.
Zároveň s tím je ještě zamezeno vzájemné komunikaci mezi klienty jednoho přístupového bodu.
Pokud je Guest samostatná síť (VLAN se svým vlastní IP rozsahem), doporučuji tuto restrikci omezit pouze a jenom na tuto síť (aby si hosté nemohli povídat mezi sebou, tedy třeba očmuchávat si navzájem porty, šířit si viry a tak podobně) a ostatní restrikce (vůči internetu či jiným lokálním privátním sítím) pak vynucovat na firewallu.
Som sa na teba spoliehal a nesklamal si...toto uniklo mojej pozornosti, nicmenej aj ked pridam IP adresu server do pre-authorization access nejde to .
Edit: Tak asi maju nejaky bug alebo co, pridal som vynimku vynimku, neslo to. Odobral som rozsah 192.168.0.0/16 z post-aurization a nic. Vratil som ho spat a...zrazu to ide.
Pre-autorization je sekce, kam mají hosti přístup ve chvíli, kdy ještě nejsou jako hosti povolení (nezaplatili, nezadali heslo či kód) - to se netýká situace, kdy guest síť je přístupná pouze přes síťový klíč (wpa) a nějaký captive portal a dodatečná autorizace se nevyžaduje. Lokální DNS (to, které má nastavené i AP) a adresa captive portálu na unifi controleru (pokud je použit) jsou povolene automaticky. Tam se typicky dává adresa externího captive portál serveru, pokud to není Unifi, DHCP serveru, pokud není součástí lokální sítě (DHCP relay), či jiné služby, třeba web provozovatele atd. Prostě všechno, co by měl vidět Guest, i když není autorizován.
Ten druhý seznam, Post-authorizaton Restrictions, to je seznam sítí (adres), které jsou zakázané pro guesta po ověření. Mým doporučením (v případě, že guest síť je firewallem oddělena od ostatních sítí a má například adresní rozsah 10.0.0.0/24) je mít v zakázaném přístupu pouze 10.0.0.0/24 a přístupy do internetu a jiných lokálních sítí řešit firewallem na routru.