Linux tips and tricks/Transparent proxy: differenze tra le versioni

In entrambi i casi, il filtratore si comporta come ''url rewriter'' nel senso che, in base alla sua configurazione, sostituisce la URL che ha ricevuto dal proxy con un'altra, tipicamente la URL di una pagina recante un messaggio del tipo ''spiacente, il sito che volevi raggiungere non sembra collegato agli interessi dell'Azienda'', o qualcosa del genere. Il proxy prende per buona questa URL ricevuta dal filtratore, sia che sia il proxy stesso a invocare il filtratore come sottoprocesso, sia che riceva dal filtratore una URL riscritta direttamente via rete.

 

 

I proxy sono una categoria di software molto ampia, per cui in questo contesto saranno necessarie alcune grossolane semplificazioni per non divagare troppo. Basterà pensare al proxy come a uno strato software che si interpone, in modo appunto trasparente, fra il browser e la rete. Ma non è un semplice passa-carte, perché prima di inoltrare nella rete le richieste che ha ricevuto dal browser, può decidere di fare diverse cose con queste richieste. Potrebbe essere egli stesso a riscrivere le URL, ma si tratta di un compito estremamente particolare che richiede un software specifico, e quindi i proxy sono di solito una parte di un'architettura in cui un'altra componente si occupa del rewriting.

Due proxy molto diffusi sono squid e tinyproxy. Il primo offre una notevole varietà di funzioni, per lo più inutili per gli obiettivi di questo testo, ma è anche molto stabile e supportato. Tinyproxy è molto veloce, richiede risorse limitate, ma è anche limitato nelle funzioni e non brilla per documentazione. A voi la scelta.

 

 

Come si è già detto, la riscrittura o redirezione delle richieste HTTP, per gli scopi elencati nell'introduzione, ha senso solo se attuata in maniera coercitiva. GNU/Linux permette di riscrivere in maniera trasparente le richieste HTTP per qualsiasi utente tramite opportune regole impostate con il comando ''iptables'' che vedremo più avanti. Questo comando è però solo un'interfaccia per consentire a un amministratore di impostare delle regole che, per loro natura, valgono a livello del kernel, e modificano il modo in cui lo stack TCP/IP, gestito appunto dal kernel, reagisce a determinate situazioni.

Quando questa opzione è selezionata, dovrebbero essere visibili anche tutte le ulteriori opzioni ad essa subordinate. Non è una cattiva idea selezionarle tutte, magari come moduli per caricare in memoria solo quelli necessari. Di certo va selezionato il modulo ''owner'', indispensabile nelle situazioni in cui il proxy si trova sullo stesso host da cui provengono le richieste HTTP: in questo caso, infatti, lo stesso host deve sia intercettare richieste per la porta 80 (la caratteristica porta HTTP), sia creare egli stesso richieste HTTP da mandare all'esterno, ma che finirebbero a loro volta intercettate! L'unico modo per uscire da questo circolo vizioso è filtrare tutte le richieste HTTP, eccetto quelle prodotte dall'utente che esegue il software di proxy, e per questo è necessario il supporto degli utenti del sistema locale a livello di Netfilter, come apparirà più chiaro nella prossima sezione.

 

 

Si illustra ora una prima soluzione basata su squid e squidGuard, rispettivamente come proxy e url rewriter. In questa soluzione, al di là delle caratteristiche e funzionalità dei due software, la cosa interessante è che squidGuard è invocato da squid come un qualunque comando, per cui squidGuard in effetti non partecipa della stack TCP/IP.