Newsgroup: it.comp.reti.locali
Titolo: funzionamento NAT

Una domanda sul NAT.
Ipotizzo il seguente scenario: ho una LAN con 3 PC, uno è il gateway che
permette la condivisione della connessione a Internet agli altri 2; gli ip
(del tutto inventati) dei 3 PC sono:
PC1 (gateway) 212.231.13.122(lato  internet) e 192.168.0.1 (lato rete
privata)
PC2 192.168.0.2
PC3 192.168.0.3
Ora, se PC2 richede una pagina web al sito 
www.pippo.it
 , per quello che ho
capito, manda la richiesta al gateway, il quale cambia IP del mittente
sostituendolo con il suo pubblico, ossia con 212.231.13.122, e poi inoltra
la richiesta .
Ora, se contemporaneamente, o quasi, anche PC3 richiede una pagina web ad
un'altro sito, ad es, 
www.pluto.it
  la storiella si ripete analogamente a
quanto visto per PC2.
La domanda è questa: Come fa il il NAT del gateway a tenere traccia che la
prima richiesta è stata fatta da PC2 e la seconda da PC3 visto che i
pacchetti di risposta dai siti hanno lo stesso IP di destinazione (quello
del gateway)?
Entra in gioco in qualche modo il protocollo ARP?
Scusate per la prolissità ma stò cominciando ora a studiare  le reti.
byeee

 La domanda è questa: Come fa il il NAT del gateway a tenere traccia
che la
gioca con le porte ;)

 del gateway)?
è un po' troppo lunga da spiegare, ma non preoccuparti, funziona anche se tu
non sai come!
:)
Esempio Pratico
PC A Gateway
PC B Client
PC C Client
Ogni volta che PC B (es dalla porta 4000) effettua una richiesta a PC A,
questo, applicando il NAT, non fà altro che modificare le intestazioni dei
pacchetti, mettendo l'IP pubblico di PC A e una porta generata dallo
stesso(es 1510), e incastonando nel pacchetto in partenza anche l'IP di PC B
e la sua porta(es 4000).
Il PC A crea una tabella, nella quale mantiene traccia delle connessioni
ancora aperte e in attesa di risposta da parte della LAN. Questa tabella è
ordinata per numero di porta, quindi quando gli torna il pacchetto dalla WAN
sulla porta 1510(nell'esempio), sà che il dato è destinato alla LAN, e per
sapere a chi e su che porta gli basta aprire il pacchetto e rileggere l'IP e
la porta che aveva inserito lui stesso(IP PC B e porta 4000). Ora capisci
che,se il PC B e il PC C effettuano una richiesta alla porta 80 dell'IP
212.65.78.21, il PC A segna 2 porte diverse di uscita nella propria tabella
degli instradamenti, e, per quanto ti ho detto prima, quando i dati tornano
non si crea alcun conflitto.
Scusami per le imprecisioni e se non sono stato molto chiaro, ma è un
periodo un po' impegnativo per me. Se hai bisogno di ulteriori
delucidazioni...sono qui!
Per Info leggiti anche le RFC 1631 e 2663.
Mip

 ha scritto nel messaggio
news:UZS1a.161902$0v.45...@news1.tin.it...


 un server ftp quindi deve essere raggiungibile dall'esterno, nella
questa e' un'altra cosa e non e' detto tu possa farlo; controlla la
funzionalita' di PAT (port addr trans) del tuo router

 ha scritto nel messaggio
news:b2dlmd$1c5it2$1...@ID-65620.news.dfncis.de...


 e la sua porta(es 4000).
Sei certo che il NAT invi al server anche IP privato del PCB? secondo me è
superfluo sarebbe sufficiente inviare IP pubblico del gateway (ovviamente) e
la porta dove il PCB invia la richiesta al gateway (porta 4000).
Do you agree?
bye


Uhmmm....non funziona proprio così....nella tabella di natting che viene
creata dal router (o chi per lui), viene effettivamente tenuta traccia delle
connessioni da e verso la lan, sfruttando appunto quello che viene definito
appunto PAT, però nell'header del pacchetto viaggia anche l'IP privato
sorgente, mascherato ma c'è, te lo assicuro. L'IP privato viene mascherato
nel checksum. Ti spiego meglio: oltre a cambiare
l'indirizzo IP nell'header del paccheto, il nat aggiunge la differenza
aritmetica fra l'IP privato e quello pubblico al checksum, in modo tale che,
quando riceve il pacchetto dal server designato, ricava il checksum ed
esegue le operazioni inverse di prima, ricavando così l'IP privato di
destinazione. C'è un problemino se la differenza o la somma creano un
under/over-flow, ma viene risolto semplicemente sommando o sottraendo "1" al
numero ottenuto, ottenendo così il complemento a 1 dell'indirizzo.
Tutto questo è vero per il TCP, per l'ICMP, FTP ed altri protocolli dovresti
fare delle aggiunte.
Lo ripeto: 
http://www.faqs.org/rfcs/rfc1631.html
li trovi tutto....

 mascherato nel checksum. Ti spiego meglio: oltre a cambiare l'indirizzo
Non capisco molto bene che intendi dire. Se lasci intendere (come capisco
io) che all'interno degli header del pacchetto viaggi in qualche modo
l'ip sorgente originale, beh, non č assolutamente vero...
Byez...
-- 
Emanuele Balla aka Skull
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)

Oltre a quello avevo anche scritto: "Lo ripeto:
http://www.faqs.org/rfcs/rfc1631.html
 li trovi tutto...."
