Un pizzico di nostalgia mi porta su queste pagine e risveglia un torpore di scrittura che andava avanti ormai da un po’ troppo tempo. Messi da parte i giorni delle intrepide (come lo stambecco ubuntiano) avventure libanesi, le guide da paladino della giustizia e i consigli da “mi manda raitre”, mi ributto a capofitto su ciò che mi viene meglio: raccontare il “come si fa” quotidiano di chi, incidentalmente, si diletta a fare il mio stesso mestiere.

La guida che leggerete è sicuramente particolare, quantomeno interessante e difficile da trovare in lingua italiana: questi i motivi per cui mi decido a scriverla.
L’architettura che andremo a realizzare è basata su Squid, il popolare proxy-cache server opensource, e vedremo come questo potentissimo amico riesce a dare il meglio di se e a stupire anche nelle architetture più complesse. L’obiettivo, infatti, è quello di installare un sistema di proxy-caching distribuito in parent-child configuration, integrando l’oggetto “child” con un antiviral engine proprietario come Symantec Scan Engine, e con un sistema di autenticazione ldap-based. Ma andiamo con ordine.

Overview: in che contesto ci muoviamo?

In strutture di rete complesse, solitamente è la network di DMZ (Demilitarized Zone) che si occupa di gestire i contatti tra l’intranet e l’esterno e viceversa. Le risorse disponibili in DMZ (solitamente server mail, webserver, server Dns, proxy server eccetera) devono essere separate dalla LAN per non comprometterne l’integrità. Ciò comporta l’impossibilità, da parte di un client di rete interna, di poter raggiungere un host fisico in DMZ o un servizio presente su di esso.

Se vogliamo implementare un servizio proxy-cache per velocizzare e controllare l’accesso ad internet dei nostri client, sarà indispensabile posizionare il server proxy su una delle macchine della DMZ. Come consentire, quindi, agli utenti della nostra rete di utilizzare il server proxy (che di base non raggiungerebbero direttamente) per poter accedere ad internet?

La risposta alla nostra domanda: Squid e la configurazione parent-child.

Una possibile soluzione è senza dubbio quella di effettuare due installazioni di Squid, una sull’host fisico della DMZ, e un’altra su un host fisico presente su una rete che faccia da trait d’union fra la nostra LAN e la zona demilitarizzata. Ovviamente solo per alcuni servizi e per alcuni protocolli.
Le due installazioni di Squid saranno in contatto fra di loro in una gerarchia che chiameremo “di padre-figlio” (da cui parent-child) per la quale l’installazione “padre” sarà quella che, fisicamente, mantiene il contatto con l’esterno e serve le pagine web, mentre l’installazione “figlio” sarà quella fisicamente raggiungibile dagli utenti della lan e alla quale essi inoltreranno le richieste.

Il “child Squid”, una volta ricevuta la richiesta dal client, controllerà sulla propria cache la presenza del dato. In caso di risposta positiva servirà la pagina in modalità “offline” all’utente, altrimenti inoltrerà la richiesta al “parent Squid”, il quale si comporterà alla medesima maniera: controllerà la presenza del dato sulla parent cache e, se la trova serve la pagina, altrimenti effettua materialmente la richiesta via internet e riceve la risposta dalla rete. Tale risposta verrà rispedita al child e servita all’utente finale.

Lo schema qui sotto potrebbe risultare esplicativo.

Squid Parent-Child Schema

Vediamo ora come configurare correttamente le due installazioni per ottenere l’effetto voluto.

Bookmark It