[LUGargano] Problemone con squid (lungo).

[Carmine Malice]

La netmask 255.255.252.0 per la subnet 192.168.0.0 letteralmente non ha 
senso perche' amplia il relativo intervallo ("range") di indirizzi di 
host oltre il limite naturale del numero assegnabile ad essa che, in 
quanto appartenente alla classe C, e' di 254: avrebbe senso una netmask 
255.255.255.192 che andrebbe a *limitare* il relativo numero di host 
accoglibili a 62 (cfr. http://a2.pluto.it/a2318.htm) ma non ha senso 
l'ampliamento, il quale sconfina.
In verita', tutte le caratteristiche intrinseche delle reti e sottoreti 
in TCP/IP sono mere convenzioni, non sono fattori "materiali e 
strutturali", ma a non rispettare tali convenzioni si va incontro - per 
usare termini tecnici - a guai imprevedibili: nel tuo caso, in pratica, 
sussiste l'eventualita' che tra gli host *locali* ci sia qualcuno che 
prenda un IPAddress "pubblico" (e non "locale") e pertanto si renda 
irraggiungibile perche' il tragitto ("route") dei pacchetti di un altro 
host verso lui passerebbe per il router onde "andare fuori verso 
destinazione e non tornare indietro nel loro stato primigenio".

Premesso questo, dall'output scaturisce involontariamente la notizia che 
il router/gateway/proxy e' un sistema IPCop e pertanto ti dico di 
provvedere innanzitutto alla verifica che
- la sua interfaccia di rete "interna" serva una subnet differente da 
quella cui appartiene l'interfaccia di rete "esterna"
- tali 2 interfacce insistino fisicamente su 2 switch distinti e 
separati, e pertanto che le 2 dette subnet abbiano come unico tramite 
fisico la macchina IPCop.

Facce sape'!

Pietro Tamburrano ha scritto:
> [...]
> Scusate per il ritardo nella risposta ma sono due giorni che non ho
> avuto modo di accendere il computer.
> Lunedi sono riuscito a fare qualche prova con i seguenti risultati:
> 
> - le impostazioni di Firefox sull'utilizzo di un proxy o meno non
> cambiano il problema;
> - resolv.conf contiene l'indirizzo 192.168.0.1
> - qualcosa di interessante è venuto fuori con il comando route anche se
> non sono riuscito ad interpretare bene il risultato:
>   quando il client non riesce a collegarsi route restituisce:
> 
> Tabella di routing IP del kernel 
> 
> Destination Gateway Genmask Flags Metric Ref Use Iface 
> 
> 192.168.0.0 * 255.255.252.0 U 0 0 0 eth0 
> 
> link-local * 255.255.0.0 U 1000 0 0 eth0 
> 
> default 192.168.0.1 0.0.0.0 UG 100 0 0 eth0 
> 
> 
> Quando il problema scompare route restituisce:
> 
> Tabella di routing IP del kernel 
> 
> Destination Gateway Genmask Flags Metric Ref Use Iface 
> 
> 192.168.0.0 * 255.255.252.0 U 0 0 0 eth0 
> 
> link-local * 255.255.0.0 U 1000 0 0 eth0 
> 
> default ipcop.localdoma 0.0.0.0 UG 100 0 0 eth0 
> 
> Non sono riuscito a stabilire se il cambiamento avviene subito prima
> della risoluzione del problema (e quindi ne è la causa) o subito dopo (e
> quindi ne è l'effetto) anche se propendo per la seconda ipotesi.
> 
> Purtroppo non ho pensato a fare un nmap, lo farò la prossima volta.
> 
> 
>    
> 
> --
> La permanenza in lista LUGargano e` regolata dal rispetto degli altri e della Netiquette:
>             http://www.nic.it/NA/netiquette.txt
>