Più autorevole di quella fonte non mi sembra ne esistano...dacci
un'occhiata.

 di quella fonte non mi sembra ne esistano...dacci un'occhiata.
Sono d'accordo, e quell'rfc la conosco ormai piuttosto bene ;-)
Analizziamo il passo incriminato:
   In addition to modifying the IP address, NAT must modify the IP
   checksum and the TCP checksum. Remember, TCP's checksum also covers a
   pseudo header which contains the source and destination address. NAT
   must also look out for ICMP and FTP and modify the places where the IP
   address appears. There are undoubtedly other places, where
   modifications must be done. Hopefully, most such applications will be
   discovered during experimentation with NAT.
Quello a cui ci si riferisce è il checksum calcolato sugli header del
pacchetto in transito, qui indicato come "header checksum":
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prendiamo il caso di uno SNAT.
Il router che opera il "mascheramento", si occupa di cambiare il
contenuto del campo "source address", sostituendolo con il suo (o quello
che ci deve mettere...).
Dato che il checksum prende dentro tutto l'header, anche il checksum deve
essere alterato per divenire conforma alle variazioni effettuate
sull'header.
Onde evitare di dover ricalcolare nuovamente tutto il checksum, il router
ha possibilità di confrontare solamente l'indirizzo vecchio con quello
nuovo, e desumere dalla differenza dei due quale deve essere la modifica
da effettuare sulla vecchia checksum, sottoforma di maschera di bit, 
il che è molto più veloce. Ovviamente l'applicazione di una maschera che
è bit per bit non tiene conto di 
Al layer superiore (TCP, UDP e ICMP), tuttavia, gli header del layer 4
considerano, nel calcolo della *loro* checksum anche uno pseudo-header
del layer 3, per questioni di "robustezza di protocollo ( e con buona
pace della separazione ISO/OSI...). In particolare l'header di tcp è
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ovviamente notasi che non è compreso l'indirizzo sorgente nè quello
destinazione (che appartengono al layer ip).
Tuttavia se cerchiamo come è definito quel campo checksum (rfc 793) 
abbiamo che (da rfc 793):
  Checksum:  16 bits
    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    transmitted as part of the segment.  While computing the checksum,
    the checksum field itself is replaced with zeros.
    The checksum also covers a 96 bit pseudo header conceptually
    prefixed to the TCP header.  This pseudo header contains the Source
    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    calls by the TCP on the IP.
                     +--------+--------+--------+--------+
                     |           Source Address          |
                     +--------+--------+--------+--------+
                     |         Destination Address       |
                     +--------+--------+--------+--------+
                     |  zero  |  PTCL  |    TCP Length   |
                     +--------+--------+--------+--------+
      The TCP Length is the TCP header length plus the data length in
      octets (this is not an explicitly transmitted quantity, but is
      computed), and it does not count the 12 octets of the pseudo
      header.
Il che significa che, nel momento in cui ci limitassimo ad adattare il
checksum dell'header ip, avremmo come risultato una corruzione
dell'header tcp soprastante. Ragion per cui, è necessario applicare le
stesse modifiche modifiche anche all'header di layer 4 (nel caso poi
dell'icmp anche qualcosa di più, ma qui andiamo OT e converrebbe
piuttosto leggersi le specifiche dell'icmp, rfc 792 ).
Ovviamente, il router che effettua il nat mantiene internamente una
tabella in cui va a mantenere traccia di quanto nattato, in modo da poter
operare correttamente quando vede passare pachetti appartenenti "allo
stesso traffico" per così dire (dato che non possiamo parlare di
sessione).
A meno di una implementazione del nat bacata, non è pertanto possibile
desumere l'ip di una macchina nattata partendo dal solo contenuto dei
layer 3 e 4. E' invece possibile farlo a layer 5 e superiori (ad esempio
il protocollo smtp si presta particolarmente bene... ).
In alcuni casi, poi, è possibile desumere il numero di macchine nattate
da un gateway basandosi su alcuni fattori (interessante potrebbe essere
una lettura di 
http://www.research.att.com/~smb/papers/fnat.pdf
 ,
recentemente segnalato su 
sikurezza.org
 e che ha generato un discreto
thread).
Se poi hai ulteriori informazioni riguardo a questo topic (ovvero la
possibilità di desumere l'ip originale sulla base del contenuto degli
header) manda pure che è argomento interessantissimo...
Byez


"Skull" ha scritto....
[sniiiiiiiiiiiiiip]
Perdona la mia ottusità, avevo interpretato male la rfc (anche se, a dir la
verità, ho sempre avuto quel dubbio, infatti il checksum DEVE cambiare nella
risposta per conformarsi al pacchetto, e così facendo si perderebbe la
corrispondenza!).
Dovrei rivedere un attimino il mio inglese!
A questo punto, ne desumo che viene tutto realizzato tramite la tabella di
natting del router e il PAT, o sbaglio?
Mip

 PAT, o sbaglio? Mip
Yesss...
Inoltre la maggir parte delle implementazioni si occupa anche di cambiare
alcune cose all'interno del payload per alcuni protocolli,ad esempio l'ip
che passa (in ascii) il comando port di una sessione ftp, altrimenti
alcuni protocolli non possono funzionare attraverso nat...
Come d'altra parte è accennato all'interno della stessa rfc...
Se usi linux e netfilter, questa è la parte in cui servono gli helper di
netfilter, tipo ip_nat_ftp e simili.
Byez...
