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

Ho un server fisico supermegacarrozzato dove ci infilo le macchine virtuali che mi chiedono continuamente. L’ultima richiesta era fantastica:

Ci servono 2 virtual machines per comporre un cluster, e altre tre per comporre un altro cluster. Fai te, basta che ce le metti a disposizione.

Guardo gli ip address statici a disposizione e…mmm…mi sa che non bastano…o se bastano li finisco…e se li finisco poi sono cavoli. E poi come lo simuli per benino un cluster in questa maniera?

E allora l’ingegno, l’aiuto del fido xen e la potenza di Linux mi hanno risolto il problema.

Ho creato le cinque macchine virtuali, con indirizzi di rete interna in classe 192.168.1.0/24. Sulla macchina host ho aggiunto due indirizzi statici su due interfacce virtuali in eth0 (eth0:1 e eth0:2 per capirci) e sull’eth1 del server (interfaccia fisica si intende) ho messo un indirizzo della stessa sottoclasse delle vm.

Una volta startate, le virtuali erano in sottorete con la macchina host. Quindi un solo indirizzo ip statico settato fisicamente su una eth virtuale del server host, diventava una specie di Virtual-IP perfetto per i rispettivi nodi del rispettivo cluster. Fantastico.

A quel punto era necessario dare accesso ai ragazzi alle macchine virtuali…e come fare? Vabbè domanda scema e risposta semplice: un paio di dnat facevano al caso mio. Più o meno scrivendo questo per cluster a due nodi:

iptables -t nat -A PREROUTING -i eth0 -d XXX.XXX.XXX.XXX -p tcp -m tcp –dport 22 -j DNAT –to-destination 192.168.1.2
iptables -t nat -A PREROUTING -i eth0 -d XXX.XXX.XXX.XXX -p tcp -m tcp –dport 222 -j DNAT –to-destination 192.168.1.3

e questo per il cluster a tre nodi:

iptables -t nat -A PREROUTING -i eth0 -d YYY.YYY.YYY.YYY -p tcp -m tcp –dport 22 -j DNAT –to-destination 192.168.1.12
iptables -t nat -A PREROUTING -i eth0 -d YYY.YYY.YYY.YYY -p tcp -m tcp –dport 222 -j DNAT –to-destination 192.168.1.13
iptables -t nat -A PREROUTING -i eth0 -d YYY.YYY.YYY.YYY -p tcp -m tcp –dport 2222 -j DNAT –to-destination 192.168.1.14

Questo per portare l’accesso ssh sulle macchine di backend passando dai rispettivi ip statici ai nodi in rete “interna”, ovviamente dopo aver abilitato il listening dell’ssh anche sulle porte interessate dal destination nat.

Difficile? Ma no! semplicissimo e molto divertente!!!

Bookmark It