15.2. Instalarea SQUID SQUID poate fi instalată din sursă sau ca pachet RPM. Instalarea SQUID RPM este foarte ușoară - doar tastați rpm –ih squid-2.3.STABLE2-3mdk.i586.rpm Folosesc squid 2.3. O versiune mai nouă este disponibilă ca coduri sursă. Sursele pot fi

15.4. Pornirea SQUID Acum că ați făcut setarea de bază a SQUID, trebuie să-l porniți: /usr/local/squid/bin/squid -z Opțiunea -z este necesară pentru a crea (zero out) directorul care conține memoria cache. De obicei, acest parametru este necesar doar la prima pornire. Alte opțiuni utile SQUID

15.5. Formatul fișierului squid.conf Fișierul squid.conf specifică diferite opțiuni de configurare a serverului proxy. Să le aruncăm o privire pe toate

17.1.5. Configurarea Squid Instalați pachetul Squid. Rămâne de configurat și de rulat. Pentru a face acest lucru, editați fișierul de configurare /etc/squid/squid.conf. Mai întâi, specificați adresa proxy a furnizorului: cach_peer proxy.your_isp.com Setați cantitatea de RAM care va fi utilizată de serverul proxy: cache_mem

Capitolul 18 Servere proxy SQUID și SOCKS Secțiunea 18.1. Ce este un server proxy? Un server proxy (server intermediar) este un program care face cereri HTTP/FTP în numele clienților. Utilizarea unui server proxy face posibilă utilizarea adreselor IP fictive în rețeaua internă (IP masquerading),

18.2. Instalarea SQUID Folosesc versiunea 2.5 de squid. Pachetul squid este inclus în distribuțiile moderne, iar dacă din anumite motive nu îl aveți, îl puteți descărca de pe www.squid-cache.org Când construiți SQUID din codurile sursă, primul pas ar trebui să fie comanda # ./ configure --prefix=/ usr/local/squidSQUID va fi instalat în director

18.3. Configurarea SQUID Serverul SQUID folosește fișierul de configurare squid.conf, care se află de obicei în directorul /etc/squid (sau /usr/local/squid/etc în versiunile anterioare). Vom discuta despre setările individuale mai detaliat puțin mai târziu. Acum, să configuram doar pas cu pas SQUID.

18.4. Pornirea SQUID Prima dată când porniți Squid cu opțiunea -z pentru a crea și curăța directorul cache: # /usr/local/squid/bin/squid -z Câteva alte opțiuni utile cu care puteți începe Squid sunt listate în Tabel 18.2 Opțiuni de pornire squid Tabelul 18.2 Scop cheie -a portul Specifică

18.5. Setări avansate SQUID. Fișierul de configurare squid.conf 18.5.1. Opțiuni de rețea Următoarele opțiuni de rețea pot fi setate în fișierul squid.conf:? http_port - port pentru cererile clientului. Din acest port, serverul proxy va asculta și procesa cererile clientului. Valoare implicită

18.8. Partajarea canalelor utilizând SQUID Să presupunem că doriți să configurați un server proxy, astfel încât un grup de computere să navigheze pe Internet cu o viteză și altul cu o viteză diferită. Acest lucru poate fi necesar, de exemplu, pentru a face distincția între utilizatorii care

9.3. squid După cum am spus, cel mai comun server proxy este squid. Acest server are o istorie destul de lungă, iar pe parcursul existenței sale au fost implementate multe caracteristici. Nu a fost încă nimic pe care să nu-l pot obține cu calmar. De bază

9.4. permisiuni squid Acesta este cel mai dureros subiect pentru orice administrator. Da, și squid are și permisiuni și sunt descrise și în fișierul de configurare /etc/squid/squid.conf. Dar considerăm drepturile separat, deoarece accentul principal este pus pe securitate. De aceea

9.5. Note despre rularea squid Acum trebuie să vorbim puțin despre unele dintre problemele de securitate ale serviciului squid și despre caracteristicile suplimentare care pot accelera munca în

12.5.4. Jurnalul proxy squid Principalul jurnal proxy squid este /var/log/squid/access.log. Acesta este un fișier text în care fiecare linie constă din următoarele câmpuri:? ora de începere a conexiunii sau a evenimentului;? durata sesiunii? adresa IP a clientului;? rezultatul procesării

Configurare Squid Proxy

Foarte des avem nevoie de un proxy. De exemplu, aveți un IP gri sau sunteți un utilizator fericit al internetului prin satelit. Descărcarea ceva de pe site-uri precum Rapidshare este nerealistă. Aici calamarul vine în ajutor.

Pentru a instala un proxy, aveți nevoie de un server pe virtualizarea KVM. Serverele proxy nu sunt permise pe alte virtualizări.

O versiune mai extinsă a articolului meu poate fi găsită pe site-ul Kursky LUG, unde am luat în considerare și posibilitatea utilizării calmarului de către utilizatorii casnici, precum și integrarea unui sistem de compresie a traficului Globax sau Toonel în cascadă în calmar.

Instalarea calmarului

Instalarea calamarului

Un pic despre acl și reguli

Inima configurației de calmar este acl(lista de control acces) și reguli.
Mai întâi trebuie să înveți cum funcționează acl. ACL-urile au următorul format:

Acl<имя> <тип> <содержание>

De exemplu, acest acl descrie două mașini utilizator cu adrese IP (tip src) 192.168.0.1 și 192.168.0.2

Acl comps src 192.168.0.1/32 192.168.0.2/32

Acum să ne uităm la reguli.
Regulile au următorul format:

<тип_правила> <действие>

În această etapă, trebuie să înveți că regulile unu tipurile sunt verificate înainte primul regula de rulare. Acțiunea acestei reguli va fi executată și verificarea altor reguli de acest tip va fi oprită. Exemplu:

acl all src 0/0 acl vasya src 192.168.1.12/32 http_access permit vasya http_access deny all

Reguli de tip http_access acestea sunt regulile care permit sau interzice accesul pe http. Luați în considerare acțiunea pasajului de mai sus. acl all ne indică toate adresele IP. Și acl vasya indică un ip 192.168.1.12
Verificarea va decurge astfel:
1) http_access permit vasya Dacă un utilizator de la această IP se află prin proxy, atunci îi vom permite accesul. Verificarea va fi oprită, a patra linie nici măcar nu va fi verificată.
2) dacă proxy-ul folosește un utilizator care nu este de la acest ip, atunci regula de pe linia 3 nu va fi executată și vom merge la regula de pe linia 4. Deoarece orice ip se potrivește sub acl all, această regulă va fi executată și vom blocați accesul. reguli suplimentare nu vor fi verificate. Astfel, am interzis tuturor, cu excepția lui Vasya, să folosească proxy.

Luați în considerare o greșeală comună bazată pe exemplul anterior:

acl all src 0/0 acl vasya src 192.168.1.12/32 http_access deny all http_access permite vasya

În acest caz, nici măcar Vasya nu va putea folosi proxy-ul. Deoarece am blocat accesul tuturor cu regula de pe linia 3, aceasta este executată, iar regula de pe linia 4 nici măcar nu va fi verificată. Acordați o atenție deosebită ordinii regulilor de același tip.

Creați configurația calmarului

Să începem să scriem configurația. Voi arunca o privire la configurația mea ca exemplu.

Mai întâi, să creăm folderul acls în folderul /etc/squid. Am creat 3 fișiere în el: bannere, nobanners, 1banners
Fișierul bannere stochează expresii regulate pentru reclame și bannere care vor fi tăiate. Excepțiile sunt stocate în nobanner-uri, adică acele pagini și imagini care vor fi încărcate chiar dacă bannerele au o regulă sub care se încadrează. Fișierul 1banners conține expresii regulate care descriu acele bannere care vor fi tăiate mai întâi. Voi oferi conținutul fișierelor mele de filtrare a anunțurilor la sfârșitul articolului.

Cu drepturi de root, creați fișierul /etc/squid/squid.conf și începeți să adăugați linii la el:

Specificați portul pe care va funcționa proxy-ul: (ATENȚIE!! Nu setați niciodată porturi standard precum 8080 80 sau 3128 dacă nu doriți ca proxy-ul să fie ușor detectat)

http_port 1234

Specificați numele nodului pe care este instalat squid. Îți poți afla numele făcând uname -n

Nume_gazdă_vizibil dimon4eg

Dezactivați icp

Icp_port 0

Prin acl cu expresii regulate, specificam pagini care nu vor fi memorate in cache

Acl donocache urlpath_regex cgi-bin user submit no_cache deny donocache

Creați un folder /var/spool/squid și faceți chmod 777 /var/spool/squid
Să descriem volumul cache-ului „rapid” și al cache-ului de pe hard disk. Volumul cache-ului rapid este recomandat să fie setat la cel mult 32 de metri pentru a economisi RAM.

Cache_mem 32 MB cache_dir ufs /var/spool/squid 1000 16 256

În mod similar, creați folderele /var/log/squid și specificați unde să stocați jurnalele

cache_access_log /var/log/squid/access.log cache_log /var/log/squid/cache.log cache_store_log /var/log/squid/store.log

Procesați tabelul mime și pid

Tabel_mime /etc/squid/mime.conf nume_fișier_pid /var/run/squid.pid

Setări FTP prin proxy

utilizator_ftp [email protected] ftp_list_width 32 ftp_passive pe ftp_sanitycheck activat

Service acl

acl all src 0/0 acl portul SMTP 25

Lista IP-urilor de la care este permis proxy. Asigurați-vă că specificați 127.0.0.1 și adresa serverului însuși în LAN. În continuare, indicăm toți utilizatorii care au acces. (AVERTISMENT, asigurați-vă că dezactivați accesul oricui.)

Acl doallow src 192.128.0.2/32 127.0.0.1/32

Setați porturile care sunt permise

acl Safe_ports port 80 acl Safe_ports port 21 acl Safe_ports port 443 563 5190 5552 acl Safe_ports port 777

Locația fișierelor cu reguli pentru tăierea reclamelor. Comutatorul -i înseamnă că regulile nu țin cont de majuscule și minuscule

acl bannere url_regex -i "/etc/squid/acls/banners" acl 1banners url_regex -i "/etc/squid/acls/1banners" acl nobanners url_regex -i "/etc/squid/acls/nobanners"

Acum să scriem regulile

Http_access deny 1bannere http_access deny bannere !nobanners http_access deny !Safe_ports http_access deny SMTP http_access permite doallow http_access deny all

Interziceți accesul icp

icp_access deny all

Aplicații

Textul complet al meu squid.conf

Regulile mele pentru tăierea reclamelor

/etc/squid/acls/banners

Materialele despre construirea unui router bazat pe Squid sunt printre cele mai populare de pe site-ul nostru. Această soluție permite, cu costuri minime (în primul rând pentru partea de software), să se organizeze și să eficientizeze accesul la Internet la întreprindere. Dar opțiunile pe care le luăm în considerare au fost destinate în primul rând lucrului ca parte a unui grup de lucru. Lipsa integrării cu Active Directory a redus drastic capacitatea de utilizare a unui astfel de router în rețelele de domenii, așa că am decis să corectăm această omisiune.

În procesul de pregătire a acestui material, nu am planificat să ne oprim separat asupra pregătirii serverului, intenționând să folosim materialul deja existent pentru aceasta: . Cu toate acestea, când numărul de clarificări și diferențe a început să depășească limite rezonabile, am decis să dedicăm un articol separat acestei probleme. În același timp, presupunem că cititorul este familiarizat cu materialul de mai sus și, prin urmare, nu va explica în detaliu multe dintre setările pe care le folosim și nu se va opri asupra detaliilor minore.

Caracteristici de integrare cu Active Directory

Care este rostul integrării proxy Squid în Active Directory? Să spunem imediat că, dacă scopul tău principal este să distribui pur și simplu internetul tuturor și fără restricții, ei bine, cu excepția închiderii rețelelor sociale, atunci nu trebuie să citești mai departe, configurația pe care am descris-o deja îți va satisface pe deplin nevoile. . Principalul avantaj al integrării unui router în Active Directory este utilizarea unui singur punct de autentificare și control al accesului la Internet bazat pe conturi și grupuri de securitate care există deja în domeniu.

De aici urmează câteva caracteristici. Deci modul transparent nu acceptă autentificarea și va trebui să o refuzați specificând setările proxy direct în setările browserului. Acest proces este ușor de automatizat folosind un server DHCP și protocolul WPAD.

ca servere DNS, inclusiv routerul, trebuie specificat doar DNS de domeniu, implicit, fiecare controler de domeniu este un server DNS. Din acest motiv, routerul nu ar trebui să aibă rolul de server DNS. De asemenea, pentru a permite integrarea cu AD, rolul de server DHCP ar trebui să fie transferat și pe Windows Server, de obicei către unul sau mai multe controlere de domeniu.

Acum ajungem la punctul pentru care toate acestea au început. Autentificarea prin conturi de domeniu vă permite să utilizați un singur punct de intrare ( SSO, Single Sign-On), când utilizatorul introduce numele de utilizator și parola o dată - când se conectează la sistem. Acest lucru se realizează prin utilizarea protocolului Kerberos, care este metoda implicită de autentificare AD. Spre deosebire de autorii altor ghiduri, nu vedem niciun rost în a configura sau autentificare de bază, în primul rând din motive de securitate. Mai mult, Kerberos este suportat de toate sistemele de operare moderne.

Următorul pas este autorizarea bazată pe grupurile de securitate existente, acest lucru este valabil mai ales când se migrează de la În frunteTMG sau ISA Server. Acest lucru permite, odată ce ați configurat serverul Linux, controlul suplimentar al accesului să fie efectuat în mod obișnuit - prin grupurile Active Directory, ceea ce permite scăderea pragului de intrare pentru administratori.

Întrucât Active Directory are o structură mai complexă și un număr mai mare de „actori”, pentru a nu vă încurca în adresele și numele gazdelor pe care le folosim, am pregătit o mică diagramă:

În exemplele noastre, vom folosi un domeniu Active Directory cu numele FQDN interfata31.lab, pentru care sunt responsabili doi controlori de domeniu SRV-DC01și SRV-DC02 cu adresele 192.168.31.101 si respectiv 102. Ambele controlere sunt bazate pe Windows Server 2012 R2.

Routerul se bazează pe Ubuntu Server 14.04 (Debian 7/8) și are numele SRV-GW01 cu adresa 192.168.31.100. În rețea există și un grup de servere cu adrese statice 192.168.31.103-105 și PC-uri client ale căror adrese sunt emise de un server DHCP din intervalul 192.168.31.111-199.

Configurarea Rețelei

Rețeaua este configurată în mod tradițional, prin editarea fișierului de configurare /etc/network/interfaces. Acceptăm că rețeaua externă corespunde interfeței eth0, și intern et1. Ca rezultat al setărilor, ar trebui să obținem ceva de genul acesta:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
adresa 172.18.0.106
mască de rețea 255.255.240.0
gateway 172.18.0.1
dns-search interface31.lab
servere de nume dns 192.168.33.101 192.168.31.102

auto eth1
iface eth1 inet static
adresa 192.168.31.100
mască de rețea 255.255.255.0

post-up /etc/nat

Vă rugăm să rețineți că, deși adresa externă și gateway-ul sunt utilizate în setările interfeței externe, adresele serverelor DNS sunt interne. Există și o opțiune dns-search, care definește domeniul pentru rezoluția non-FQDN. Aceasta înseamnă că domeniul specificat va fi adăugat automat la fiecare nume scurt, de exemplu, srv-dc01 va fi adăugat la srv-dc01.interface31.lab.

Dacă sunteți confuz prin specificarea DNS-ului intern în setările unei plăci de rețea externe, atunci puteți muta aceste linii în secțiunea eth1, acest lucru nu va afecta funcționarea serverului.

Serverele DNS ale furnizorului sau DNS-urile publice trebuie specificate în secțiune expeditori server DNS intern pe oricare dintre controlerele de domeniu.

Dacă obțineți setări de rețea de la furnizor prin DHCP, atunci pentru a utiliza servere de nume interne, în loc de DNS-ul furnizorului, secțiunea eth0 ar trebui să arate astfel:

Auto eth0
iface eth0 inet dhcp
dns-search interface31.lab
servere de nume dns 192.168.33.101 192.168.31.102

Astfel, setările specificate în mod explicit le vor înlocui pe cele primite automat de la furnizor.

Salvați conținutul fișierului, reporniți. Verificăm disponibilitatea Internetului pe server și rezoluția numelui. De exemplu, rulați comanda:

nslookup srv-dc02

Primul server de nume de domeniu specificat ar trebui să vă răspundă, în cazul nostru 192.168.33.101 și să emită numele de gazdă FQDN complet și adresa sa IP.

Apoi verificați rezoluția numelor externe:

Nslookup ya.ru

De asemenea, ar trebui să primiți un răspuns de la serverul intern. Aceasta completează configurarea rețelei.

Configurarea NAT și Firewall

Configurarea de bază a paravanului de protecție este în esență aceeași cu opțiunea de router pentru grup de lucru, cu o singură excepție. Deoarece proxy-ul nostru este opac, este posibil să ieșim direct prin NAT dacă, dintr-un motiv oarecare, browserul nu este configurat să funcționeze cu un server proxy. Prin urmare, vom restricționa accesul prin HTTP (portul 80) la toți clienții din rețeaua locală, cu excepția serverelor și a gazdelor individuale care ar putea avea nevoie de acces direct.

Credem că un server proxy este necesar în primul rând pentru a controla utilizatorii, așa că nu vedem niciun rost să încapsulăm serverele și gazdele de servicii care nu oferă acces la Internet utilizatorilor de pe el.

Creați și deschideți un fișier /etc/nat

Să adăugăm următorul conținut:

#Activați redirecționarea pachetelor
echo 1 > /proc/sys/net/ipv4/ip_forward

#Permite traficul pe lo
iptables -A INPUT -i lo -j ACCEPT

#Permite servere HTTP
iptables -A FORWARD -i eth1 -s 192.168.31.101 -p tcp --dport 80 -j ACCEPT
...
iptables -A FORWARD -i eth1 -s 192.168.31.105 -p tcp --dport 80 -j ACCEPT

#Dezactivați HTTP
iptables -A FORWARD -i eth1 -p tcp --dport 80 -j REJECT

#Permite accesul din rețeaua internă spre exterior
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

#Activați NAT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.31.0/24 -j MASQUERADE

#Permite răspunsuri din rețeaua externă
iptables -A FORWARD -i eth0 -m stat --state ESTABLISHED,RELATED -j ACCEPT

#Interziceți accesul extern la rețeaua internă
iptables -A FORWARD -i eth0 -o eth1 -j RESPING

Secțiune #Permite servere HTTP implică un set de reguli identice pentru fiecare gazdă pe care le permitem accesul la Internet ocolind proxy-ul. În cazul nostru, acestea sunt adrese de la 192.168.31.101 la 192.168.31.105, pentru a nu aglomera exemplul, le-am scris pe primul și pe ultimul, separându-le cu puncte de suspensie (care nu ar trebui să fie într-o config reală).

Salvați fișierul și acordați-i permisiuni de execuție:

Chmod +x /etc/nat

Să repornim:

După aceea, puteți verifica internetul pe clienți, pe cei care sunt incluși în lista de excepții - va fi, pe restul nu. Alte protocoale: mail (SMTP, POP3, IMAP), FTP, HTTPS etc. ar trebui să lucreze la toți clienții.

Setare de sincronizare a timpului

Pentru a lucra cu succes cu domeniul Active Directory și a trece autentificarea Kerberos, este important ca ceasul routerului să fie sincronizat cu ceasul controlerului de domeniu.

Instalați clientul NTP:

apt-get install ntp

Apoi deschideți fișierul de configurare /etc/ntp.confși comentați toate rândurile începând cu Server. Apoi adăugăm două dintre intrările noastre:

Server srv-dc01.interface31.lab
server srv-dc02.interface31.lab

După cum probabil ați ghicit, am comentat intrările de la serverul de timp terță parte și am adăugat controlere de domeniu ca atare.

Apoi adăugați două linii la sfârșitul fișierului, limitând clientul NTP la interfața internă:

interfață ignoră wildcard
interfață asculta eth1

Salvați fișierul și reporniți serviciul:

Repornirea serviciului ntp

Pentru a vă asigura că NTP funcționează numai pe interfața interioară, rulați:

Ss-l | grep 123

Ieșirea comenzii ar trebui să conțină numai adrese interne și adrese ale buclei locale (localhost):

Puteți verifica sincronizarea cu comanda:

În rezultat, acordați atenție coloanelor: când-timpul de la ultimul răspuns al serverului, bazin- timpul de sondare a serverului, decalaj- diferenta de timp in secunde.

Dacă routerul dvs. se află într-un mediu virtual, atunci la pornire, până când sistemul știe cu cine să sincronizeze ora, timpul din interiorul mașinii virtuale este sincronizat cu ora hipervizorului. Prin urmare, fie dezactivați această caracteristică în setările mașinii virtuale, fie sincronizați ceasul hypervisorului cu ceasul domeniului.

Configurarea serverului proxy de cache Squid3

Atenţie! Dacă reconfigurați serverul pentru un grup de lucru, atunci asigurați-vă că ștergeți pachet dnsmasq sau alte servere DNS și DHCP!

Instalați serverul proxy squid3 cu comanda:

apt-get install squid3

Să deschidem fișierul de configurare /etc/squid3/squid.confși setați configurația minimă prin adăugarea sau decomentarea liniilor indicate în secțiunile corespunzătoare.

Specificați elementul acl pentru rețeaua locală:

Acl localnet src 192.168.31.0/24

Set minim de liste de acces:

http_access permite localnet
http_access permite localhost
http_access deny all

Interfețe, porturi și moduri proxy:

http_port 192.168.31.100:3128
http_port 127.0.0.1:3128

Setări cache:

Cache_mem 1024 MB
dimensiune_maximum_obiect_in_memorie 512 KB

cache_dir ufs / var /spool/squid3 2048 16 256

dimensiunea_obiectului_maximum 4 MB

Setări jurnal:

Access_log daemon:/var/log/squid3/access.log squid
logfile_rotate 31

Pentru calmar 3.1 și mai jos, prima linie ar trebui să arate astfel:

Access_log /var/log/squid3/access.log squid

Salvați și testați configurația:

Squid3 -k verifica

Dacă nu există erori, atunci reporniți squid:

Reporniți serviciul squid3

Reconstituirea cache-ului:

Serviciu oprire squid3
calmar3 -z
service squid3 start

Pe serverul DNS al domeniului, adăugați o înregistrare A pentru routerul nostru:

Acum, în setările browserului, specificați numele FQDN complet al serverului și portul 3128:

Deoarece nu au fost stabilite restricții încă, trebuie să accesați Internetul.

Squid este o aplicație de server proxy de stocare în cache cu caracteristici complete care oferă servicii de stocare în cache și proxy pentru HTTP, FTP și alte protocoale de rețea populare. Squid poate stoca în cache și proxy solicitările SSL și poate stoca în cache rezultatele căutării DNS, precum și poate efectua memorarea în cache transparentă. Squid acceptă, de asemenea, o gamă largă de protocoale de cache, cum ar fi ICP (Internet Caching Protocol), HTCP (Hypertext Caching Protocol), CARP (Routing Caching Protocol) și WCCP (Content Redirection Caching Protocol).

Squid Proxy Server este o soluție excelentă pentru cerințele extinse de stocare în cache și server proxy, care se extind de la biroul regional la rețelele corporative atunci când oferă un mecanism extensibil de control al accesului partajat și monitorizarea parametrilor critici prin protocolul SNMP. Atunci când alegeți un sistem de computer pentru a utiliza ca proxy Squid sau server de cache, asigurați-vă că sistemul dumneavoastră este echipat cu multă memorie RAM, deoarece Squid menține un cache în memorie pentru a crește performanța.

Instalare

Într-un terminal, introduceți următoarea comandă pentru a instala serverul Squid:

sudo apt-get install squid

Setare

Squid este configurat prin editarea directivelor conținute în fișierul de configurare /etc/squid/squid.conf. Următoarele exemple ilustrează câteva dintre directivele care pot fi modificate pentru a afecta comportamentul serverului Squid. Pentru o configurație mai aprofundată a Squid, consultați secțiunea.

Înainte de a edita un fișier de configurare, ar trebui să faceți o copie a fișierului original și să îl protejați împotriva suprascrierii, astfel încât să aveți întotdeauna setările originale ca referință și să le refolosiți dacă este necesar.

Copiați fișierul /etc/squid/squid.conf și protejați-l la scriere cu următoarele comenzi în terminal:

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original sudo chmod a-w /etc/squid/squid.conf.original

1. Pentru a configura serverul Squid să asculte pe portul 8888 în loc de 3128 implicit, modificați directiva http_port așa cum se arată aici:

Http_port 8888

2. Schimbați directiva vizibil_hostname pentru a da serverului Squid un anumit nume de gazdă. Acest nume nu trebuie să fie numele de gazdă al computerului. În exemplu, este definit ca weezie:

Visible_hostname weezie

3. Folosind controlul accesului Squid, puteți configura ca utilizarea serviciului proxy Internet să fie disponibilă numai pentru utilizatorii de la anumite adrese IP. De exemplu, vom ilustra accesul utilizatorilor numai din subrețeaua 192.168.42.0/24:

ACL

Acl fortytwo_network src 192.168.42.0/24

http_access fișierul dvs. /etc/squid/squid.conf:

http_access permit fortytwo_network

4. Folosind capabilitățile excelente de control al accesului Squid, puteți configura serviciul proxy de Internet pentru a fi utilizat numai în timpul orelor normale de lucru. De exemplu, vom arăta cum să configurați accesul pentru angajații care lucrează de la 9:00 la 17:00 de luni până vineri din subrețeaua 10.1.42.0/24:

Adăugați următoarele la sfârșitul secțiunii ACL fișierul dvs. /etc/squid/squid.conf:

acl biz_network src 10.1.42.0/24 acl biz_hours ora L M M J V 9:00-17:00

Apoi adăugați următoarele la începutul secțiunii http_access fișierul dvs. /etc/squid/squid.conf:

Http_access permite biz_network biz_hours

După ce faceți modificări în fișierul /etc/squid/squid.conf, salvați-l și reporniți aplicația server squid pentru ca modificările să aibă efect cu următoarea comandă în terminal: sudo /etc/init.d/squid restart

Timp plăcut, dragi cititori și oaspeți! Cu acest articol, voi începe descrierea lucrării Proxy de stocare în cache SQUID. Acest articol va fi în mare parte teoretic introductiv.

Ce este un server proxy și ce este squid

Voi începe cu elementele de bază. calmar este cache server proxy pentru HTTP, FTP și alte protocoale. Server proxy pentru HTTP este un program care face cereri HTTP în numele unui program client (fie acesta un browser sau alt software). proxy poate fi stocarea în cache sau nu stocarea în cache. stocarea în cache,în consecință, salvează toate solicitările într-un fel de stocare pentru o întoarcere mai rapidă către clienți și nu stocarea în cache- traduce pur și simplu HTTP, ftp sau alte solicitări. Anterior, caching-ul de trafic făcea posibilă realizarea unor economii de trafic destul de semnificative, dar în prezent, odată cu creșterea vitezei de internet, acest lucru și-a pierdut puțin relevanța. Serverul proxyA poate fi încorporat ierarhie pentru a procesa cereri. În același timp, serverele proxy A interacționează între ele prin Protocolul ICP.

