www.MegaLab.it

Avviare ed auto-avviare Squid

Salvate il file di configurazione ed impartite service squid start nel terminale per avviare il relativo servizio. In caso tutto sia funzionante, verrà mostrato l'incoraggiante OK verde.

Impostate quindi il servizio di modo che si auto-avvii anche ad ogni accensione del server lanciando chkconfig squid on oppure spuntando la casella di controllo relativa a squid e cliccando quindi il pulsante Save in System -> Administration -> Services

Utilizzare Squid per gestire le richieste

È ora necessario fare in modo che il server "passi" a Squid le richieste di gestione dei contenuti.

Il modo più semplice di procedere è quello di modificare il file routing.sh presentato in "Creare un "super router" con un vecchio PC e CentOS". Lanciate quindi gedit /root/routing.sh (adeguando, naturalmente, il percorso a quello in cui avevate salvato il file).

Una volta aperto lo script, cercate la stringa SQUID per trovare il BLOCCO DI ISTRUZIONI CHE ABILITANO L'USO DI SQUID.

Rimuovete ora il simbolo # da tutti i comandi che fanno parte di questo gruppo di istruzioni, salvate il file e ricaricate lo script con sh /root/routing.sh.

Provare la connettività

A questo punto, potete provare ad accedere al web dai vari client. A meno di errori di configurazione, tutto dovrebbe funzionare regolarmente, con l'unica differenza che è Squid a gestire le richieste: se provate ad arrestare il servizio sul server (service squid stop) e a ricaricare una pagina su un client, dovreste ricevere un errore di connettività assente.

Per tenere sott'occhio in tempo reale le richieste gestite da Squid, lanciate sul server il comando tail -f /var/log/squid/access.log e provate ad aprire una pagina qualsiasi sui client

Per uscire, premete Ctrl+C sulla tastiera.

Un problema chiamato "HTTPS"

A complicarci un po' la vita ci pensano le connessioni HTTP "sicure" (HTTPS), ovvero quelle cifrate tramite tecnologia SSL.

Con la configurazione ottenuta fin qui, tutte le richieste a pagine quali https://google.com (notate la s finale nel nome del protocollo) mostreranno un avviso di sicurezza nel browser dell'utente, il quale sarà chiamato a confermare una o più finestre di dialogo prima di poter procedere

Purtroppo, al momento non v'è modo di risolvere questo inconveniente mantenendo l'impostazione agile e centralizzata vista fino a qui.

In caso questa limitazione risultasse inaccettabile, l'alternativa è quella di consentire all'utenza di accedere alle pagine crittografate senza passare per Squid: per farlo, inserire il carattere # all'inizio delle seguenti righe nel file routing.sh (sono le ultime del blocco di istruzioni dedicate all'uso di Squid)

#$IPT -t nat -A PREROUTING -i $LAN1 -p tcp --dport 443 -j REDIRECT --to-port 3129 #$IPT -A INPUT -j ACCEPT -m state --state NEW,ESTABLISHED,RELATED -i $LAN1 -p tcp --dport 3129 #$IPT -A OUTPUT -j ACCEPT -m state --state NEW,ESTABLISHED,RELATED -o $WAN -p tcp --dport 443 #$IPT -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED -i $WAN -p tcp --sport 443 #$IPT -A OUTPUT -j ACCEPT -m state --state ESTABLISHED,RELATED -o $LAN1 -p tcp --sport 443

Notate però che, così facendo, perderete qualsiasi capacità di memorizzare in cache o di filtrare i contenuti richiesti via HTTPS.

Filtrare i contenuti

Arrivati a questo punto, state sfruttando la capacità di accelerare il web e ridurre l'impatto sulla banda.

Poterebbe però essere interessante anche filtrare i contenuti, impedendo, ad esempio, di visitare siti pornografici, oppure inadatti all'uso "da ufficio": ne abbiamo parlato più dettagliatamente in "Bloccare Facebook, YouTube, porno, malware ed altre risorse inadeguate con un server CentOS".