Költséghatékony WiFi hálózat kialakítása (tartalomszűrés, naplózás, izoláció)

Hálózatok egyéb

Sziasztok!

Több nap agyalás után úgy gondoltam ideje megkérdezni az itteni kollégákat is.

Adott egy ügyfél, akinél "switch it on and forget it" jellegű üzemeltetéssel (ne legyen vele rendszeres munka) és persze költséghatékonyan kellene kialakítani egy hálózatot. Amiket szeretnénk megvalósítani:

  • Szeparált belső hálózat a saját eszközöknek (ez lehet egyben a menedzsment VLAN is akár)
  • Az előbbi, úgymond "biztonságos" hálózaton lévő 1-2 eszköznek az Internet felé prioritást kell kapnia
  • Szeparált vendég hálózat (csak WiFi), ezen szolgáltatásokkal:
    • Seamless WiFi roaming
    • Tartalomszűrés (akár DNS alapú is)
    • AP izoláció (a kliensek ne lássák egymást)
    • Sávszélesség korlátozása per felhasználó alapon
    • Sávszélesség korlátozása per interfész (VLAN) alapon
    • Forgalom naplózása
  • VPN képes legyen az eszköz, a távoli felügyelethez, segítségnyújtáshoz

És mindent olcsón... Amiket gondolkoztam:

1: TP-Link Omada alapú hálózat

Előnye, hogy van olyan eszköze ami egyben megoldja a hálózati feladatokat addig, hogy kialakíthatóak a VLAN-ok, az AP-k tudnak multi-SSID-t, tud AP izolációt, DNS-nek használhatjuk pl. az OpenDNS-t, így a tartalomszűrés is úgy ahogy megvalósul. A dokumentáció szerint a sávszélesség limitek is beállíthatóak. Ami hiányzik, az a részletes forgalom naplózás.

2: PfSense + PiHole + Omada kontroller + AP-k

Ehhez már kellene valamilyen "szerverecske", több hálózati vezérlővel. Ez nem lesz "abszolút gondozásmentes", mert ha például virtualizálni kell (pl. Proxmox, PCI passthrough a WAN interfészre), akkor azt azért "illik" frissíteni, backup-olni. A PfSense kb. mindent megold a hálózati téren, a PiHole a tartalomszűrés + naplózás téren.

Lenne valakinek egyszerűbb ötlete? Ilyen is megfordult a fejemben hogy az 1-es verziót kiegészíteni egy PiHole-al, akár ténylegesen egy rPi-n futtatva. Ami a fenntartásom ezzel az az, hogy meddig fogja bírni a 0-24 üzemet? Továbbá, így nem redundáns a DNS.

A naplózás és a tartalomszűrés azért kell, hogy a vendégek ne tudjanak olyan tartalmakat elérni ami nem "oda való" (pornó, stb.), továbbá, ha mégis incidens történik erről a hálózatról, legyen napló hogy melyik kliens (MAC address) hova forgalmazott. A tisztán DNS alapú naplózás egy jó középútnak tűnik, tudom így nem teljes, de talán elég ahhoz hogy "bevédjük magunkat", ha egy vendég erről a hálózatról csinálna butaságokat. A jogi hátterét ennek nem ismerem pontosan.

Az egyidejű hálózati kliensek száma 60-100 között várható.

Minden ötletet szívesen fogadok, és köszönöm.

A nyitó hozzászólásomban írt megoldásokat ismerem, használom. Az UniFi új terület, de nem zárkózom el előle. Ahogy nézem árban körülbelül ugyanott lenne egy Omada-hoz hasonlítva. Mivel tényleg új terep, eszközben mit ajánlanál? Melyik lenne a szerinted megfelelő router / vezérlő? AP-k: bő 200 négyzetméter, 100+ kliens. Lehetséges hogy nem engednek mennyezetre szerelni, csak falra.

Abszolut nem.

Az összes Unifi eszközt az Unifi Network Application kezeli (ez a központi kontroller, management), és ahhoz van egy kiegészítő mobil app, amin eLéhetőek a szolgáltatásai (csatlakozni tud hozzá), vagy igény esetén, ha csak egyetlen szóló eszköz van, akkor alapbeállításokat lehet a mobil appal végezni rajta a Network App számítógépre telepítése nélkül. Maguknak az Unifi eszközöknek semmilyen webes (GUI) felületük nincs, azok csak a Netwok App-al távvézésrlést és korlátozott CLI-t tartalmaznak.

Az Unifi router-ek (talán mind) Unifi OS-t futtatnak, amin alapból fut a Network App, így ha van egy UBNT router a hálózatban, akkor már nem kell külön eszköz a Network App (központi kontroller, menedzsment) futtatására. Ha ilyen nincs, akkor lehet venni a Cloud Key-ek valamelyikét (amik dolga csak a Network App és más UBNT kontrollerek futtatása), vagy PC-n is futtatható a kontroller szoftver.

Az Unifi-Omada relációban az Unifi-vel az a gond, hogy új eszközök megjelenésekor dobják az elődöket. Az jó, hogy mindig csúcstechnikát kapsz, az viszont nem olyan örömteli, hogy ha nincs rá szükséged, akkor is csak ilyent vehetsz. Omada-nál még Wifi 4-es AP-t is vehetsz bel- és kültérit egyaránt, ha az igény kielégítésre elég az is.

Személyesen nekem még az sem tetszik, hogy az Unifi nem igazán vállalati, inkább gazdag hobbista készülékeket gyárt. Nem kell egy rack switch-re OLED kijelző meg hófehér ház és méregdrága dizájn csomagolás. De bezzeg dupla táp nincs, csak spéci külső plusz tápegység modul, spéci tápkábellel (egyik sem olcsó...), ha redundáns tápellátást szeretnél.

Az Unifi ellen szól még nálam, hogy rendszeresen több funkciót sorolnak képességnek a marketing anyagban, de azok jó része még nincs kész, és némelyekre éveket kell várni (pl. L3 képességek a switch-ekben...). Ezen felül sokak által jelzett, aránylag zavaró hibákat is képesek hónapokig nem javítani. Meg gondolnak egyet és átalakítják a rendszert, amivel eltűnnek funkciók, és mikor ezért reklamál a nép, akkor megigérik, hogy visszateszik majd valamikor. Vagy használd a legacy felületet, amin meg az új funkciók nincsenek rajta és nem lehet oda-vissza váltogatni, mert a konfig megzakkan. Összességében nem mondanám, hogy atomstabil ez a szoftveres ökoszisztéma.

Omada esetében sokkal rikábban jön új fw vagy kontroller verzió, eddig nem láttam leírva olyan képességet, ami nincs még benne. Egyébként annyi ideje van Omada, mint Unifi, csak itthon nem igazán nyomják olyan rég óta.

Félreértés ne essék, nem állítom, hogy az Omada jobb, vagy akár ugyan olyan. De az biztos, hogy az Unifi-t mélyebben megismerve azért éri nem kevés csalódás és bosszúság az embert. Nem egy enterprise cucc, az tuti.

Hardver minőség és wifi képességek terén elég közel vannak egymáshoz, messze előzve pl. a Mikrotik wifi megoldásait.

Mi mindhármat használjuk ügyfél igény alapján választva. Alapjában véve baj egyikkel sincs, stabilan működnek a beüzemelt rendszerek. Aki az egyiket ismeri, az a másikban is tud kapásból mindent (szerintem az alap kontroller szoftvert ugyan onnan veszik). Mikrotik meg külön világ, rendszerbe nem igazán használható központi management megoldás hiányában, egyesével kell mindent konfigolni (ha ez szemont).

( dentzol | 2024. 07. 06., szo – 15:19 )

pár gondolat:

- nem bízok a TP-link eszközök hosszú távú szoftveres támogatásban. Mikrotik (esetleg Openwrt) alapon építkeznék.

- pfsense mellé minek pihole?

- A mobil eszközök wifi csatlakozásnál jó eséllyel random mac-et használnak manapság.

Eddigi tapasztalataink alapján a Mikrotik elég gyenge még mindig WiFi terén.

pfsense mellé minek pihole?

Van hozzá olyan megoldás amivel láthatom pl. a feloldott hosztnevek listáját per IP / MAC, hisztorikusan?

Random MAC: valóban. Erről megfeledkeztem. Nem csak Te írtad, köszönöm mindenkinek aki előhozta! Ez esetben a Captive portal lesz a nyerő. Itt mit javasoltok? Legyen user azonosítás valamilyen alapon? Egyszerű, könnyen kezelhető megoldás kell.

Ha olyan azonosítás kell, ami jogilag is megállja a helyét, akkor az sem egyszerű, sem könnyű nem lesz.

Ugyanis meg kell adnia valami személyes adatát, és a jogi rész miatt azt vissza is kell ellenőrizd, hogy nem kamu (SMS telefonszámra, e-mail-ben kód, stb). Aztán ha ez megvan, akkor valahogy a netflow-hoz kell kötnöd a ziosztott session ID-t, hogy azonosítani tudd, melyik regésztráló csinálta melyik forgalmat. Az nem is gondolom, hogy ezt UBNT, TP-Link, Mikrotik eszközökkel meg lehetne oldani, ennyire nem szofisztikáltak.

Ezért írtam, hogy jogásszal egyeztetés után valami más (egyszerűbb) út kellene. Pl. mindenki elfogad egy felhasználási feltételek-et csatlakozáskor, a vendég wifi forgalma pedig egy elszeparált kapcsolaton megy ki (legalább külön IP cím vagy másik internet kapcsolat, mint a melóhelyi). Ezzel ugyan nem segítitek meg a bűnüldöző szervek munkáját egy esetleges puttyputty esetén, de legalább letolja a felelősséget magáról a cég, és érdemben azt tudja bizonyítani, hogy nem céges, hanem vendég volt az elkövető.

Bocsi, lehet, hogy nem volt egyértelmű, az én hibám, de erre az állításodra reagálva írtam, amit írtam:

de legalább letolja a felelősséget magáról a cég, és érdemben azt tudja bizonyítani, hogy nem céges, hanem vendég volt az elkövető.

A kürtőskalács egy nagy lyuk, tésztával faszán körbetekerve.

( GaLbi | 2024. 07. 06., szo – 17:35 )

- lehet akármilyen Wi-Fi-t használni, mert a forgalmi naplózást nem a wi-fi log alapján történik, hanem a gateway forgalma alapján kell. Ha olcsó megoldás kell, akkor Unifi, de meg lehet nézni a Aruba Instant On eszközöket is. 

- a guest network-t voucher alapú javasolt, aminél igény alapján adott névre állítod ki a hozzáférést. Így nincs jelentősége a változó MAC címnek.  

- én gateway-nek OPNSense-t javaslok, van benne captiva portál, be lehet állítani DNS alapú szűrést. (Unbound dns)

- a probléma a loggolás, mert azt külön szerverrel végeztetjük (+1 gép)  

( ggallo | 2024. 07. 06., szo – 19:00 )

Elsőre leírom ami azonnal eszembe jutott: felháborít az igény a gondozásmentes hálózatra és szolgáltatásokra. Aki ilyent akar, csináljon magának, aztán döntsön úgy, hogy nem nyúl hozzá sose.

Emiatt elsőre azt javaslom, gondold át ennek az elvállalását. Ugyanis egy ilyen rendszer, bármiből csinálod, nem lesz gondozás mentes. Ha pedig nem fizetnek a gondozásáért, akkor vagy ingyen dolgozol majd, vagy nem lesz gondozva, de ha megáll/nem jó a konfig, akkor Te leszel a hibás, mert gondozásmentest kértek.

A másik indok, amiért erősen elgondolkodnék az elvállalásán az az, hogy a fő igény a "legyen olcsó" (ezt abból gondolom, hogy ezt Te is többször leírtad, így biztos sokszor elhangzott). Pedig ez a lefedendő területtől függően a nem olcsó és a drága közé fog esni bármiből, amivel ez megvalósítható. Ezen felül a legyen olcsó ügyfélnek vannak mindig a legmagasabb elvárásai minden téren, és ezek kötnek bele az élő fába is mikor kész a rendszer. Ez valahogy mindig együtt jár.

Az igényekre:

- Tartalomszűrés nem lesz gondozásmentesen, mert a legelső nap lesz olyan, amit nem enged át, de kellene (pl. főnöknek kell a pornó meg fészbúk, de másnak nem mehet). Ezen felül tisztzni kell mennyire cizellált a szűrési igény, valamint, hogy felhasználónként változik-e és a felhasználót valahogyan authentikálni kell, vagy eszköz alapján azonosítható csak. Ez erősen befolyásolja, mivel tudiod megvalósítani.

- Seamless roaming erősen a klienseken múlik. Ha használod az erre szolgáló 802.11 kiterjeszéseket (főleg az 11r), akkor az van amivel nem kompatibilis egyáltalán (régebbi eszközök) és bajt csinál, ha meg nem használod, akkor csak teljes újra authentikációval tud csak átmenni másik AP-re, tehát nem lesz gyors a roaming. A kompatibilitási kérdések miatt pedig nem lesz gondozásmentes.

- Sávszél korlátot mind az Omada, mint az Unifi tud önmagában (nem a rendszerbe kötött router csinálja), így azt nem feltétlen kell a gateway-ig elvinni, ha csak wifi-re kell.

- Bármelyiket választod, mindenképp nézd meg, a router-eik mit tudnak, és ne tegyél abból a rendszerből router-t, ha nem tud mindent mai kell. Nem lehet belenyúlni érdemben egyikbe se hiányzó funkció esetén. Olyankor vagy Mikrotik, vagy OPNsense/pfSense. Én a Mikrotik-et javaslom, mert robosztusabb (bár kényelmetlenebb és funkciószegényebb), mint a szoftveres megoldások, amikhez még egy külön szervert is tutujgatni kell a programon felül. Nagyon nem lesz gondozásmentes.

- A legelején tisztázd, mint értenek logolás alatt. Ha teljes forgalmat, és nem csak 1-2 napra kell megőrizni, és nem csak pár user lesz, akkor bődületes tárkapacitás, és külön dedikált szerver kell majd. Meg pár szoftver, nem pár percnyi konfigurálással, amivel gyűjtöd és megjeleníted azt a forgalmat. Ráadásul ez sem lesz gondozásmentes. Mikrotik, *sense tud netflow exportot, Omada-Unifi szerintem nem tud (nem láttam még egyikben sem, igaz nem is kerestem kifejezetten).

- pfSense-t fontold meg, ha nem akarnak a fizetős Plus-ért pénzt adni, mert a communiti-ből egyre-másra szedik ki a képességeket, nehezítik az elérését, stb. Inkább OPNsense, az nincs paywall mögött. piHole-t szereintem hagyd el, az otthonra való hobbizni. Élesben több bajod lesz vele, mint hasznod. Akkor inkább a *sense-ben lévő Unbound DNS alapú szűrési képessége, plusz "gyárilag" szűrős DNS-ek használata.

- MAC address alapján hiába naplózol, semmit nem ér. Mobil eszközökön kapásból random a követhetetlenség miatt, és ha nem is lenne random, sose mondod meg, hogy az adott MAC kinek a milyéhez tartozott X ideje. Ezt a feladatot valami captive portal-os, személyt azonosító rendszerrel, és az oddani azonosító forgalmi naplózáshoz kötésével tudod elérni. Jó ötlet fentebb a voucher-ezés, de az nem a gondozásmentesség felé visz, ráadásul ott is kötni kell a voucher-t valahogy a személyhez is meg a generált forgalomhoz is. Valójában nagyon nem triviális úgy naplózni, hogy a személy köthető legyen a generált forgalmához. Plusz bejön a képbe a GDPR, adattárolás megengedett időtartama, ennek elfogadása a vendég által, lehetőség biztosítása az szonosító adatainak soron kívüli törlésére, stb. Ezt egy megfelelő tudású jogásszal egyeztetni kell, hogyan védheti meg magát a cég ilyen esetben, és aszerint eljárni. Szerintem nem a naplózás lesz a megoldás.

Egy másik, saját szoftveres megoldást szállítunk, és ennek hálózatba illesztésekor derült ki hogy az ügyfél nagyon nem jó irányba indult el. A szolgáltatója (T) rásózott egy "okoswifi" rendszert. Okos, aha... Még egy vendég hálózatot és kliens izolációt sem tud... Na mindegy, ezt eltennénk máshova, és kellene nekik helyette valami "normális". Kompromisszumok elfogadhatóak, természetesen.

Unbound alapú szűrés: megnézem! Köszönöm!

A belső hálózatos és a vendég wifi-t én fizikailag más-más AP-re szervezném, hogy ne azonos csatornákon osztozzanak.

Bár az alapelv, hogy a legjobb wifi vétel az Ethernet drót végén van, így a melós gépeket érdemes lenne nem wifi-n bekötni (és így a belső hálózatot is könnyebb védeni valamivel). Persze ez nem mindenhol opció (pl. ahol bele vannak szeretve a Mac gépekbe vagy Windows-os ultrabook-okba).

( n.balazs v | 2024. 07. 06., szo – 20:25 )

Csak pár apró észrevétel részemről:

- A mgmt VLAN-t legyen csak mgmt részre fenntartva. Ne keverd ide a belső gépeket.

- Nincs olyan, hogy biztonságos hálózat, megbízható eszköz (lásd: zero trust). Ezért ajánlom a 802.1x megvalósítását legalább a belső gépekre nézve.

- Nem tudom, hogy mekkora területet kell lefedned. Kliensszámból kiindulva nyugodtan számolhatsz legalább 4-8 AP-vel (~15 kliens/AP).

- Unifiről utóbbi pár hónapban/évben rosszakat hallok. A hardver pöpec, de a szoftverkörnyezet elkurvult.

- Én a 2. opció mellé tenném le a voksom. Sokkal rugalmasabb megoldás. pfSense helyett meg inkább OPNsense.

- Ahogy előttem is írták: Ez minden lesz, csak karbantartás mentes nem. A tartalomszűrés, logolás monitorozása ilyenek.

(~15 kliens/AP).

Az nagyon kevés lenne. Az unifi u6 doksija pl 300+ konkurens klienst ír egy AP-ra, bírjon csak harmad annyit. És elhiszem, hogy tudja is, pl rendezvényeken tudom, hogy van aki használja. (Inkább a terület lehet kérdés, amit le kell fedni + az árnyékoló falak.)

Nagyon is jól adta meg a valóságnak megfelelő számot! Mi is 15-25 kliens/AP-t számolunk. A marketing számok a valóságban nagyon távol állnak a működőtől wifi esetén.

A wifi osztott erőforrást (frekvenciát/csatornát) használ, így a kliensek azok osztoznak, ráadásul nem egyenlő arányban, és még a távolságuk sem mindegy. Namost, hiába tud CPU-val RAM-mal 300 vagy akár 100 klienst lekezelni egy AP, ha ennyien rácsatlakoznak akkor nagyjából semennyi sávszélesség nem jut nekik. Az eszközökön lesz térerő szépen, meg ez alapján mutatja a kontroller is, hogy a kapcsolat Excellent, csak aztán kilobitekben mérhető az átviteli sebesség mindenkinek...

Itthon reálisan 5G-n az alsó négy csatorna használható. A felette lévő DFS csatornákról gyorsan elváltanak az AP-k (az alsó négyre random...), mert mindig van valami nyavajás jel, amire azt hiszik, radar, és akkor tűnni kell a sávból. Az Unifi és Omada eszközök pedig egyelőre nem támogatják EU-ban a UNII-3 csatornákat (amik nem DFS csatornák). Namost, ha azzal a 4-gyel gazdálkodsz, akkor 20 MHz-es csatornát választasz, hogy mind a négy elérhető legyen (átfedés nélkül) és az egymáshoz közeli AP-ket tudd különböző frekire tenni. 20 MHz-en pedig 1 antennás kliens ~40 Mbps, 2 antennás kliens ~100 Mbps max sebességre képes ideális vételi viszonyok mellett. Namost ezen osztozik mindenki, aki az adott AP-re kapcsolódik, nem fejenként tud ennyit a wifi, hanem összesen, mindenkinek. Ez korlátozza be a valóságban/gyakorlatban egy AP-re köthető eszközök számát.

Persze, ha a kliensek esetileg forgalmaznak csak, és akkor sem sokat (pl. van 50-100 ember, telefon zsebben és csak push üzenetek jönnek, meg néha egy-egy valami), úgy több kliens is "működik" egy AP-vel. De valódi hálózat használat mellett nem (pl. laptopon dolgoznak, azon érik el a helyi hálózatot).

Ráadásul figyelembe kell venni, hogy hiába van egy AP-n több SSID, azok mind-mind ugyan azon a csatornán így sávszélen osztoznak. Így ha a belsősök az adott AP-n lokális hálózatot használnak laptopról folyamatosan, akkor a vendég SSID-n nem lesz internetes virgonckodás mondjuk mobillal nemhogy 100, de 10 embernek se...

Ha a felhasználói élmény fontos a klienseken, akkor 15-20 kliens/AP-vel lehet számolni.
Nem arról van szó, hogy egy AP ne bírna el 300 klienst is. A kérdés, hogy milyen élményt, sávszélességet tud biztosítani. IoT, alacsony sávszélességet igénylő, nem késleltetés kritikus kliens eszközök esetén igen, többet is elbír egy AP.

Kis számolgatás a sávszélességről:
Vegyünk példának egy Unifi U6 Pro-t. Van neki 1 darab 1 GbE interfésze. Ha azon 15 kliens osztozik, akkor átlag 66 Mbps esik egy kliensre. 300 kliensnél 3 Mbps. És hiába tud papíron 4,8 Gbps-t 5 Ghz-n, ezt nem fogja vezetékes oldalon bírni. Specifikáció: https://techspecs.ui.com/unifi/wifi/u6-pro

Az még hagyján, hogy nem bírja a 4.8 Gbps-t az 1 GbE kapcsolatán, de nem a vezetékes oldalon van a szűk keresztmetszet, hanem a rádióson. Kapásból nincs olyan kliens, amin ilyen antenna/MU-MIMO konfiguráció elérhető (nincsenek 4 antennás, 1024QAM-et tudó kliensek...). Jó, ha van két antenna (stream) a kliensnek, és ha modern (ac-s vagy ax-es), akkor tud 256QAM-et, amivel lesz neki (2 stream esetén) 160 Mbps névleges sebessége 20 MHz csatornán, ha egyedül van kapcsolódva. Aki ennél gyengébb képességű kliens, vagy többen vannak, annak ennyi se jut ideális esetben.

Mindig a rádiós részre kell tervezni (szerintem), mindig az a kevés.

MCS Index

Ami még fontos lehet - bár közvetetten leírtad: A wifit mindig a leggyengébb szabványt / modulációt tudó kliens fogja megfogni. Hiába az 5 Ghz, ha van 2,4-s kliens is vagy a router tud 1024 QAM-t (Wifi 6, ax), de a kliens csak 64 QAM-t (Wifi 4, n).

Tény, hogy a rádiós rész roppant gyorsan elfogy.

en is megerosithetem. mikrotikkel anno mar 3 kliens is sok volt, unifi ahhoz kepest maga volt a mennyorszag hogy nem rohadt le 10 klienstol se :)

persze ha csak lognak rajta es nem csinalnak semmit akkor elfer a 100 is, de ha kozbe megy egy kis torrent, youtube, tiktot, zoom/teams streaming stb akkor hamar elfogy a "levego".  olyan 30-40 kliens korul szoktak elkezdeni panaszkodni az usreek U6-LR eseten, de a controller szerint minden rendben...

meg az se mind1 melyik sav, 2.4ghz vagy 5ghz... vagy megoszlik koztuk...

( dlaszlo | 2024. 07. 06., szo – 20:39 )

2 db Unifi U6-LR + 1 db Unifi U6+ van itthon egy Mikrotik routerrel. Egy adguard fut (korábban RPI-n futott), és az unifi controller is korábban RPI-n futott (tökéletesen ment rajta).

Harmad ennyi kliens van itthon, de szerintem a 60-100-at is tökéletesen vinné, és amióta Unifim van, tökéletes a lefedettség az egész házban + kertben.
Csatorna probléma is volt korábban, rengeteg zaj jött kívülről, és ez most valahogy nem gond.
Az eszközök tökéletesen átcsatlakoznak egyik AP-ról a másikra, szakadás mentesen.

Korábban Mikrotik AP-im volt, hát, nem így működött. Lefedettség problémák voltak, és a roaming sem működött rendesen.

A TP-linket nem ismerem.

( arpi_esp v | 2024. 07. 06., szo – 23:26 )

a logolas izgi lesz.  es nem csak a random mac cimek miatt.

ugye DoH miatt nem latod a dns kereseket se, a httpS miatt meg mar azt se nagyon (tls 1.2-ig ugye ki lehetett nezni legalabb a domaint, 1.3-tol ennek is vege) mit nez (es ugye minden nagyobb cucc mar cdn-eneken van, a cel ip-vel se mesz sokra)

persze ha logolod idopont + forras mac/ip + cel ip, azzal te teljesited a kotelesseged, onnantol oldja meg az erdeklodo szerv problema eseten hogy ebbol hogy lesz ertelmes info :)

amugy mintha lenne olyan is hogy csak ugy nem lehet wifi-internetszolgaltatokent mukodni, egyreszt az uplinket szolgaltato isp se szokta engedni szerzodesileg, meg mintha valami jogszabaly is lenne ra, de ez meg mar legyen az ugyfel problemaja. persze ha csak a sajat dolgozoinak/vendegeinek szolgaltat akkor nem akkora para gondolom.

a logolas izgi lesz.  es nem csak a random mac cimek miatt.

ugye DoH miatt nem latod a dns kereseket se, a httpS miatt meg mar azt se nagyon

Egy proxy minden ilyen igényt megold.

Internet elérés csak azon kerszuetül, ott meg lehet authentikálni, logolni, URL szűrni, meg amit akarsz.

 

szerintem.

zrubi.hu

MITM proxy SSL végződtetéssel? Na azt meg épeszű felhasználó nem fogja igénybe venni és jogilag is elég csücskös vendég hálózaton, hisz velük nem állsz olyan szerződésben, hogy a hálózatra csatlakoztatott eszközeiken csak és kizárólagosan céges forgalmat bonyolíthatnak. Mondjuk feltéve hogy észreveszik ugye. Nekem a secure DNS ha nem tud zártan hazahívni, közli hogy nincs internet.

Több majdnem működő van :) Az általad említett wpad, a dhcp option 252 és egy .pac file.

Persze Windows group policyból beállítható.

De annak idején, amikor egyik proxyról a másikra váltottunk úgy, hogy a cím is változott, és nem akartunk big bang módszerrel átállni, akkor eltartott egy ideig, amíg majdnem mindenkit átállítottunk (több ezer kliens + jó néhány server, elég vegyesen)

A dhcp opcióval még lehet játszani valamennyit, az működhet guest wifin is. A domain policy értelemszerűen nem. Nálunk a guest wifit megoldottuk azzal, hogy minden átmegy a proxyn, az is, ami nem :), mert a proxy egyben a default gw is és transzparensen is elkapja a http/https-t. Persze ssl felbontás ott nincs, viszont amúgy is meglehetősen korlátozott a szűrés kategória szerint. Autentikáció természetesen nincs, mert transzparens proxynál az nem megy. Akinek meg nem megy valami, az így járt, ajándék ló esete.

transparens proxyt en is hasznaltam regen, squid es ffproxy is, de tobb dolog nem mukodott mint ami igen, igy elegem lett a folyamatos nyavajgasbol aztan offoltam... eredetileg volt igeny a vezetoseg reszerol hogy megnezze ki mit csinal, de ez egyreszt jogilag is neccess lenne, masreszt a gyakorlatban vegul sose akartak megnezni, igy folosleges volt teljesen.

ma meg mar 99.9%-ban https-en megy minden, igy tok folosleges lenne.

azt gondolom megint túlkomplikáltok mindent. Nem kell proxy szinten szűrni. A guest wi-fi lényege az, ha jön egy vendég, akkor tudjak a részére biztosítani internet elérést:

- a helyi kontakt, aki kapcsolatban van a vendéggel igényli a vendéghozzáférést. Itt meg kell adni kötelezően ki az illető, tehát megvan az azonosítás. 

- captive portálon authentikálom, hogy hogy a tudjam a session alapján nyomon követni a logban

- minimális szűrést rakok be (max DNS, nem használok semmilyen proxy-t), mert akkor nem lesz probléma a vendég oldali extra szoftverekkel (VPN)