Místo toho, aby se klient spojil se serverem, na kterém se zdroj nachází, spojí se s proxy-serverem, a ten požadovanou informaci získá (pošle) z (na) originální zdroj. Kešující proxy-server si informace přes něj procházející může uložit, a jsou-li po něm požadovány znovu, poskytne svou lokální kopii.
Proxy-server samotný většinou slouží jako relativně bezpečné spojení dvou sítí, které mezi nimi umožňuje jen přesně definovanou komunikaci. Můžete například povolit HTTP/FTP přístup jen vybrané skupině lidí nebo počítačů k vybraným zdrojům. Počítače nemusí být schopné samy komunikovat s druhou sítí. Přínosem proxy-serveru je především možnost oddělení sítí a umožnění jen vybrané komunikace.
S kešujícím proxy-serverem navíc můžete výrazně ušetřit provoz, který mezi sítěmi vzniká při opakovaném požadavku na stejný dokument. Velkým problémem kešování WWW je možná ztráta aktuálnosti poskytovaných dat – v keši je uložena starší verze dokumentu než na původním serveru. Při konfiguraci musíme najít kompromis mezi aktuálností dat a úsporou datového provozu.
Typicky squid použijeme k připojení vlastní sítě k Internetu. Squid je však velmi výkonný, může pracovat s obrovskou zátěží a je často používán pro optimalizaci provozu na velkých páteřních sítích. Navíc se se squidem dají dělat různé psí kusy jako třeba odfiltrování bannerů…
Squid má GNU licenci, běhá na spoustě různých UNIXů a je součástí mnoha linuxových distribucí. Homepage je tady: www.squid-cache.org
Konfigurujeme squid:
Hlavním konfiguračním souborem je squid.conf
, většinou umístěný v adresáři /etc/squid
, nebo /usr/local/squid/etc
. Na první pohled potěší množství kvalitních komentářů v defaultním konfiguračním souboru (má bratru 90kB!). Každý řádek je pečlivě popsán. Vše je pro názornost nastaveno na víceméně rozumné defaultní hodnoty a zakomentováno. (Chceme-li nějakou hodnotu změnit, je nutné řádek odkomentovat.)
Základní nastavení:
Jako jiní démoni, pokud je squid spuštěn s rootovými právy, snaží se jich co nejrychleji zbavit. Defaultně běží pod uživatelem squid a skupinou squid (viz cache_effective_user
a cache_effective_group
). Balíčkovací nástroje jako RPM se o jejich existenci postarají samy. Důležité je, že tento uživatel musí mít dostatečná práva k adresáři s keší.
Než si squid poprvé vyzkoušíme, musíme nastavit místo, kam se bude ukládat keš. Slouží k tomu klauzule cache_dir
a defaultně bude nejspíš nastavena na /var/spool/squid
. Další parametry pak určují maximální velikost keše v MB a počet podadresářů (dvě úrovně), které si squid v keši vytvoří. (Squid ukládá každý kešovaný objekt do zvláštního souboru. Těch můžou být u větších keší třeba desítky milionů a není efektivní je mít v jednom adresáři…) Pro zkoušku můžeme snížit počty podadresářů, aby jejich vytváření zbytečně nezabralo moc dlouho. Keš se poprvé inicializuje spuštěním squid -z
Pár důležitých věcí, které byste mohli chtít změnit před prvním spuštěním:
http_port
(číslo portu, kam se připojují klienti),
cache_mem
(velikost keše v paměti – na režii se použije ještě nejmíň jednou tolik – je blbost nastavit tolik, aby systém swapoval, to už si na disk může squid hrábnout sám… )
O něco složitější je nastavit, kdo smí a kdo nesmí proxy využívat…
ACLs
Squid má poměrně dobře propracovaný systém ACL (Access Control List). I když omezení přístupu k proxy je asi nejdůležitější, k čemu se ACLs používají, uplatní se ve squidu i na několika jiných místech.
ACL třídy se definují pomocí řádek začínajících acl
a požadavky do jednotlivých tříd můžeme řadit podle opravdu mnoha různých parametrů: IP, port, čas, cílová IP, cílová URL, vlastní autentizace a mnoho dalších. ACL operátory pak, na základě tříd, ve kterých požadavek je, určují, co s ním bude dál.
Použití ACL si ukážeme na jednoduchém příkladě. POZOR!, tady v konfiguračním souboru záleží na pořadí řádek! K řízení HTTP přístupu k proxy je používán ACL operátor http_access
. Standardně v konfiguračním souboru najdeme asi toto:
http_access allow manager localhost http_access deny manager # Deny requests to unknown ports http_access deny !Safe_ports # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # And finally deny all other access to this proxy http_access allow localhost http_access deny all
A tak squid, když musí rozhodnout o tom, který požadavek od klienta pustit a který ne, vezme první z těchto řádků.
Vidí, že pokud požadavek spadá do ACL třídy manager
A zároveň do třídy localhost
, má jej povolit. Tak zkontroluje, zda požadavek do těchto tříd patří. Pokud ano, je požadavek povolen a tím vyhodnocování končí. Pokud ne, přejde se k dalšímu řádku.
Ten říká, že vše, co patří do třídy manager
, se má zakázat. Takže spolu s prvním řádkem to znamená: „Pokud požadavek patří do třídy manager
, povol jej jen tehdy, pokud zároveň patří do localhost
“. Podíváme se na definici těchto tříd:
acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255
Třída manager
jsou požadavky, které používají speciální squidův protokol a používají se jen pro administrativní účely (viz dále). Třída localhost
jsou požadavky z IP adresy 127.0.0.1, tedy z našeho loopbacku. Takže výsledek: „protokolem cache_object jen z lokálního počítače“
Další řádek, http_access deny !Safe_ports
, je zajímavý dvěma věcmi: Použití vykřičníku jako logického NOT, a pak způsobem, jakým je třída Safe_ports
nadefinována:
acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews ...
Vidíme, že třídu můžeme definovat několika acl
-řádky. Platí mezi nimi logické OR. Takže řádek http_access deny !Safe_ports
znamená „zakaž vše, co nejde na porty 80, 21, 443, 563, …“
No a pak se ještě zakáže CONNECT na non-ssl porty a už je tu místo, kam umístit patřičné povolení pro koho chceme. Dalším řádkem se povolí vše z loopbacku (třída localhost
) a pak už se všechno ostatní šmahem zakáže (třída all
je definována jako acl all src 0.0.0.0/0.0.0.0
, tedy „odkudkoli“).
Takže teď, když do toho trochu vidíme, můžeme přidat například povolení pro naši lokální síť. Řekněme, že je to třeba 192.168.0.x.
Na nějaké hezké místo mezi acl vsuneme řádek:
acl moje_sit src 192.168.0.0/255.255.255.0
a nejlépe na vyznačené místo řádek:
http_access allow moje_sitObsáhlý popis squidových ACL je tady
ready, steady, go…
Tak… můžeme squida spustit. Systémy jako RedHat si na squida vytvoří skripty samy, takže stačí něco jako service squid start
, pro automatický start chkconfig squid on
… znáte to. Ostatní prostě spustí binárku (většinou /usr/sbin/squid
)
Pokud je vše v pořádku, měl by fungovat telnet 127.0.0.1 3128
(nebo kolik máte ten port nastavený). 2* enter by měl telnet ukončit s výpisem nějaké chybové hlášky v HTML…
Nastavte si v prohlížeči adresu a port vašeho serveru a zkuste, jak funguje. Odpověď na problémy hledejte v logu.
Logy jdou standardně do /var/log/squid
. cache.log
obsahuje informace o běhu programu, store.log
informace o diskové keši, a access.log
jednotlivé požadavky od klientů.
Pro potřeby debugování se dá poměrně přesně nastavit, co všechno se má logovat. Slouží k tomu v konfiguráku příkaz debug_options
. Ten má dva parametry, oblast, pro kterou chceme úroveň nastavit (viz doc/debug-sections.txt), a požadovanou úroveň.
Příště si ukážeme, jak nastavit transparentní proxy, jak použít redirector k odfiltrování bannerů, jak vyladit squidův refresh-algorithm podle svých potřeb a povíme si něco o hierarchickém kešování.