Elosztott hitelesítő portál nyilvános helyeken és nehézségek alma, savepearlharbor
Részt vettünk az olyan köz- hálózatok elosztott hitelesítő portál és megtámadta szinte az összes rake, ezért szeretnék megosztani a tapasztalatokat.
Már a kezdet kezdetén - egy kis elmélet arról, hogyan működik, és hogyan oszlik portálok eltérnek centralizált. Ideológiailag, mi hívtuk a Captive Portal, valójában az alábbi három összetevőből áll:
tűzfal - felelős a hozzáférést az egyes felhasználók a hálózaton. Ha nincs hozzáférési ideológiai okokból - átirányítja a felhasználó az interneten frontend. Abban az esetben való hozzáférés hiánya technikai okokból (nem ping a gateway), akkor utasíthatja a tűzfal, hogy végre a felhasználó átirányítás egy külön oldalt „nincs szolgáltatás, de fix küzd.”
Abban az esetben, központosított hitelesítő portál mindhárom komponens nyilvánvalóan helyezkedik egy gépen (készülék), ami nagyban egyszerűsíti a feladatot. Tűzfal ebben az esetben gyakran több és a NAT és a hitelesítő portál lehet végrehajtani formájában egy csomó scriptek podkruchivayut helyi iptables. Van egy nagyszerű vágy natolkat olcsó hálózati hozzáférési pontot, amely esett nekünk az összes felhasználó egy ethernet, vagy a legjobb esetben - egy külön VLAN. Mi a probléma:
- Biztonsági problémák. Mi korlátozza a hozzáférést a külső vonal, de minden rossz a helyi hálózaton. Mivel a hálózat nyitott, bárki válaszolni ARP nevében a mi az alapértelmezett átjáró, megkapja a felhasználói forgalmat és vegyen részt a phishing. Nem tilos tegye fel a DHCP szervert és egy bizonyos delta-szomszédságában stremayutsya felhasználók nyilatkozatok, mint „a böngésző reménytelenül elavult.” Ha a hitelesítő portál és a felhasználó osztja a router, akkor nincs ellenőrzés a hitelesítő portál megfelelő mac és ip annak minden következményével együtt. A kommunikáció a vezeték nélküli kliensek válik lehetővé. Akkor pont az olcsó tiltják a vezeték nélküli ügyfelek kommunikálni, de az ügyfelek más pontokon már láthatók az ethernet.
- Problémák a forgalom. Van egy helyi hálózaton egy csomó extra forgalmat. Előnyösen megnyitása előtt hitelesítő portál ügyfelek több hozzáférési pont nem engedélyezettek.
- Problémák a skálázhatóság. A nagy számú problémás ügyfelek közül bármelyik lehet a három komponens a portál.
Ahogy talán már sejtette, elosztott hitelesítő portál célja, hogy megoldja ezeket a problémákat. Apropó „elosztott”, azt feltételezzük, hogy az alkatrészeket lehet helyezni a különböző eszközökön. Ez lehetővé teszi számunkra, hogy hozzon létre egy megbízható rendszert, amely biztosítja a kívánt biztonsági szintet és a szolgáltatás, miközben nagy lehetőségek rejlenek a skálázhatóság. A probléma, amit meg kell oldani - így komponensek közötti kölcsönhatás fogságban portálon. Amennyiben meg kell elhelyezni összetevői a megoldást?
Tűzfal legyen a lehető legközelebb a kliens, azaz a egyedülálló a hozzáférési pontot. Mivel a hozzáférési pontok kevés és mindegyikben - a tűzfal, akkor a munkájuk szinkronizálni kell egy bizonyos helyen vagy területen, amelyen belül azt feltételezzük ügyfél roaming. Ellenkező ügyfelek barangoló fogunk tapasztalni a kommunikáció. A mai hálózatokban, a feladat szinkronizálása működésének valamit egy bizonyos területen belül (RF-domain) keresztül végezzük kijelölt választottbírák (témagazdáknak RF) és megoldották a régi időkben, tekintet nélkül arra a problémára, megvalósítása elosztott hitelesítő portál. Ennél a rendszernél az időzítés a tűzfal - csak egy a folyamatokat kell végrehajtani a koncert domain, együtt (például) forgalmak, szinkron pont konfiguráció, illetve a statisztikai adatgyűjtés.
Hely web frontend helyzetben erősen függ bonyolítja a feladat, hogy meg kell oldani. Ha szükség van megmutatni az oldalon, feltételezve, hogy nincs szerver oldali feldolgozás, vagy bizonyos típusú ömlesztett SMS bonyolultságot lehet kezelni a szerver a hozzáférési ponton. Ő újra, olyan közel, hogy az ügyfél, és biztosítja a leghatékonyabb kölcsönhatás vele. Tartalom szinkronizálása webszerverek különböző hozzáférési pontokat is részt (meglepetés) menedzser RF-tartományban.
Hely hitelesítő portál elrendezés pozíciójától függ a webes felületen, illetve hozzáférési pontokat. Mivel az a cél hitelesítő portál kanyargó tűzfal, akkor megvan a reprezentáció (ügynök) minden ponton. A web frontend képes kommunikálni a másolatok ezen szerek miatt az állapotát (kitaláltad) is összehangolták tartományon belüli.
Módszer kölcsönhatás hitelesítő portál. Szükségünk van egy olyan mechanizmus, amellyel meg tudjuk tájékoztatni a portál felhasználói beavatkozást. Ebben az esetben a HTTP GET választottuk ezt a mechanizmust. Amennyiben szükséges, emelje fel a portál küldünk HTTP GET annak bármely irodák. Készítmény továbbítani GET paraméter függ a mód, amelyben a portál működik. Számos módja van:- A portál mindig kinyílik. Talán hozza meg a megfelelő bejegyzést a naplóban.
- A portál nyílik jelenlétében GET változó, ami a feltételek a megállapodás (Megállapodás).
- A GET telt felhasználónevét és jelszavát, a portál maga felmászik a RADIUS ezeket a tulajdonságokat, és megnyitja odaértünk ACCEPT.
- A GET továbbítjuk egy (univerzális) attribútum portál jelzi neki, mivel mind a felhasználónév és jelszó, ha a kapcsolatot a RADIUS és beérkezett ajánlatok ACCEPT. Magától értetődik, hogy egy ilyen felhasználónak kell RADIUS
Ideális esetben, az a pont hordoz áthidaló (továbbítási Layer 2) közötti SSID és egyes VLAN vezetékeket. Azaz tűzfal fut a második (MAC) szintet. Mivel a tűzfal látja érkezett DHCP-hez a belek hálózati kliens, tudja, hogy a VI ez a feladata az ügyfél helyett az ARP és mereven szűri ARP és a DHCP a vezeték nélküli szegmensben.
Mit jelent az Apple
És miért mindannyian, mint a metró, ayfonchegi hogy ne jöjjenek létre portálon.
Abból, ahogy ayfonchiki viselkednek a vezeték nélküli hálózatok, már szilárd meggyőződése, hogy az alkotók ezt megaprodukta feltételezett egyetlen forgatókönyv, azaz - egy hozzáférési pont. Azaz, akár otthon, akár egy kávéházban hipsters. A második esetben van esély, hogy megfeleljen neillyuzorno hitelesítő portál.
Mi tart ayfonchik találkozott ugyanazzal az SSID azonnal 2,4 és 5 GHz? Azt hitted, hogy egyensúlyt vevői csatornák, pontok és tartományok, maximálisan kihasználva a lehetőséget, az ügyfelek és a hálózati sávszélességet? Nem csak az Apple termékek! A hálózati oldalon, a meghallgatását ügyfél kéri mindkét tartományban, akkor feltételezhetjük, hogy tudjuk kényszeríteni a kliens kapcsolódni, hogy hol kell, átadva kéri arra a pontra, ahol nem akarjuk azt, hogy csatlakozik. Jellemzően az ügyfelek megértsék a célzást, és össze vannak kötve, például az 5 GHz. IPhone 2.4 megtöri az utolsó. Mert tolóerő egy külön méter (20 kérések alapértelmezés szerint egy sorban). Túl, ez időt vesz igénybe.
Leírt két folyamat nem csak akkor, amikor csatlakozik a hálózathoz, de akkor is, ha roaming, ha megy elég messzire. Ó, itt az új pontot. Nos, nézd ...
Remélem most már értem, hogy miért a metró leállt észlelési portál.
By the way, észlelési készülék ki van kapcsolva, egyetlen paranccsal: