Am participat la crearea de rețele publice cu portal captiv distribuite și au atacat aproape toate rake-ul, așa că vreau să împărtășesc experiența.
Pentru început - o mică teorie despre cum funcționează și cum distribuite portaluri diferă de centralizat. Ideologic, ceea ce am folosit pentru a apela portal captiv, acesta este, de fapt format din trei componente:
firewall - este responsabil pentru accesul utilizatorilor individuali în rețea. În cazul în care nu există acces din motive ideologice - redirecționează utilizatorul către frontend web. În cazul lipsei de acces la motive tehnice (nu ping gateway), puteți instrui firewall-ul pentru a efectua redirecționarea utilizatorului la o pagină specială „nici un serviciu, dar ne fixam luptă.“
În cazul unui portal captiv centralizat toate cele trei componente este, evident, situat pe o singură mașină (aparat), care simplifică foarte mult sarcina. Firewall, în acest caz, durează mai mult și de multe ori NAT, precum și cu portal captiv poate fi implementat sub forma unui buchet de script-uri care podkruchivayut iptables locale. Există o dorință formidabilă natolkat punct de acces la rețea ieftine, care a scăzut la noi de toți utilizatorii de pe o rețea Ethernet, sau în cel mai bun caz - un VLAN separat. Care este problema:
- Probleme de securitate. Noi restricționa accesul la linia externă, dar totul este rău în rețeaua locală. Având în vedere că rețeaua este deschisă, oricine poate răspunde la arp în numele gateway-ului nostru implicit, primesc trafic de utilizator și să se angajeze în activități de phishing. Nu este interzis pentru a pune la serverul DHCP și la un anumite declarații ale utilizatorilor delta-cartier stremayutsya ca „browser-ul dvs. este iremediabil de actualitate.“ În cazul în portal și utilizatori captive partajează router, atunci nu ai nici un control asupra captivă mac de potrivire portal și IP cu toate consecințele. Comunicarea dintre clienții wireless devine posibilă. Puteți indica ieftine interzică clienții wireless pentru a comunica, dar clienții din alte puncte sunt deja vizibile pe Ethernet.
- Probleme cu trafic. Avem o rețea locală o mulțime de trafic suplimentar. De preferință, înainte de deschiderea clienților captivi portalului mai multe puncte de acces nu sunt permise.
- Probleme cu scalabilitate. Cu un număr mare de clienți problemă poate fi oricare dintre cele trei componente ale portalului.
După cum probabil ați ghicit, distribuit portal captiv conceput pentru a rezolva toate aceste probleme. Vorbind de „distribuite“, presupunem că componentele pot fi plasate pe diferite dispozitive. Acest lucru ne va permite de a crea un sistem fiabil, care va asigura nivelul dorit de siguranță și de servicii, având în același timp un mare potențial de scalabilitate. Problema pe care trebuie să o rezolvăm - pentru a asigura o interacțiune între componentele unui portal captiv. În cazul în care trebuie să fie amplasate componente ale unei soluții?
Firewall trebuie să fie cât mai aproape posibil de client, și anume, unic în punctul de acces. Deoarece punctele de acces sunt puține și în fiecare dintre ele - un firewall, atunci activitatea lor ar trebui să fie sincronizate într-un anumit spațiu sau o zonă în care se presupune roaming pentru clienți. În caz contrar, clienții serviciului de roaming atunci când se va confrunta cu probleme legate de comunicare. În rețelele de astăzi, sarcina de sincronizarea funcționării ceva într-o anumită zonă (RF-domeniu) se realizează prin intermediul arbitrilor desemnați (domeniu de manageri RF) și a fost rezolvată în zilele vechi, fără a ține cont de problema implementării unui portal captiv distribuit. Pentru acest sistem, funcționează firewall-ul de sincronizare - doar un alt proceselor care urmează să fie efectuate în domeniul de concert, împreună (de exemplu) comutate de trafic, configurații de puncte de sincronizare sau colectarea de statistici.
Locul poziția web front-end depinde foarte mult de complexitatea sarcinilor pe care le are de rezolvat. Dacă este necesar să se arate pagina, presupunând că nici o prelucrare partea de server, sau un anumit tip de complexități de mesaje SMS în vrac, este posibil să se administreze serverul de pe punctul de acces. El, din nou, este cât mai aproape de client și asigură interacțiunea mai eficientă cu el. Sync servere de conținut web la diferite puncte de acces vor fi angajate (surpriza) manager de RF-domeniu.
Locul aspect portal captiv depinde de poziția punctelor de frontend web și acces. Având în vedere că obiectivul este captiv firewall-ul portal de rasucire, acesta trebuie să aibă reprezentarea (agentul) la fiecare punct. Cu toate acestea, web poate comunica front-end cu oricare dintre copiile acestor agenți, din cauza statutului lor (ați ghicit) sunt, de asemenea, sincronizate într-un domeniu.
interacțiune Metoda cu portal captiv. Avem nevoie de un mecanism prin care putem informa portalul de interacțiune cu utilizatorul. În acest caz, GET HTTP a fost ales ca un astfel de mecanism. Dacă este necesar, ridicați portalul vom trimite HTTP GET în oricare dintre sediile sale. Compoziția transmisă în parametrul GET depinde de modul în care funcționează portalul. Există mai multe opțiuni:- Portalul se deschide întotdeauna. Poate aduce un record de ea în jurnal.
- Portalul se deschide în prezența variabila GET, reflectând termenii acordului (acord).
- Numele de utilizator și parola trecut GET, portalul se urcă la radiala cu aceste atribute și deschide ajuns acolo ACCEPT.
- EEG este transmis unul (universal) atribuie portalul el indică atât numele de utilizator și parola atunci când contactați radius și oferte primite ACCEPT. Se înțelege că o astfel de utilizator ar trebui să fie RADIUS
In mod ideal, punctul transporta punte (forwarding Layer 2) între SSID și anumite fire VLAN. Adică firewall-ul care rulează pe al doilea nivel (MAC). Deoarece firewall-ul a ajuns la DHCP vede oferiți clientului măruntaie de rețea, el știe de anchetă, aceasta este responsabilitatea în locul clientului la ARP și rigid filtrează tot ARP și DHCP pe segmentul wireless.
Ce Apple
Și de ce noi toți, cum ar fi metroul, ayfonchegi asigura că nici un portal.
Din modul în care se comportă ayfonchiki în rețelele fără fir, am convingerea fermă că creatorii acestui megaprodukta presupune doar un singur scenariu, și anume - un punct de acces. Adică, fie acasă, fie într-o cafenea pentru Nonconformiști. În al doilea caz, există o șansă de a întâlni neillyuzorno portal captiv.
Ce este de a lua ayfonchik, sa întâlnit același SSID imediat la 2,4 și 5 GHz? Ai crezut că poți echilibru între canalele de client, punctele și intervale, ceea ce face utilizarea maximă a posibilității clienților dumneavoastră și de lățime de bandă de rețea? Nu numai cu produsele Apple! Partea de rețea, ascultarea cererilor clienților în ambele domenii, putem presupune că putem obliga clientul să se conecteze la cazul în care avem nevoie, trecând cererile de la punctul în care nu vrem ca acesta să fie conectat. De obicei, clienții să înțeleagă aluzia și sunt conectate, de exemplu, în 5GHz. IPhone 2.4 va rupe la ultimul. Pentru forța de tracțiune este un contor separat (20 de cereri implicit într-un rând). Prea, este nevoie de timp.
Descris două procese au loc nu numai când este conectat la o rețea, dar, de asemenea, atunci când roaming, dacă nu merge suficient de departe. Oh, aici noul punct. Ei bine, verifica ...
Sper că acum înțeleg de ce metroul închide portalul de detectare.
Apropo, echipamentul nostru de detectare este oprit cu o singură comandă: