Newsgroup: it.comp.reti.locali
Titolo: NAT, problemino (lunghetto)

Vorrei dei consigli su come (se possibile) risolvere il seguente
problema.
3 reti di pc:
Rete A
indirizzi statici su internet
Rete B
Indirizzi privati LAN
Rete C
Indirizzi privati LAN
La rete A e B sono collegate tra loro tramite un router che chiamiamo
pippo (che ovviamente ha un indirizzo ip sia nella classe della rete A
che in quella della rete B). Il collegamento è permanente.
Lo stesso router permette  tramite un collegamento ppp on demand di
raggiungere la rete C (anche qui ci sarà un router, ma a ns fini non
ci interessa).
Sulla rete C c'e' un server che fornisce un servizio necessario ai
client che girano sulle reti A e B.
Pippo (il router) inoltra le richieste della rete A senza operare
mascheramento NAT e quelle della rete B operando il NAT (ossia mette
il suo IP pubblico).
Il server (della rete C) gestisce gli accessi in base alla terna A:B:C
dove A=utenza_di_accesso+passwd, B=Ip_di_provenienza,
C=Porta_di_provenienza.
Dato che A e C sono uguali per tutti i client, rimane solo B che
permette di distiguere se l'accesso arriva da una macchina diversa (e
quindi va aperta una nuova sessione) o da una macchina già
precedentemente loggata.
Nelle richieste che passano via NAT, A e B sono sempre uguali ed è
invece C che cambia e differenzia le varie richieste.
Bene il problema è che il collegamento tra pippo e la rete C non è
sempre attivo, ma quando inutilizzato per tot minuti viene chiuso.
E cosa succede quando cio' avviene:
Rete A (uno dei pc):
Il client non aveva mandato il comando di chiusura sessione e quindi
sul server rimane aperta la sua sessione.
Quando il client cercherà di operare di nuovo, Pippo reinstaurerà la
connessione con la rete C ed il client comunicherà con il server.
Il server vedendo che la richiesta arriva da una terna A:B:C  di cui
esiste già una sessione aperta, riutilizzerà quest'ultima e tutto fila
liscio.
Rete B (uno dei pc):
Il client non aveva mandato il comando di chiusura sessione e quindi
sul server rimane aperta la sua sessione.
Quando il client cercherà di operare di nuovo, Pippo reinstaurerà la
connessione con la rete C ed il client comunicherà con il server.
Il server vede ora una terna A:B:C diversa da quelle già loggate
(perchè il NAT ogni volta invierà un porta diversa presa a caso tra
quelle riservate per il nat).
Quindi apre una nuova sessione, la sessione precedente diverrà una
sessione morta che non viene utilizzata + da nessuno.
Il difetto si presenta anche senza che la connessione tra Pippo e Rete
C sia stata chiusa.
Se si killa brutalmente un client (quindi senza permettere a
quest'ultimo di inviare il comando di chiusura sessione) e poi lo si
riapre subito si ottiene che sul server si apre una nuova sessione
(perchè anche in questo caso il NAT invia un nuovo numero di porta).
Risultato dopo un po' che le macchine della rete B stanno operando
finisce che le licenze (sessioni contemporanee) disponibili sul server
sono esarite senza giusta causa.
E per risolvere il problema bisogna killare a mano le sessioni morte
(che oltretutto è difficile capire quali sono, e si rischia di killare
una di quelle buone), al fine di liberare licenze.
Come risolvere la cosa?
A me la prima cosa che viene in mente è dire a Pippo di non operare il
NAT per la rete B (tanto il collegamento con la rete C non è via
internet). In questo modo funzionerebbe come per la rete A ed il
problema sarebbe risolto.
Ma cosi' nascono altre due possibili situazioni non gradite:
a) La rete C è gestita da altri, ed i gestori della rete B
preferirebbero non fare sapere quali sono gli ip della rete B che si
collegano.
b) Anche se attualmente non ci sono, c'e' sempre il rischio di
confilitti di indirizzi ip.
Se alla rete B (o C) venissero aggiunte delle macchine con un ip
privato già usato sull'altra rete, ci sarebbero conflitti nel caso di
accesso contemporaneo.
Dato che le due reti sono gestite da entità diversa, la cosa potrebbe
pure accadere.
Quindi l'ideale sarebbe una soluzione che mantenga il mascheramento
NAT.
E' possibile?
Ciao.
Fabrizio

 ha scritto nel messaggio
news:osrfqsco9osc3tv0r...@4ax.com...


non è il PAT ke trasla le porte?
Si il PAT traduce le porte e serve quando vuoi che qualcosa
indirizzato verso una porta sia dirottato verso un'altra.
Mentre il NAT traduce gli indirizzi ma per fare questo deve usare
(temporaneamente) porte diverse.
Un articolo ben fatto sul NAT lo si puo' leggere nel post di Midori.
Cercate con 
www.deja.com
 il post "Come funziona il NAT" fatto il 4
agosto su it.comp.os.linux.sys
Riassumo con un esempio (che si rifa al mio problema, tutti i valori
sono inventati):
192.168.2.34
192.168.2.35
192.168.2.36
sono i client sulla rete B
200.200.12.22 
è il router. Questo è l'ip pubblico su internet, ovviamente ha un ip
anche privato (se no i client non lo vedrebbero), diciamo
192.168.2.235. Comunque ai ns fini serve solo l'ip pubblico.
192.168.45.100
è il server sulla rete C
2004 è la porta sorgente usata dal sw client
3004 è la porta destinazione da raggiungere sul server.
34000 - 37000 è il range di porte utilizzate dal router per fare la
NAT.
Ora che succede quando i client comunicano con il server:
1) Senza NAT (cosa possibile solo grazie al fatto che il collegamento
è diretto e non via internet)
192.168.2.35:2004
 si collega a 
192.168.45.100:3004
Dato che il router non fa la NAT il server vede giungere la richiesta
direttamente da 
192.168.2.35:2004
 ed inoltra a tale indirizzo le sue
risposte.
Se dovesse cadere il collegamento, al successivo collegamento sarebbe
sempre 
192.168.2.35:2004
 l'indirizzo visto dal server e quindi
verrebbe riciclata la sessione precedentemente aperta e non chiusa.
Se si collegano + client contemporaneamente, semplicemente il server
vede giungere sulla sua porta + richieste dalla stessa porta di IP
diversi.
192.168.2.34:2004
 si collega a 
192.168.45.100:3004
192.168.2.35:2004
 si collega a 
192.168.45.100:3004
192.168.2.36:2004
 si collega a 
192.168.45.100:3004
2) Con la NAT attiva.
192.168.2.35:2004
 si collega a 
192.168.45.100:3004
Dato che il router  fa la NAT il server vede giungere la richiesta
come proveniente dal router con una porta presa dal range a
disposizione della nat (ossia ad esempio 
200.200.12.22:34044
)
Il server quindi risponde all'indirizzo 
200.200.12.22:34044
 ed il
router (grazie ad una tavola di mappatura che  si crea all'atto della
nat) sa che che tutto quello che arriva sulla sua porta 34044 va
dirottato su 
192.168.2.35:2204
.
La comunicazione fila liscia ma in realtà il server crede di
comunicare con un client che sta all'indirizzo 
200.200.12.22:34044
Se si collegano + client contemporaneamente, semplicemente il server
vede giungere sulla sua porta + richieste dallo stesso ip MA con porte
diverse.
192.168.2.34:2004
 si collega a 
192.168.45.100:3004
 e per il server
diventa 
200.200.12.22:34067
 che si collega a 
192.168.45.100:3004
192.168.2.35:2004
 si collega a 
192.168.45.100:3004
 e per il server
diventa 
200.200.12.22:34079
 che si collega a 
192.168.45.100:3004
192.168.2.35:2004
 si collega a 
192.168.45.100:3004
 e per il server
diventa 
200.200.12.22:34098
 che si collega a 
192.168.45.100:3004
E fin qui sarebbe tutto OK, i problemi si hanno quando la
comunicazione viene chiusa (ad esempio per timeout) senza che il sw
client abbia mandato l'ordine di disconnessione del client dal server.
Ossia facciamo l'esempio:
192.168.2.34:2004
 si collega a 
192.168.45.100:3004
 e per il server
diventa 
200.200.12.22:34067
 che si collega a 
192.168.45.100:3004
comunicano per un po' e tutto va ok.
Poi l'operatore che usava il sw client decide di bersi un caffè e
lascia in pausa il tutto.
Il router dopo un po' taglia la comunicazione (per contenere i costi),
ma sul server rimane aperta la sessione a nome 
200.200.12.22:34067
perchè non è arrivato il comando esplicito di chiusura (l'operatore è
andato in pausa mica ha terminato il lavoro).
L'operatore bevuto il suo caffè riprende il lavoro, 
192.168.2.34:2004
si ricollega a 
192.168.45.100:3004
. Il router ristabilisce la
connessione fisica e fa una nuova Nat.
A meno di culo mostrouso o settaggi particolari (che poi sono quelli
che io vorrei sapere se si possono fare) sicuramente la porta usata
dal nat non sarà + quella di prima.
Quindi ora 
192.168.2.34:2004
 che si collega a 
192.168.45.100:3004
 per
il server diventa 
200.200.12.22:34178
 che si collega a
192.168.45.100:3004
.
Il server non riesce a capire che è sempre la stessa macchina che si è
ricollegata e quindi apre una nuova sessione a nome
200.200.12.22:34178
 e la precedente sessione 
200.200.12.22:34067
diventa una sessione morta che (sempre salvo fortuna, ossia riciclata
dal router per un altro client) non sarà + usata da nessuno.
Dopo un po' di questi giochetti non ci si riesce + a collegare a causa
dell'esaurimento delle licenze disponibili.
Magari sono collegati solo in 3 o 4 ma tutte le 50 licenze sono in uso
a causa di 40 e passa sessioni morte.
Spero di essere stato chiaro.
Ciao.
Fabrizio

 Indirizzi privati LAN
Ciao,
e molto coplesso ciň che fai, am a pensarci bene, il NATa che ti serve??
se vuoi che dall'interno si esca fuori , siamo d'accordo, am se devi solo
far veder eservizi alle due reti locali, il normlae rotuing ti pemrette di
farlo.
io ho una situazione simile alla tua:
A b c , come le tue, e c si connette con ppp.
Bene se dall ac voglio anare su internet, vengono con l loro ip fino a B,
dove c'č il route che fa da NAT verso A e quindi internet.

Grazie mille, credo ke dovresti creare delle mappature NAT STATICHE e non
dinamiche...io configuro i router Pocket Multicom, ho letto qualcosa
relativo a ciò sul manuale ma non ho mai approfondito, ti consiglio di
guardare in quella direzione, fammi sapere perkè è interessante!!!



Beh in effetti il NAT si potrebbe eliminare e la rete C non deve avere
accesso ad internet tramite la rete A.
Questo perchč la rete C č in una societą mentre le reti A e B sono in
una altra societą.
Siccome ci sono due amministratori di rete (ed io non sono nessuno dei
2) c'č il rischio che le rete B e C finiscano per avere prima o poi
indirizzi ip in comune (e che quindi collidano).
Ciao.

 Ciao.
Se A B e C devono giocare, facciano pure.
Se la situazione si eve risolvere, e bene, allora si usano  gli struemnti
adatti, DHCP,
per gli indirizzi.
Per la intercnnession si lascia com'è e il NAT si usa solo se da B o C si deve
andare fuori.Il tutto si può gestire con le giuste policy e se qualcuno non
deve uscire non esce.....

guardare in quella direzione, fammi sapere perkè è interessante!!!
Beh in effetti io ho semplificato la cosa ed il router pippo (del mio
esempio) è in realtà composto da 2 macchine.
1 server su cui è installato un firewall (firewall-1 della checkpoint)
ed a cui sono collegate le reti A e B.
Poi viene  il un router vero e proprio (ascend MAX).
E' il firewall che fa la NAT, il router si occupa solo di instradare
verso internet o verso le reti PPP.
Esaminando i menu di configurazione del firewall non abbiamo notato
niente che ci possa servire.
C'è una funzione che fa una NAT statica.
Una macchina della rete B puo' essere mappata su un indirizzo della
rete A (quella visibile su internet) virtuale.
Cioe' la macchina rimane fisicamente sulla rete B (e quindi con
indirizzo 192.168.x.x) ma il firewall crea una macchina virtuale sulla
rete A che la duplica e poi dirotta tutte le richieste di I/O che
arrivano sulla macchina virtuale esterna (cioe' con ip visibile in
internet) verso quella reale interna.
Questa cosa funziona (o almeno dovrebbe non l'abbiamo provata), ma
pero' c'e' il problema che gli IP disponibili nella rete A sono un
numero limitato e piccolo.
Quindi non si puo' mica rimappare ogni macchina della rete B in una
virtuale sulla rete A.
Dopotutto il NAT è nato proprio per permettere di condividere un IP
pubblico da + macchine.
Ciao.
Fabrizio

A proposito..com'è Firewall-1 di Checkpoint?
Mi sa ke tra un po' melo dovrò studiare....
--
CIAO!!!
Daniele-Sagnelli Sistemi
MEDA (MI)
ICQ: 21963839
.

 Mi sa ke tra un po' melo dovrò studiare....
Completo. E pesante.
Tuo
\/\/owbagger

Ciao ragazzi,
sono appena rientrato dalle ferie, quando il mio capo mi dice che
dovremo cambiare firewall e passare a quello della checkpoint.
Qualcuno di voi ha sottomano della documentazione (o dei link) da dove
poter iniziare per capirci qualcosa???
Grazie in anticipo a tutti.


 > \/\/owbagger
Il tuo capo ha capito tutto...qunado qualcosa non la si capisce--bisogna
farla fare a qualcun'altro che l'ha studiata..cosi vi ciula i soldini....

 farla fare a qualcun'altro che l'ha studiata..cosi vi ciula i soldini....
Grazie per la dritta :-) , ma oltre questo sapresti suggerirmi
qualcos'altro???
Ciao

TheFlyerŽ wrote:

Credo che chi arriva a comprare FW1 non possa chiedere altro.....ma prima di
spendere qeui soldi mi farei un'attimo di cultura..se te lo vengono ad
installare
avrai sempre un timore reverenziale verso un prodotto completo ma che poi devi
gestire con il telefono, ovvero devi chiamare sempre l'assistenza...
Meglio studiare ipcahins di linux, l'idea iniziale del NAT era la migliore.
Se non ti perdi d'animo puoi riuscirci....