[LUGargano] Problemone con squid (lungo).

Carmine Malice instarvega_capitanlug@yahoo.it
Ven 13 Feb 2009 10:30:15 CET


Pietro Tamburrano ha scritto:
> Il giorno gio, 12/02/2009 alle 10.08 +0100, Carmine Malice ha scritto:
>> 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.
> 
> Il subnet mask a 255.255.252.0 ha lo scopo di consentire l'utilizzo di
> oltre 254 macchine collegate all'interno della rete (ebbene si, nel
> nostro istituto ci sono pił di 254 macchine). Probabilmente si sarebbe
> potuto trovare una soluzione migliore ma la cosa fino ad ora ha
> funzionato.
> [...]

La precisazione conferma che ci si sta arrischiando.
Come detto in precedenza, in fondo si tratta solo di convenzioni ma su 
queste convenzioni si basa tutto il funzionamento del TCP/IP.
Le reti TCP/IP di classe C sono predestinate ad ospitare un massimo di 
254 nodi: e' previsto di *meno*, anche nel senso di limtazione logica 
(p.e. con maschera di rete 255.255.255.192), ma *non* di *piu'*.
In pratica, le reti di classe C vanno da 192.0.1.0 a 223.255.254.0 
secondo lo schema [rete].[rete].[rete].[nodo].
Nell'ambito della classe C, come per le altre classi, una serie di 
indirizzi sono stati riservati ad usi privati (ovvero per reti interne, 
LAN, e non per reti pubbliche ed esterne), in pratica secondo lo schema 
192.168.[reteinterna].[nodo] .
In definitiva, se un pacchetto in una rete deve raggiungere l'IPAddress 
192.168.x.y gli apparati di quella rete "convenzionalmente sanno" che 
dovranno rivolgersi esclusivamente ad uno di loro stessi e non chiedere 
a quello che e' il gateway di condurli "fuori" perche' nella "peggiore" 
delle ipotesi si deve fare un passaggio da una rete interna ad un'altra 
rete interna (da 192.168.[rete1].nodo a 192.168.[rete2].nodo).
Effettivamente, essendo in questo caso il terzo ottetto dell'IPAddress 
comunque riservato ad usi interni, per quanto limitatamente alla 
definizione di rete (interna), *in teoria* il privato se ne potrebbe 
"appropriare" per dedicarlo in tutto o in parte ai nodi: in una 
situazione estrema si potrebbe avere un router/gateway con IPAddress 
192.168.0.1/16 sul lato "interno" ed un indirizzo pubblico sul lato 
esterno ed esso che da solo instrada verso l'esterno una massa 
indistinta di nodi interni.
In pratica ci si ficcherebbe nel modello di una classe B o A.
Ma allora perche' non si e' usata una classe B o A se "ci sono pił di 
254 macchine"???
Si deve prestare attenzione a tutto questo perche' come regola generale, 
la quale assume valore sostanziale e supera il mero valore 
convenzionale, bisogna evitare di assegnare ai nodi o alle "sottoreti 
interne" gli IPAddress il cui valore potrebbe coincidere con quello 
della rete interna in quanto tale (p.e. 192.168.0.0/24) o quello del 
relativo broadcast (p.e. 192.168.255.255/24).
In breve: a prevaricare gli schemi si possono avere risultati imprevedibili.

Il fatto poi che 192.168.0.1 effettivamente corrisponda al nodo 
ipcop.localdomain ovvero al router non puo' portare all'affermazione 
"Cambia l'instradamento" proprio perche' c'e' coincidenza: piuttosto 
bisognerebbe capire come mai l'instradamento al default gateway si 
esprima a volte in nominativo e non in numerico, cosa sconcertante dato 
che stiamo ancora ad un livello dove bisogna affidarsi esclusivamente ai 
  valori numerici.
Puo' essere che un qualche automatismo di Ubuntu porti a quel risultato, 
puo' anche darsi che sia la conseguenza di una DNS cache sul router, 
infine potrebbe dipendere proprio dalla "prevaricazione" degli schemi di 
rete.

Il comportamento di Windows, cosi' com'e', non aiuta perche' Windows ha 
una massa di automatismi e preimpostazioni.

In ogni caso, ricorda che con IPCop e' fondamentale isolare sia 
fisicamente sia logicamente la LAN servita dal "resto del mondo".

Ciao!


Maggiori informazioni sulla lista LUGargano