Calmar proiectat și poate rula pe majoritatea sistemelor de operare (atât Unix, cât și Windows). Licențiat sub GNU GPL. Capabil să proceseze și să memoreze în cache solicitările HTTP, FTP, gopher, SSL și WAIS (eliminate în 2.6), precum și DNS. Cele mai frecvente solicitări sunt stocate în RAM. Momentan există 2 versiuni stabile de calmar: 2.7 și 3.1 . Diferențele pot fi găsite în linkurile de la sfârșitul articolului. Toate dependențele la instalarea din pachete sunt aceleași. Fișierul de configurare al versiunii 2 este compatibil cu versiunea 3, dar versiunea 3 adaugă noi opțiuni. În articol voi lua în considerare versiunea squid3. De asemenea, merită remarcat faptul că, dacă instalați squid3 , atunci își va păstra fișierele de configurare /etc/squid3, precum și jurnalele implicite din squid3 sunt în director /var/log/squid3/, dar nu /var/log/squid/, la fel de multor analizoare de jurnal „le place să numere”.

De multe ori cuvântul " stocarea în cache". Și ce este, de fapt, asta - stocarea în cache? aceasta o modalitate de a stoca obiecte solicitate de pe Internet pe un server care este mai aproape de computerul solicitant decât de cel original. Un obiect Internet este un fișier, document sau răspuns la un apel către un serviciu furnizat pe Internet (cum ar fi FTP, HTTP sau Gopher). Clientul solicită un obiect Internet din memoria cache a proxy-ului; dacă obiectul nu este încă stocat în cache, atunci serverul proxy primește obiectul (fie de la gazda specificată la adresa URL solicitată, fie de la cache-ul părinte sau vecin) și îl livrează clientului.

Moduri Squid Proxy

Proxy-ul Squid poate funcționa în următoarele trei moduri principale:

modul transparent

În acest mod HTTP, conexiunea realizată de clienți este redirecționată către un server proxy fără cunoștința lor sau configurarea explicită. În acest mod, nu este necesară configurarea clientului. Dezavantajele acestei metode: este necesară configurarea NAT și redirecționarea traficului, autentificarea clientului nu funcționează, solicitările FTP și HTTPS nu sunt redirecționate.

Modul de autentificare

Pentru a funcționa în acest mod, clienții trebuie configurați să funcționeze cu un server proxy (adresa serverului proxy trebuie specificată în setările de conexiune). Clienții pot fi autentificați și autorizați prin Kerberos, Ldap, NTLM, IP și Radius. Este posibil să se construiască interacțiune cu serverele Microsoft Active Directory prin autentificarea clienților - membri ai domeniului utilizând protocolul Kerberos, iar apoi autorizarea membrilor grupului de domenii folosind LDAP în mod transparent (utilizatorul își introduce parola doar la înregistrarea în domeniu). Pentru grupurile autorizate, este posibil să se aplice diferite setări pentru controlul accesului și QoS (pool-uri de întârziere).

Proxy invers

Serverul proxy memorează în cache datele de ieșire. Proxy-ul invers Squid primește date de la serverul HTTP în numele clientului și le trimite înapoi clientului (de exemplu, pe Internet). Acest mod vă permite să:

• Utilizarea memoriei cache, care reduce sarcina pe serverul HTTP;
• Echilibrarea sarcinii între serverele HTTP;
• Mascarea serverelor HTTP și caracteristicile acestora;
• Prevenirea atacurilor web pe servere.

Diagramele modului de funcționare SQUID

În diagramele de mai sus, săgețile verzi indică fluxurile de trafic proxy. Mișcarea acestor fluxuri în Linux este cel mai adesea controlată de forțele și setările browserului. În plus, foarte des, funcțiile routerului și proxy-ului sunt îndeplinite de o singură mașină.

Instalarea SQUID

Înainte de a instala și configura squid, trebuie să vă asigurați de asemenea că mașina pe care va rula squid are acces la rețeaua externă, iar clienții care vor folosi acest proxy au acces la această mașină. Instalarea serverului proxy squid, ca și alte software-uri pe Linux, este posibilă în diferite moduri, descrise în articol. Voi atinge modul de instalare din depozitul din Debian. Deci, pentru a instala squid, trebuie să instalați pachetul squid3, pentru a face acest lucru, rulați următoarea comandă:

Gw ~ # aptitude install squid3 Următoarele pachete NOI vor fi instalate: libltdl7(a) squid-langpack(a) squid3 squid3-common(a) 0 pachete actualizate, 4 noi instalate, 0 pachete marcate pentru eliminare și 0 pachete neactualizate . Trebuie să obțineți 2 157 kB arhive. După despachetare, vor fi folosiți 10,3 MB. Doriți să continuați? y Get:1 http://ftp.ru.debian.org/debian/squeeze/main libltdl7 i386 2.2.6b-2 Get:2 http://ftp.ru.debian.org/debian/squeeze/main squid- langpack all 20100628-1 Get:3 http://ftp.ru.debian.org/debian/squeeze/main squid3-common all 3.1.6-1.2+squeeze2 Get:4 http://ftp.ru.debian.org /debian/ squeeze/main squid3 i386 3.1.6-1.2+squeeze2 Obține 2.157 kB în 9s (238 kB/s) Se selectează un pachet libltdl7 neselectat anterior. (Se citește baza de date... instalate în prezent 41133 fișiere și directoare.) Se despachetează pachetul libltdl7 (din fișierul.../libltdl7_2.2.6b-2_i386.deb)... Se selectează pachetul squid-langpack neselectat anterior. Pachetul squid-langpack este dezambalat (din fișierul.../squid-langpack_20100628-1_all.deb)... Selectarea unui pachet squid3-common neselectat anterior. Pachetul squid3-common este dezambalat (din fișierul.../squid3-common_3.1.6-1.2+squeeze2_all.deb)... Selectarea unui pachet squid3 neselectat anterior. Se despachetează pachetul squid3 (din fișierul.../squid3_3.1.6-1.2+squeeze2_i386.deb)... Se procesează declanșatoarele man-db... Se configurează pachetul libltdl7 (2.2.6b-2)... Se configurează squid-langpack pachet (20100628-1) ... Configurarea pachetului squid3-common (3.1.6-1.2+squeeze2) ... Configurarea pachetului squid3 (3.1.6-1.2+squeeze2) ... Crearea proxy HTTP Squid 3.x Structura directorului spool 2012/02/15 21:29:41| Crearea directoarelor de schimb Repornirea Squid HTTP Proxy 3.x: squid3Crearea Squid HTTP Proxy 3.x structura cache... (avertisment). 2012/02/15 21:29:43| Crearea directoarelor de schimb.

