Configurați limita de viteză pentru utilizatorii din calamari - rețineți-i că este specialist

Configurați limita de viteză pentru utilizatorii din calamari - rețineți-i că este specialist
Tema limitei de viteză prin serverul proxy de squid a fost deja ridicată pe paginile blogului nostru, însă am considerat opțiunea cu restricție pentru nodurile de rețea și segmentele sale, fără să atingem problemele legate de autentificarea utilizatorilor. În același timp, administratorii rețelelor mari se confruntă cu problema limitării vitezei utilizatorilor și grupurilor, inclusiv a celor bazate pe calitatea de membru în grupurile Active Directory. Astăzi vă vom spune cum se poate face.







După cum știți, primele trei clase de bazine funcționează cu rețele, subrețele și noduri specifice. Există concepții greșite comune că bazinele lucrează cu elemente ACL, iar conținutul lor nu este atât de important. Desigur, noi înșine am fost sub influența lor, dar cel mai bun mod de a risipi concepțiile greșite este de a verifica totul pe propria experiență.

Empiric, sa constatat că în cazul în care elementul de ACL nu conține descrieri de rețele pentru clasele 1-3 piscine, subrețele sau gazde, atunci conținutul său atunci când se utilizează bazine de întârziere vor fi ignorate. Astfel, pentru a lucra cu utilizatorii ar trebui să fie utilizate numai bazine de gradul 4, care, în plus față de setările pentru rețelele și gazdele conțin o setare separată pentru utilizator autentificat.

Și dacă descrierea piscinei din clasa a treia arată astfel:

apoi în clasa a patra, se adaugă setări de utilizator

Prin urmare, în clasa ACL folosită pentru piscina din clasa 4, utilizatorii trebuie să fie prezenți, altfel o astfel de piscină nu va funcționa.

Cum se aplică această clasă de bazine? Să începem cu cea mai simplă sarcină: vom limita viteza pentru toți utilizatorii care au fost autentificați la proxy.

Mai întâi de toate, am setat elementul ACL pentru ei:

Apoi descriem piscina:

Prima linie am specificat numărul de bazine, apoi le-am enumerat cu numărul și clasa, apoi am plasat lista de acces de mai jos, permițând numai acele elemente de autentificare ACL să lucreze cu grupul - adică toți utilizatorii autentificați. În cele din urmă, am setat limitele de viteză. Primele trei opțiuni pe care le-am stabilit fără limite, iar în cele din urmă am indicat viteza maximă pentru utilizator la 1,25 MB / s = 10 Mbps.

Configurați limita de viteză pentru utilizatorii din calamari - rețineți-i că este specialist

În acest caz, piscina poate fi utilizat pentru limitele de viteză pentru gazde și subrețele. Pentru a face acest lucru, selectați setările corespunzătoare, și există o altă listă, se adaugă ACL de acces care conține noduri și rețele, în acest caz, piscina de muncă nu va diferi de la piscina de clasa a treia, iar setările vor fi ignorate pentru utilizatori.







Am creat două elemente ACL: pentru un anumit tip de PC public, de la care accesul la rețea se va face fără autentificare și pentru utilizatorii autentificați. Apoi, lista de acces pentru PC-ul public a fost plasată deasupra listei de acces pentru utilizator, altfel proxy-ul va necesita mai întâi autentificarea.

În cele din urmă, am definit două liste de acces pentru pool, în acest caz ordinea lor nu este deosebit de importantă, deoarece elementele ACL conțin diferite tipuri de date și nu se suprapun reciproc. În setările bazinului, am setat viteza la 10 Mb / s atât pentru nod cât și pentru utilizator. Combinarea setărilor ar trebui să țină seama de cuibărirea lor, restricțiile pentru utilizator luând în considerare, de asemenea, restricțiile pentru nod, subrețea și pentru piscină ca întreg. De exemplu, limitând viteza nodului la 1 Mbps și lăsând 10 Mbps pentru utilizator, tot nu vom obține o viteză mai mare de 1 Mbps.

Până în prezent, am operat cu privire la noțiunea generală de utilizatori, însă în majoritatea cazurilor sunt necesare restricții pentru anumiți utilizatori sau grupuri. Dacă Squid își face autentificarea propriu-zisă a utilizatorilor, puteți să enumerați pur și simplu numele necesare din descrierea ACL. De exemplu, divizăm Internetul într-un grup mic pentru seful și subordonații.

Acum avem două elemente ACL, primul este un utilizator numit șef, iar al doilea este angajații Ivanov, Petrov și Sidorov.

Vom crea două bazine din clasa a patra și vom specifica liste de acces pentru ele:

Acum setați parametrii bazinelor. Pentru șef nu există restricții și la prima vedere ar fi logic să indicați:

Dar a fost stabilit experimental că, în acest context, accesul la Internet va fi dificil, în practică se exprimă prin descărcarea nesfârșită a unor site-uri.

Prin urmare, ar trebui să indicați în mod explicit viteza, de exemplu, viteza maximă a canalului sau o valoare semnificativ mai mare. În cazul nostru, vom specifica 100 Mbps pentru șef și 10 Mbps pentru angajați.

Dacă utilizați autentificarea prin intermediul unor servicii externe, de exemplu, prin intermediul directorului Active Directory, este mult mai convenabil să nu funcționați decât de către utilizatori, ci de către grupuri. Pentru a obține informații despre calitatea de membru al unui anumit grup, sunt folosite utilitare externe - ajutoare, care sunt manipulate de o directivă specială external_acl_type. Mai multe detalii despre acest lucru pot fi găsite în articol:

Nu vom analiza în detaliu această problemă și vom lua ca exemplu setările din articolul specificat. Vom verifica calitatea de membru al utilizatorilor din două grupuri de domenii și, pe baza acestora, le vom plasa într-unul din elementele ACL:

Și cum rămâne cu cei care nu au intrat pe nici o listă? Dacă vă lăsați la asta, atunci nu li se aplică nici o restricție. Prin urmare, vom crea cea de-a treia piscină, asigurându-ne înainte de faptul că avem un element ACL pentru toți utilizatorii.

Atunci vom lista lista de acces pentru ei și vom pune-o la ultimul. Listele sunt procesate în ordinea priorității și până la primul meci, astfel încât numai cei care nu intră în altă listă vor ajunge la aceasta. Ie aceasta va fi corectă astfel:

În acest caz, poziția relativă a listelor pentru administratori și utilizatori nu este critică, deoarece conținutul lor nu se suprapune, dar dacă brusc orice utilizator ar fi în mai multe grupuri, limitarea de lucru a piscinei, regula pentru care este mai mare pe lista pentru el, deși astfel de situații ar trebui evitate ori de câte ori este posibil.

Pentru a înțelege mai bine regulile de lucru și de depanare, puteți include jurnale avansate, pentru aceasta adăugați directiva la secțiunea corespunzătoare din fișierul de configurare:

După aceasta, evenimentele asociate cu grupurile de întârziere vor fi scrise în fișierul /var/log/squid3/cache.log. Să examinăm un exemplu de astfel de jurnal:

După cum puteți vedea, nu este nimic dificil pentru utilizatori să limiteze viteza, trebuie doar să înțelegem principiul bazinelor de întârziere și să nu confundăm obiectele la care se aplică restricțiile.

Materiale suplimentare:







Articole similare

Trimiteți-le prietenilor: