[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
Nella terminologia utilizzata per le reti, una cache proxy è un servizio di memorizzazione locale delle risorse della rete richieste più frequentemente. Con il termine «risorsa» si deve intendere un oggetto a cui si accede attraverso un URI.
L'utilizzo di un proxy offre due vantaggi principali: l'accesso rapido a risorse già accumulate nella memoria cache e la riduzione del traffico nella rete che precede il proxy stesso.
Il proxy si interpone nella rete agendo, idealmente, al di sopra del quinto livello del modello ISO-OSI, come si vede nella figura 175.1. Infatti, il cliente di un proxy intrattiene normalmente una connessione HTTP o FTP; così il proxy deve intrattenere lo stesso tipo di connessione, per conto proprio, con il servente a cui il cliente avrebbe voluto rivolgersi realmente, a meno di ottenere tali risorse dalla sua memoria cache.
|
Il servizio di cache proxy può essere collocato in posizioni differenti nella rete, a seconda delle esigenze o delle particolarità delle situazioni. Generalmente, lo scopo è quello di servire un segmento di rete, indifferentemente dal fatto che questo segmento utilizzi indirizzi privati o sia accessibile dall'esterno.
Quando un proxy viene utilizzato per servire un segmento di rete rispetto alla rete esterna, senza fare altre considerazioni, è sufficiente che l'elaboratore su cui viene collocato il servizio sia accessibile da questo segmento di rete e che a sua volta sia in grado di accedere all'esterno.
|
A questa situazione appartiene anche il caso limite in cui il proxy serve solo se stesso, quindi la stessa macchina è servente e anche cliente.
Un proxy potrebbe servirsi di altri proxy quando si tratta di accedere a reti determinate, alleggerendo in questo modo il carico della rete anche in altri punti, non solo nel tratto immediatamente precedente.
|
La figura 175.3 mostra il caso di un collegamento a una rete esterna, (A), condiviso da due segmenti di rete, che si collegano a questa attraverso i collegamenti B e C. A valle del collegamento A si trova un proxy il cui scopo è quello di ridurre il più possibile il traffico attraverso quel tratto; a valle dei collegamenti B e C si trovano altri proxy locali il cui scopo è quello di ridurre il traffico attraverso i collegamenti rispettivi. In questa situazione, i proxy locali utilizzano a loro volta il servente principale, mentre tutto quello che viene accumulato nei proxy locali, viene conservato anche in quello principale.
Il servente proxy, se si trova in un elaboratore che è connesso simultaneamente, attraverso interfacce di rete differenti, a una rete interna con indirizzi privati (cioè esclusi da Internet) e alla rete esterna, può essere utilizzato per permettere ai clienti della rete privata di avere accesso all'esterno attraverso il proxy stesso.
Questo accesso si limita ai protocolli gestiti dal proxy; spesso si tratta solo di HTTP e FTP.
|
I clienti per la navigazione, vanno configurati per poter sfruttare il servizio della cache proxy. Per esempio, la figura 175.5 mostra la finestra di configurazione di un navigatore comune.
È interessante anche la configurazione di Lynx per l'utilizzo di un servizio di cache proxy. È sufficiente definire alcune variabili di ambiente, come elencato nella tabella 175.1. Per esempio, per utilizzare il protocollo HTTP attraverso il proxy http://proxy.brot.dg
nella porta 8 080, si potrebbe agire come si vede qui:
$
http_proxy="http://proxy.brot.dg:8080"
[Invio]
$
export http_proxy
[Invio]
$
lynx http://www.indirizzo.remoto"
[Invio]
Tabella 175.1. Elenco delle variabili di ambiente per la configurazione dell'accesso a un proxy da parte di Lynx.
Variabile | Descrizione |
http_proxy | Proxy per il protocollo HTTP. |
ftp_proxy | Proxy per il protocollo FTP. |
gopher_proxy | Proxy per il protocollo Gopher. |
wais_proxy | Proxy per il protocollo WAIS. |
Anche Links prevede una configurazione per l'utilizzo di proxy; si tratta di opzioni della riga di comando o di direttive di file di configurazione:
Opzione | Direttiva | Descrizione |
|
| Proxy per il protocollo FTP. |
|
| Proxy per il protocollo HTTP. |
I programmi di navigazione offrono anche la possibilità di richiedere al proxy di prelevare una nuova copia della pagina, anche se non sono scaduti i tempi previsti. Nel caso di programmi grafici si tratta normalmente di selezionare pulsanti grafici del tipo <Reload
>, <Ricarica
> o simili. Per quanto riguarda il caso particolare di Lynx, si può usare l'opzione -reload, mentre con Links si può usare la combinazione di tasti [Ctrl+r].
Se si vuole sfruttare un proxy nel modo indicato nella sezione 175.1.3, si possono usare solo programmi che prevedono espressamente la presenza di questo, attraverso i protocolli serviti effettivamente dal proxy stesso.
Prima di affrontare lo studio di un tipo particolare di cache proxy, vale la pena di riordinare le idee sulle esigenze tipiche di un servizio del genere, che poi si riflettono conseguentemente nella configurazione relativa. In breve i problemi riguardano essenzialmente i punti seguenti:
amministrazione della memoria cache
utente e gruppo proprietari di questi file
dimensione massima di una singola risorsa accumulabile
scadenza massima per la validità delle informazioni accumulate nella memoria cache
Indirizzi esclusi dall'accumulo nella memoria (solitamente quelli che contengono le stringhe ? e cgi-bin, perché riguardano probabilmente delle interazioni con programmi CGI)
utenze
individuazione degli indirizzi che possono accedere per utilizzare il servizio
utente fittizio mostrato all'esterno (di solito per l'accesso a un servizio FTP anonimo)
connessione
porta o porte attraverso cui resta in ascolto per le richieste di connessione (di solito si usa la porta 8 080)
indirizzi e porte di altri servizi del genere da interpellare se disponibili (per non sovraccaricare la rete)
Il servente HTTP Apache incorpora delle funzionalità di proxy elementare. In queste sezioni viene valutato solo ciò che è necessario fare per configurare il servizio attraverso il file httpd.conf
(collocato normalmente nella directory /etc/apache/
). Per il resto che riguarda Apache conviene consultare i capitoli 159 e 160.
In generale, Apache non è il software migliore per svolgere anche questo compito. Se possibile è meglio usare Squid. |
Per poter utilizzare la funzionalità di cache proxy di Apache è necessario attivare il modulo relativo, a meno che questo sia stato incorporato nell'eseguibile principale in base alla configurazione stabilita al momento della compilazione. Questa attivazione si fa con la direttiva seguente nel file httpd.conf
:
LoadModule proxy_module directory/libproxy.so
La direttiva in questione dovrebbe essere già stata predisposta, commentata in modo da non essere presa in considerazione. In tal modo non ci si deve preoccupare di trovare la directory giusta per la libreria indicata.
La configurazione predefinita di Apache non prevede la gestione del proxy. Di solito sono presenti alcune direttive di esempio, debitamente commentate, in modo da facilitare il lavoro dell'amministratore.
ProxyRequests {on|off}
La direttiva ProxyRequests permette di attivare o meno la gestione della cache proxy. L'esempio seguente mostra la sua attivazione.
ProxyRequests on |
CacheRoot directory_cache
La direttiva CacheRoot permette di definire la directory da utilizzare per contenere la memoria cache. La directory in questione deve risultare accessibile in scrittura all'utente e gruppo specificati con le direttive User e Group (potrebbe trattarsi di nobody, www-data o qualcosa di simile).
CacheRoot /var/cache/httpd/proxy |
CacheSize n_Kibyte
La direttiva CacheSize specifica la dimensione in kibibyte (simbolo: Kibyte) dello spazio su disco da utilizzare per la memoria cache. Questo valore può essere superato, ma periodicamente viene eseguito un controllo con l'eliminazione dei file più vecchi che eccedono tale limite. L'esempio mostra la dichiarazione di una memoria cache di 500 000 Kibyte.
CacheSize 500000 |
CacheGcInterval n_ore
In questo modo può essere definito l'intervallo tra una ripulitura e l'altra della memoria cache, alla ricerca di file troppo vecchi e di quelli che eccedono il limite di dimensione stabilita. L'esempio mostra la dichiarazione di un intervallo di controllo orario (una sola ora).
CacheGcInterval 1 |
CacheMaxExpire n_ore
I documenti HTTP vengono conservati per un massimo di ore stabilito con questa direttiva. Superato tale tempo, alla richiesta di un cliente, viene fatta una verifica dall'origine. Questo limite di tempo è imposto anche se il documento originale indica una data di scadenza superiore. L'esempio mostra una scadenza massima di 24 ore.
CacheMaxExpire 24 |
CacheDefaultExpire n_ore
Quando il tipo di protocollo non prevede l'indicazione di una scadenza, si utilizza il tempo indicato attraverso la direttiva CacheDefaultExpire.
CacheLastModifiedFactor fattore
Questa direttiva definisce un «fattore» utilizzato per calcolare un tempo di scadenza quando il documento originale non lo fornisce. In pratica si applica la formula x=t*f, dove f è il fattore, t è il tempo trascorso dall'ultima modifica, e x è il tempo di scadenza (il periodo di validità).
La logica sta nel fatto che è più probabile che una pagina venga modificata ancora entro breve tempo se la sua data di modifica è recente. Infatti, minore è il tempo trascorso dall'ultima modifica, minore sarà la durata di validità risultante dalla formula. L'esempio mostra un fattore di 0,1, pari al 10 % del tempo trascorso dall'ultima modifica.
CacheLastModifiedFactor 0.1 |
Ci sono situazioni in cui non è opportuno che il proxy accumuli nella sua memoria cache informazioni riferite a determinati domini o sottoreti. Di sicuro non è conveniente farlo per la propria rete locale, a meno che non ci siano delle buone ragioni.
NoCache {dominio|parola}...
Per escludere alcuni nodi o domini interi dalla memoria cache basta elencare i nomi, separati da uno spazio, con la direttiva NoCache. In generale verranno esclusi tutti gli indirizzi che contengono in qualche modo le «parole» indicate, per cui continuano a essere presi in considerazione gli indirizzi IP equivalenti.
NoCache roggen.brot.dg mehl.dg |
L'esempio esclude dalla memoria cache il nodo roggen.brot.dg
e il dominio mehl.dg
.
NoProxy {nome|dominio|indirizzo-ip|sottorete}...
Questa direttiva consente di dichiarare in modo più preciso cosa escludere dalla cache rispetto alla direttiva simile NoCache. L'esempio seguente esclude tutto il dominio escluso.dg
:
NoProxy escluso.dg |
Per attivare effettivamente il servizio, oltre alla configurazione del file httpd.conf
, occorre predisporre la directory utilizzata per la memoria cache. Questa deve essere accessibile in scrittura da httpd, nelle condizioni in cui si trova normalmente; in altri termini, deve essere accessibile all'utente secondo la cui identità è in funzione il demone. In generale potrebbe trattarsi di nobody, di www-data o di qualcosa di simile.
L'esempio seguente mostra le direttive del file httpd.conf
per una configurazione tipica. Ciò che può valere la pena di modificare è la dimensione della memoria cache.
ProxyRequests On CacheRoot /var/cache/httpd/proxy CacheSize 500000 CacheGcInterval 1 CacheMaxExpire 24 CacheLastModifiedFactor 0.1 CacheDefaultExpire 1 Listen 80 Listen 8080 |
In generale, un servizio proxy dovrebbe essere accessibile solo dalla rete (o sottorete) per la quale è stato attivato. Qualunque altro utente non ne potrebbe trarre vantaggio, mentre un utilizzo improprio servirebbe solo a intasare inutilmente il collegamento che invece si vuole alleggerire.
Per la protezione del servizio di cache proxy si può utilizzare una sezione Directory nel file access.conf
, come nell'esempio seguente:
<Directory proxy:*> order deny,allow deny from all allow from .brot.dg </Directory> |
In questo caso si concede solo al dominio brot.dg
di accedere.
Squid (1) è un programma specifico, molto potente, per la gestione di una cache proxy. Tuttavia, il suo difetto è la carenza di documentazione.
squid [opzioni]
Squid viene avviato normalmente attraverso la procedura di inizializzazione del sistema, in uno script, attraverso un comando che lo mette esplicitamente sullo sfondo, per esempio come nel modo seguente:
#
squid &
Le prime volte, l'avvio di Squid può riservare delle sorprese. È importante sapere che all'avvio Squid tenta di risolvere l'indirizzo di alcuni nodi, attraverso il DNS. Nella maggior parte dei casi, se Squid viene avviato in una rete chiusa, il servizio non parte perché questa richiesta fallisce.
Pertanto, se si avvia Squid quando si è isolati dall'esterno, occorre evitare che venga eseguito il controllo; per questo si utilizza l'opzione -D della riga di comando. |
Le distribuzioni GNU/Linux che prevedono Squid tra i pacchetti standard, dovrebbero avere organizzato uno script per il suo avvio automatico attraverso la procedura di inizializzazione del sistema; come già accennato. Se si intende avviare Squid quando non è presente uno sbocco verso Internet, potrebbe essere necessario modificare tale script in modo da inserire l'opzione -D, se questa non è già presente. Nel caso della distribuzione Red Hat, questo script si trova nella directory /etc/rc.d/init.d/
, mentre nel caso di Debian, si tratta della directory /etc/init.d/
.
squid -D & |
Per verificare che Squid funzioni correttamente, può essere sufficiente osservare l'albero dei processi attivi attraverso pstree. Si dovrebbe ottenere qualcosa come il pezzo seguente:
|
Come si può osservare, il binario squid pilota altri programmi che fanno parte dello stesso pacchetto.
Le opzioni, quando si riferiscono a elementi che possono essere definiti attraverso il file di configurazione, prendono il sopravvento su questa.
#
squid -z -F
Avvia squid in primo piano per azzerare e rigenerare le directory che compongono la memoria cache.
#
squid -D &
Avvia squid sullo sfondo, in modo da attivare il servizio di proxy, senza però eseguire il controllo DNS.
#
squid -k check
Verifica il funzionamento di Squid, in particolare anche la correttezza della configurazione attraverso il file /etc/squid.conf
.
#
squid -k shutdown
Invia un segnale di spegnimento al servente Squid già attivo.
RunCache è uno script aggiuntivo usato per avviare Squid e per controllare che non «muoia» accidentalmente. In pratica, serve a garantirne il funzionamento. Vale la pena di citarne la sua esistenza, anche se non è necessario il suo utilizzo, perché può capitare che la distribuzione GNU/Linux di cui si dispone sia organizzata in modo da avviare Squid attraverso questo meccanismo. Lo script potrebbe trovarsi nella directory /usr/lib/squid/
.
Squid utilizza file specifici per la registrazione degli eventi, anche quando si utilizza l'opzione -s per inviare informazioni al registro del sistema. Questi file si trovano nella directory /var/log/squid/
. Quando si invia al servente il segnale rotate (attraverso l'opzione -k), si ottiene l'archiviazione dei file, aggiungendo loro un'estensione numerica che ne indica il livello. Per esempio, cache.log.0
rappresenta l'archivio più recente di cache.log
.
La configurazione di Squid avviene attraverso il file /etc/squid.conf
, o un altro file se viene usata l'opzione -f. Questo file è già configurato in modo da permettere a Squid di funzionare in quasi tutte le situazioni, tuttavia sarebbe bene ritoccare qualcosa; per esempio il numero di porta del servizio e il dominio o il gruppo di indirizzi a cui concedere di poterlo utilizzare.
La sintassi del file è molto semplice: ciò che è preceduto dal simbolo #, viene trattato come un commento fino alla fine della riga; le righe bianche e le righe vuote sono ignorate; il resto sono le direttive, composte nel modo seguente:
direttiva [argomenti]
Segue la descrizione di alcuni esempi.
http_port 8080 |
Definisce la porta 8 080 per l'accesso al servizio.
http_port 3128 8080 |
Definisce sia la porta 3 128, sia la porta 8 080 per l'accesso al servizio.
icp_port 3130 |
Definisce la porta 3 130 per le comunicazioni ICP con i cache proxy vicini.
cache_peer 192.168.77.7 parent 8080 3130 |
Indica un nodo da trattare come «vicino» ai fini della funzione di cache proxy (potrebbe essere la cache proxy del proprio ISP). In questo caso viene indicato il numero IP 192.168.7.7, a cui si accede attraverso la porta 8 080 e si comunicano i messaggi ICP tramite la porta 3 130.
cache_mem 4 |
Riduce a 4 Mibyte la dimensione ottimale per la RAM utilizzata come memoria cache (altrimenti verrebbero usati 8 Mibyte in modo predefinito).
cache_dir /var/spool/squid 200 16 256 |
Indica la directory da usare per lo scambio su disco, specificando che possono essere usati al massimo 200 Mibyte, strutturando la directory in 16 livelli che si suddividono ulteriormente in 256 sottolivelli.
maximum_object_size 2048 KB |
Riduce a 2 Mibyte la dimensione massima degli oggetti accumulati nella memoria cache (altrimenti questa sarebbe di 4 Mibyte in modo predefinito).
#Defaults: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl SSL_ports port 443 563 acl Safe_ports port 80 21 443 563 70 210 1025-65535 acl purge method PURGE acl CONNECT method CONNECT |
Quelle che si vedono nell'esempio sono le direttive acl che appaiono nel file /etc/squid.conf
standard. In generale conviene lasciarle come sono. Vengono riportate qui per permettere la comprensione degli esempi che verranno mostrati successivamente.
#Default configuration: http_access allow manager localhost http_access deny manager http_access allow purge localhost http_access deny purge http_access deny !Safe_ports http_access deny CONNECT !SSL_ports |
Anche queste direttive sono standard, concedendo poche funzionalità solo agli accessi locali.
acl localnet src 192.168.0.0/255.255.0.0 http_access allow localnet http_access allow localhost http_access deny all icp_access allow localnet icp_access allow localhost icp_access deny all miss_access allow localnet miss_access allow localhost miss_access deny all |
Dopo le direttive standard già mostrate in precedenza, questo dovrebbe essere il modo più conveniente di intervenire per limitare l'accesso al servizio, avendo definito il nome localnet per individuare la rete locale a cui concedere l'accesso (in questo caso 192.168.0.0/16), oltre all'elaboratore locale stesso.
Si può osservare in particolare che il nome all viene usato per impedire gli accessi da parte di nodi che non ricadano nel gruppo fissato dal nome localnet o dal nome localhost.
Squid si compone del binario squid e di altri accessori, con funzioni specifiche, avviati da questo. Si tratta di dnsserver, pinger e unlinkd, che potrebbero trovarsi nella directory /usr/lib/squid/
, proprio perché non sono fatti per essere usati direttamente.
dnsserver viene usato per le interrogazioni DNS e solitamente ne vengono avviate diverse copie per accelerare le operazioni.
pinger viene usato per il protocollo ICMP; in particolare deve funzionare con i privilegi dell'utente root. Per questo motivo, è normale che appartenga a root è che abbia il bit SUID attivato (SUID-root).
unlinkd è un programma molto semplice che serve a cancellare file: cancella di volta in volta i file i cui nomi gli vengono forniti attraverso lo standard input. L'utilità di un tale programma sta nel non dover avviare ogni volta un nuovo processo per la cancellazione di ogni singolo file.
Squid fornisce un programma CGI per l'interrogazione del servizio proxy da parte dell'amministratore. Se viene installato correttamente, vi si dovrebbe accedere attraverso l'indirizzo http://localhost/cgi-bin/cachemgr.cgi
. La configurazione predefinita di Squid dovrebbe escluderne l'utilizzo da parte di utenti che accedono da nodi differenti da localhost
.
Come si vede dalla figura 175.6, è necessario indicare almeno il nome del servente e il numero di porta del proxy.
Squid Web Proxy Cache
daniele @ swlibero.org
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome cache_proxy.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]