După cum puteți vedea, la instalarea pachetului, a existat o încercare de a crea directorul cache, ci pentru că nu este configurat, avertizarea a căzut. Același fel, calmar adăugat la pornire, rulare și acceptare a conexiunilor pe toate interfețele. Dar de atunci nu este configurat, accesul la paginile de internet prin server este limitat. Configurare calmar situat în /etc/squid3/squid.confși constă din mai mult de 5,5 mii de linii și sintaxa sa este practic aceeași cu configurația oricărui alt serviciu. Să te grăbești să schimbi unele setări într-o tăietură nu merită. Atunci nu greblați. Să ne uităm la configurația care ne este oferită implicit fără comentarii și linii goale:

Gw ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$ acl manager proto cache_object acl localhost src 127.0.0.1/32::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32::1 acl SSL_ports port 443 acl Safe_ports port 21_ports acl Safe port 80_ports # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # porturi neînregistrate acl Safe_ports port 280 # http-mgmt acl port Safe_ports 48_acl # port sigur 48_acl # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access permit manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access permit localhost http_access deny all http_port 3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern 0 20% 4320

După cum puteți vedea, în configurația implicită, serverul proxy funcționează și permite accesul doar de la adresele 127.0.0.0/8. Ar trebui să revizuiți cu atenție întreaga listă și să comentați liniile cu porturi de servicii care nu sunt necesare sau utilizate. O înțelegere mai completă a acestei configurații va fi după citirea următoarelor secțiuni. Acea. dacă lansăm browserul consolei lunx indicând proxy-ul nostru, putem vedea pagina dată:

Gw ~ # # rulați browserul cu pagina ya.ru specificată: gw ~ # http_proxy=http://127.0.0.1:3128 lynx ya.ru Căutarea „ya.ru” mai întâi gw ~ # # în jurnal vedem o referință la pagina dată : gw ~ # cat /var/log/squid3/access.log 1329527823.407 110 127.0.0.1 TCP_MISS/200 9125 GET http://ya.ru/ - DIRECT/93.158.134.203 text/html

Unele opțiuni din fișierul de configurare squid pot fi folosite de mai multe ori (ex. acl). Unii parametri, în special cei cu o singură valoare, pot fi utilizați o singură dată. În acest caz, atunci când utilizați acest parametru de 2 sau mai multe ori, se va folosi ultima valoare. De exemplu:

Logfile_rotate 10 # Valori multiple - finala va fi 5 logfile_rotate 5

managementul calmarilor

Parametrii cu care a fost construit squid-ul distribuției dvs. pot fi vizualizați cu comanda squid3 -v. De exemplu, pe Debian squeezy, squid este construit cu opțiunile de mai jos:

Prefix=/usr - prefix pentru alte chei: --mandir=$(prefix)/share/man - director de stocare a paginii de manual --libexecdir=$(prefix)/lib/squid3 - director cu module executabile (inclusiv ajutoare) -- sysconfdir=/etc/squid3 - director pentru stocarea configurației --with-logdir=/var/log/squid3 - director pentru stocarea jurnalelor și multe altele. alte...

Instalarea calamarului

Descrierea setărilor squid3 Voi începe cu setări de bază, pe care este de dorit să îl faceți atunci când configurați orice configurație de server proxy. Configurația squid se află în /etc/squid3/squid.conf, acesta este fișierul principal de configurare, care conține toate setările. (În distribuțiile Debian și RedHat, parametrii din fișierele de configurare de pornire sunt, de asemenea, vizualizați la pornire /etc/default/squid3și /etc/sysconfig/squid3, respectiv). De asemenea, am menționat că sunt peste 5 mii de linii și că nu merită să te grăbești imediat să configurezi ceva fără să înțelegi. sintaxa de configurare squid3 clasic: liniile cu # sunt comentarii, parametrii sunt linii " valoarea parametrului", puteți folosi . Fișierul de configurare este împărțit în secțiuni pentru comoditate, dar este important să rețineți că parametrii sunt analizați „de sus în jos” în ordinea priorității. De asemenea, folosind include parametrul puteți include fișiere de configurare externe.

În mod implicit, rezoluția numelui gazdei în care rulează Squid este realizată gethostname(),în funcție de setările DNS, uneori nu poate determina fără ambiguitate numele care va apărea în jurnalele și ieșirile de eroare „ Generat... de server.com (squid/3.0.STABLE2)". Pentru a înregistra corect numele gazdei, trebuie să introduceți acest nume (FQDN??) în parametru:

Visible_hostname myproxy

În mod implicit, squid acceptă conexiuni pe toate interfețele. Dacă serverul nostru privește lumea exterioară cu una dintre interfețele de rețea, atunci este de dorit să se limiteze conexiunile numai pe interfața LAN (de exemplu, 10.0.0.10/24). Responsabil pentru asta parametrul http_port:

Http_port 10.0.0.10:3128

Cum funcționează acești parametri poate fi văzut în următoarea listă:

Gw ~ # # testează demonul înainte de a-l configura: gw ~ # netstat -antp | grep squ tcp 0 0 0.0.0.0:3128 0.0.0.0:* LISTEN 25816/(squid) gw ~ # # modificări efectuate: gw ~ # grep ^http_port /etc/squid3/squid.conf http_port 10.0.0.80 gw:312.10 # # reîncărcați configurația gw modificată ~ # /etc/init.d/squid3 reîncărcarea fișierelor de configurare Squid HTTP Proxy 3.x. Terminat. gw ~ # # verificați funcționarea cu configurația schimbată: gw ~ # netstat -antp | grep squ tcp 0 0 10.0.0.10:3128 0.0.0.0:* ASCULTĂ 25816/(calamar)

După cum puteți vedea, acum demonul funcționează numai pe interfața rețelei specificate. De asemenea, merită remarcat faptul că noile versiuni de calmar (<3.1) поддерживают задание нескольких параметров http_port. При этом, у разных параметров могут быть указанны дополнительные ключи такие как intercept, tproxy, accel и др., например:

Gw ~ # grep ^http_port /etc/squid3/squid.conf http_port 10.0.0.10:3128 http_port 10.0.0.10:3129 tproxy

Acești parametri setează modurile de funcționare a serverului proxy. De exemplu, tproxy (sintaxa veche este transparentă) specifică . Aceste moduri merită articole separate și pot fi luate în considerare în viitor.

Acum trebuie să configurați un computer client și să utilizați Internetul. Dar în mod implicit, accesul este permis numai de la localhost și atunci când încearcă să acceseze web, utilizatorul va primi o eroare „Acces refuzat”. Jurnalul /var/log/squid3/access.log va conține ceva de genul acesta:

1329649479.831 0 10.0.1.55 TCP_DENIED/403 3923 GET http://ya.ru/ - NONE/- text/html

Pentru ca clienții LAN să funcționeze, trebuie configura permisiunile cu liste de control al accesului.

Configurarea accesului calmarului

De fapt setare de acces se află în descrierea obiectului acces prin parametrul acl, și apoi rezoluţie sau interzicerea muncii obiect acl descris cu Parametrul „http_access”.. Cel mai simplu format de date de configurare este următorul:

Acl nume_listă tip_selecție caracteristici_tip_selectare

Unde acl- descrierea parametrilor lista de control acces, al cărui nume este dat de valoarea nume_listă. Numele este sensibil la majuscule. tip_selecție specifică tipul la care este dat în continuare caracteristica tip_selecție. Această caracteristică poate lua valori utilizate frecvent ca src(de la sursă) - sursa cererii, dst- adresa de destinatie, arp- Adresa mac, srcdomainși dstdomain- numele de domeniu al sursei și respectiv al destinației, port- port, proto- protocol, timp- timp și multe altele. În consecință, valoarea caracteristici_tip_selecție se va forma in functie de tip_selecție.

Puteți specifica mai multe șiruri de caractere acl cu aceleași nume și selecție_types, caz în care datele acl vor fi combinate într-o singură listă cu o operație OR logică. De exemplu:

site acl dstdomain site.com acl site dstdomain site.org # la fel ca: acl site dstdomain site.com site.org

Cu cuvinte, sună așa: lista de acces numită site deține toate cererile trimise către site-ul site.com SAU site.org. De asemenea, escape_names sunt sensibile la majuscule și minuscule, ceea ce înseamnă că site-ul acl și site-ul acl sunt 2 liste de acces diferite.

Odată ce listele de acces au fost formate, folosind parametrul http_access permite sau interzice accesul la ACL specificat. Formatul general de apel este:

Http_access allow|deny [!]list_name

Unde, http_access- parametru care specifică regula de permisiune ulterioară ( permite) sau interdicții ( nega) acces specificat mai jos nume_listă. În acest caz, semnul exclamării opțional inversează valoarea numelui listei. Adică, cu un semn de exclamare, valoarea nume_listă va suna ca toți, cu excepția celor care aparțin acestei liste. În plus, puteți specifica mai multe liste separate printr-un spațiu, apoi accesul va fi permis dacă aparține tuturor listelor specificate. În acest caz, toate regulile de autorizare trebuie specificate înainte de toate regulile de refuz:

http_access deny all

Poate apărea o întrebare rezonabilă: de ce să stabilim această regulă dacă, de exemplu, permitem doar acls selectați să acceseze calmarul? La urma urmei, restul, care nu se încadrează în acest acl, așa că „treceți”... E simplu. În mod implicit, squid folosește regula opusă de permis/refuzare. De exemplu:

# avem o singură regulă de permis pentru un utilizator acl: http_access allow user # dacă clientul nu se află în acest acl când accesează squid, atunci i se va aplica acțiunea de deny. # Și dacă avem două reguli http_access allow user http_access deny user2 # și clientul nu este inclus nici în acl user, nici în acl user2, atunci i se va aplica allow. # Adică, acțiunea opusă ultimului utilizator http_access deny2

Aceasta, după cum se spune - fundațiile fundațiilor. Să ne uităm la un exemplu simplu. Să presupunem că avem 2 rețele 10.0.1.0/24 și 10.0.0.0/24, precum și o gazdă 10.0.4.1, cărora trebuie să li se permită accesul la Internet. Pentru a permite accesul, trebuie să creați o descriere a noii liste de acces în secțiunea „CONTROLUL ACCES” a fișierului squid.conf:

acl lan src 10.0.1.0/24 10.0.0.0/24 acl lan src 10.0.4.1

Pentru mai multă comoditate, puteți seta aceste reguli într-un fișier separat, specificând calea către el caracteristicile tipului_selecției. Aici:

Gw ~ # # creați un director separat pentru stocarea listelor de acces gw ~ # mkdir /etc/squid3/acls/ gw ~ # # puneți subrețelele și gazdele noastre într-un fișier separat gw ~ # vim /etc/squid3/acls/lan.acl gw ~ # cat /etc/squid3/acls/lan.acl 10.0.1.0/24 10.0.0.0/24 10.0.4.1 gw ~ # # descrie fișierul creat în configurație (calea trebuie inclusă între ghilimele) gw ~ # grep lan.acl /etc /squid3/squid.conf acl lan src "/etc/squid3/acls/lan.acl"

Permite accesul la Internet listei de acces LAN creată și spune-i calamarului să recitească fișierul de configurare:

Gw ~ # grep lan /etc/squid3/squid.conf | grep acce http_access allow lan gw ~ # service squid3 reload Reîncărcarea fișierelor de configurare Squid HTTP Proxy 3.x. Terminat.

Pentru a rezuma această secțiune, pe scurt, acl identifică o solicitare Web, iar http_access permite sau respinge cererea identificată. Acum clienții noștri locali sunt bucuroși să folosească Internetul, având configurat anterior browserul!

Configurarea setărilor de cache pentru calmar

Un punct important în configurarea calmarului este setarea opțiunilor de cache în squid. Locația memoriei cache este setată parametrul cache_dirîn calmar.conf. Formatul parametrului este următorul:

Mărimea căii tip cache_dir L1 L2

Unde, tip de- acesta este algoritmul de generare a memoriei cache, poate: ufs (sistem de fișiere Unix), aufs (async ufs), diskd(procese externe pentru a evita blocarea squid pe disc I/O). Se recomandă utilizarea ufs deși unele laude aufs. cale- specifică locația cache-ului în sistemul de fișiere (trebuie să existe și să aibă acces de scriere pentru utilizatorul sub care rulează squid - de obicei un proxy). Marimea- setează dimensiunea maximă după care va începe ștergerea cache-ului. Există multe holivar în rețea pentru acest parametru. Dimensiunea ideală a memoriei cache este de 2 GB până la 10 GB, în funcție de numărul de clienți. Aproximativ 1 GB cache pentru fiecare 100.000 de solicitări/zi. Eu raman cu 5 GB. În Squid, fiecare obiect din cache este localizat într-un fișier separat, fișierele în sine nu sunt aruncate într-un singur loc, dar este utilizată o ierarhie de directoare pe două niveluri. Numărul de cataloage de 1 și 2 niveluri și determinați parametrii L1 și L2. Aceste valori pot fi lăsate implicite. Dar pentru orientare în situație, voi cita din bog.pp.ru:

Experimentul a arătat că, cu un cache de 700 MB, sunt folosite doar 2 directoare de primul nivel. Adică, pentru o structură standard de directoare cache, un milion de obiecte (9 GB) se potrivesc „confortabil” în ea, dacă sunt mai multe, atunci trebuie să măriți numărul de directoare de nivel superior

Puteți folosi mai multe cache_dir. Acest lucru are un efect pozitiv asupra performanței, mai ales dacă plasați memoria cache pe discuri diferite. Puteți accelera și mai mult memoria cache plasând memoria cache în tmpfs. Pentru fiecare parametru cache_dir posibil în secțiunea de opțiuni definiți opțiunile numai în citire (numai în citire) și dimensiunea maximă (dimensiunea maximă a obiectului).

Dimensiunea maximă a unui obiect din cache este determinată de parametrul maximum_object_size, valoarea implicită este de 4 MB. Am crescut această valoare la 60 MB, pentru că. angajații din rețeaua locală trebuie adesea să descarce fișiere de același tip până la dimensiunea specificată:

Dimensiunea_obiectului_maximum 61440 KB

De asemenea? au si parametrul minim_object_size responsabil pentru dimensiunea minimă a obiectului, implicit valoarea acestuia este „0”, adică este dezactivat. Recomand creșterea valorii acestui parametru la 2-3 KB, ceea ce va reduce sarcina de pe disc la căutarea obiectelor mici.

Berbec, folosit de calamar este instalat parametrul cache_mem, valoarea implicită este 256 MB (în versiunea 3.1). Am lăsat această valoare ca implicită. Merită să schimbați această valoare numai dacă calmarul vă întreabă despre asta în jurnalele. După aceste modificări, trebuie să reporniți squid, aceasta va crea structura de director:

Gw ~ # service squid3 start Pornirea Squid HTTP Proxy 3.x: squid3Crearea Squid HTTP Proxy 3.x structura cache... (avertisment). 2012/02/19 22:58:21| Crearea directoarelor de schimb 2012/02/19 22:58:21| /var/spool/squid3 există 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/00 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/01 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/02 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/03 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/04 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/05 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/06 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/07 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/08 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/09 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/0A 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/0B 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/0C 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/0D 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/0E 2012/02/19 22:58:21| Realizarea directoarelor în /var/spool/squid3/0F .

Sunt descrise multe întrebări interesante și răspunsuri la acestea cu privire la utilizarea memoriei și a cache-ului squid.Pe aceasta, putem considera o soluție tipică pentru configurarea unui server proxy completă.

exemplu de configurare proxy transparent squid

Ce este proxy transparent? Acesta este modul de operare al serverului proxy atunci când clientul nu este configurabil să lucreze printr-un proxy și să trimită cereri către rețea folosind protocolul HTTP, ca și cum clientul browser ar lucra direct cu serverul web. În același timp, prin forțe (în linux - ) cererile HTTP de ieșire sunt direcționate către portul pe care rulează proxy-ul. Serverul proxy, la rândul său, convertește cererile HTTP în solicitări de protocol de server proxy și trimite răspunsuri către client ca pe un server web. Acea. clientul interacționează transparent cu serverul proxy.

Este important să înțelegi și să cunoști! Această metodă acceptă numai protocolul HTTPși nu acceptă Gopher, FTP sau alte tipuri de proxy. De asemenea, Squid nu poate funcționa în modul transparent și în modul de autentificare în același timp.

Pentru a configura modul transparent, trebuie să:

1. Setați modul transparentîn setările proxy. Acest lucru se face în parametrul http_port, de exemplu:

Http_port ip:port transparent

2. Încheierea utilizatorilor regula corespunzătoare portului dorit folosind iptables:

Iptables -t nat -A PREROUTING -i incoming_interface_name -s LAN_subnet -p tcp --dport 80 -j REDIRECT --to-port squid_port, exemplu: iptables -t nat -A PREROUTING -i eth1 -s 10.0.0.0/24 - p tcp --dport 80 -j REDIRECT --la-port 3128

Toate. Este posibil să vă bucurați de utilizatorii împachetati și nebănuiți pe serverul nostru proxy.

Depanare

Pentru inceput, diagnosticarea operațiunii de calmar se află în vizualizarea jurnalelor situat în /var/log/squid3. Cele mai multe probleme sunt rezolvate în acest fel. Dacă acest lucru nu a ajutat la rezolvarea problemei, atunci treceți demonul în modul de depanare cu comanda squid3 -k depanare problema va fi mai usor de gasit. De fapt, ce este un buștean de calmar? Fișierele jurnal conțin diverse informații despre încărcarea și performanța Squid. Pe lângă informațiile de acces, /pre mai scrie în jurnal erorile de sistem și informații despre consumul de resurse, cum ar fi, de exemplu, memorie sau spațiu pe disc.

Format de fișier jurnal Squid este un șir de valori separate prin unul sau mai multe spații:

time.ms response_time ip_src Squid_req_status/HTTP_status byte_snd metoda URL utilizator squid_her_status/ip_dst MIME

• timp- ora în format unix (număr de secunde de la 00:00 la 1970.01.01)
• Domnișoară- milisecunde până la 3 cifre
• timp de raspuns- timp de răspuns, milisecunde
• ip_src- adresa IP sursă
• squid_req_status- starea cererii squid (de exemplu, TCP_HIT pentru obiectele memorate anterior în cache, TCP_MISS dacă obiectul solicitat nu este preluat din memoria cache locală, UDP_HIT și UDP_MISS la fel pentru cererile de frați)
• Stare_HTTP- starea protocolului http (200 pentru succes, 000 pentru cereri UDP, 403 pentru redirecționări, 500 pentru erori)
• byte_snd- transmis, octeți ca răspuns, inclusiv antetul HTTP
• metodă- metoda de solicitare GET sau POST
• URL- adresa URL solicitată
• utilizator- nume de utilizator autorizat
• squid_her_status- starea ierarhiei calmarilor - Rezultatul solicitărilor către cache-urile fraților/părinților
• ip_dst- adresa IP a nodului solicitat
• MIMA de tip mimic

Să ne uităm la un exemplu:

1329732295.053 374 10.0.1.55 TCP_MISS/200 1475 GET http://www.youtube.com/live_comments? - DIRECT/173.194.69.91text/xml

După cum puteți vedea, cererea a fost făcută la 1329732295.053, răspunsul serverului de la distanță a fost de 374 ms, gazda care a solicitat pagina are IP 10.0.1.55, obiectul solicitat nu a fost transferat din cache-ul local (TCP_MISS), serverul codul de răspuns a fost 200, 1475 de octeți au fost trimiși către client folosind metoda GET, a fost solicitat adresa URL http://www.youtube.com/live_comments?, numele de utilizator nu a fost definit, obiectul a fost primit direct de la server cu IP 173.194.69.91, textul a fost transmis, deoarece mime-text/xml. Aici.

Câteva puncte finale despre calmar3

În articol, am trecut în revistă principiile de bază ale serverului proxy, precum și setările de bază care vă permit să implementați cel mai simplu server de cache, precum și să organizați funcționarea squid într-un mod transparent (transparent). Squid acceptă mai multe opțiuni de autorizare (prin IP, LDAP, MySQL, NTLM etc.), capacitatea de a limita lățimea de bandă a canalului și de a controla accesul la resursele de Internet. Voi lua în considerare munca unui calmar cu diferite metode de autorizare și exemple de control al traficului în articolele următoare.