[LUGargano] Problemone con squid (lungo).

Carmine Malice instarvega_capitanlug@yahoo.it
Lun 9 Feb 2009 14:22:08 CET


Io e Alessandro stiamo puntando alla stessa ipotesi, ma credo ci siano 
delle imprecisioni.

Fondamentalmente, un web proxy "trasparente", e pertanto "obbligatorio" 
ma privo di autenticazione - e perciò di tracciamento - degli utenti, 
funge da router/gateway secondo il seguente schema

###

client chiede servizio presso server esterno su porta 80

-->

router/gateway/proxy raccoglie la richiesta destinata a porta 80 *ma* al 
proprio interno la gira al proprio servizio di web proxy

-->

la richiesta raggiunge il servizio esterno su porta 80 *ma* oramai a 
tutti gli effetti è una richiesta del web proxy

###

In questo modo non c'e' bisogno che un firewall blocchi le richieste 
verso le porte 80 e men che meno verso servizi "innoqui" come il DNS, 
semplicemente tali richieste vengono "catturate e rigirate all'interno", 
poi chiaramente si potra' desiderare di bloccare le richieste verso 
altri servizi p.e. FTP su porta 21 (non ricorrendo ad un analogo 
meccanismo di FTP proxy trasparente).

Certo l'ipotesi "autonoma" che le richieste per DNS siano state bloccate 
rimane a margine, e d'altra parte pare non si abbia a che fare con un 
sistema DHCP.

In tutto questo non scorgo ancora punti di "frattura" tranne una 
situazione che ho gia' sperimentato: l'insistenza di entrambe le 
interfacce di rete di un router+proxy sullo stesso switch, nel mio caso 
preferii però un web proxy non trasparente perche' necessito di 
autenticazione&tracciamento (percio' la soluzione fu configurazione 
"pseudomanuale" degli IE e blocco di tutte le richieste verso una serie 
di porte, mediante regola di iptables che mandava in DROP).

Nella mia situazione i client erano tutti IE in Windows ma il 
router/proxy (macchina con IPCop con estensioni) si "addormentava" 
inesplicabilmente in momenti e per periodi imprevedibili.
La soluzione fu *isolare fisicamente* la LAN mediante il ricorso a 2 
switch: uno per l'interfaccia di rete "interna" del router proxy e la 
LAN da questo servita e l'altro per collegare l'interfaccia di rete 
"esterna" del router/proxy al "resto del mondo".
Attenzione: questo accorgimento e' successivo e subordinato al primo e 
piu' fondamentale accorgimento di *dover* collocare la LAN servita in 
una subnet logicamente diversa da quella che porta al "resto del mondo", 
io addirittura collocai la LAN servita in una classe B (172.16.x.y) che 
era poi instradata dal router/proxy verso una classe A (10.x.y.z).

Facci sapere.

Pietro Tamburrano ha scritto:
> Il giorno sab, 07/02/2009 alle 17.36 +0100, Alessandro Rendina ha
> scritto:
>> Io ipotizzo questo:
>> il sysadmin ha bloccato tutto con iptables, e ha abilitato il proxy per far 
>> passare solamente http, tra le porte bloccate ci sono anche quelle del DNS.
>> Per ovviare a questo problema il sysadmin ha impostato una dns cache su 
>> 192.168.0.1. 
>> Per qualche motivo questa informazione viene passata ai sistemi windows ma non 
>> hai sistemi linux. I sistemi windows funzionano anche con ip statico o sono 
>> con dhcp?
>>
>> Se ho ragione potresti fare questo test:
>>
>> 1) impostare il proxy di firefox su 192.168.0.1 (le porte utilizzate di solito 
>> sono 3128 oppure 8080) così secondo me dovrebbe andare in qualunque 
>> situazione (a meno di problemi di configurazione di squid).
>>
>> 2) impostare sui client in /etc/resolv.conf il nameserver a 192.168.0.1,
>> verificare anche:
>>  ifconfig 
>> route
>>
>> in pratica per questo secondo test la configurazione da shell dovrebbe essere 
>> la seguente:
>>
>> echo "nameserver 192.168.0.1" > /etc/resolv.conf 
>> ifconfig eth0 192.168.0.2 up
>> route add default gw 192.168.0.1
>>
>> mi è venuto in mente che su ubuntu/debian c'è un software (resolvconf) che 
>> quando non riesce a ricevere un server dns, ti azzera automaticamente il file 
>> resolv.conf il che vorrebbe dire che perdi automaticamente le impostazioni 
>> del dns, il file esegue questa roba ogni "tot" tempo quindi potrebbe essere 
>> il tuo problema.
>> Nel caso non usi dhcp puoi disinstallarlo (anzi io lo disinstallo sempre 
>> perchè ci ho litigato, non mi piacciono i software che mi cambiano i files di 
>> configurazione di domenica, ps: è successo veramente)
> 
> 
> Lunedì faccio qualche prova e vi faccio sapere.
> 
> Ciao.
> 
> --
> La permanenza in lista LUGargano e` regolata dal rispetto degli altri e della Netiquette:
>             http://www.nic.it/NA/netiquette.txt
> 


Maggiori informazioni sulla lista LUGargano