Newsgroup: it.comp.reti.ip-admin
Titolo: NAT e FTP

andare a caccia i porte strane.
Probabilmente pero' vale anche una di queste due condizioni:
- stai utilizzando un client FTP che ha il modo PASV impostato
- stai utilizzando un web browser (che usa PASV) per fare FTP 
Se ho ben capito, quello che dici tu non dovrebbe essere sufficiente, in quanto
il client FTP stabilisce si' una sessione collegandosi alla porta 21 del server
remoto, ma poi la usa solo per lo scambio dei comandi, mentre i dati seguono
un'altra strada che adesso vedremo.
Se dai un'occhiata al log dei comandi FTP che client (*non* in modo PASV) e
server si scambiano quando chiedi la lista della directory, noterai che a un
certo punto succede questo (le risposte del server sono indentate per
distinguerle meglio):
pwd
  257 "/packages/ibmpc/windowsnt" is current directory.
TYPE A
  200 Type set to A.
PORT 212,216,34,46,4,22
  200 PORT command successful.
LIST
  150 Opening ASCII mode data connection for /bin/ls.
  226 Transfer complete.
Con "PORT 212,216,34,46,4,22" il client sta dicendo al server:
"Sto ascoltando sulla mia porta TCP 1046 (4*256+22=1046) e il mio indirizzo IP
e' 212.216.34.46; stai pronto a collegarti li' e a mandarmi i dati che ti
chiedero'."
1046 e' un numero di porta piu' o meno casuale allocato al volo dal client FTP,
mentre 212.216.34.46 e' il vero indirizzo IP del client host cosi' come
rilevato dal client FTP che gira sul host stesso; il NAT non ha poteri di
interferenza (1).
Subito dopo il client chiede di mandare la lista della directory con LIST e il
server si connette immediatamente a 
212.216.34.46:1046
 e manda i dati richiesti
chiudendo poi la connessione.
Al posto del comando LIST ci poteva essere benissimo il comando RETR che serve
al client per farsi mandare un file, e il discorso sarebbe stato analogo.
E' chiaro che il comando LIST potra' dare il risultato sperato solo se il
server FTP puo' far arrivare dei segmenti TCP diretti alla porta 1046 inseriti
in pacchetti IP diretti all'indirizzo 212.216.34.46; finche' l'indirizzo
212.216.34.46 e' visibile da Internet tutto funziona bene (e' sufficiente che
in entrata passino i pacchetti IP diretti a 212.216.34.46 contenenti segmenti
TCP diretti alla porta 1046, quindi in particolare non e' necessario che ci sia
la "pingabilita'" a livello ICMP), ma se 212.216.34.46 fosse un indirizzo
privato tali pacchetti non arriverebbero nemmeno dalle parti del client ma si
perderebbero su qualche router a poca distanza dal server... il NAT non puo'
certo andare a recuperarli dall'altra parte del mondo!
Se invece il client FTP usa il modo PASV ecco che succede:
pwd
  257 "/packages/ibmpc/windowsnt" is current directory.
TYPE A
  200 Type set to A.
PASV
  227 Entering Passive Mode (193,63,255,4,179,246)
LIST
  150 Opening ASCII mode data connection for /bin/ls.
  226 Transfer complete.
Il comando PORT non viene usato dal client, il quale invece invia al server il
comando PASV che significa:
"Per cortesia dammi il numero di una porta TCP sulla quale ti metterai in
ascolto, cosicche' io possa collegarmici per recuperare i dati che mi manderai
su richiesta".
Il server risponde "227 Entering Passive Mode (193,63,255,4,179,246)" che
significa:
"Va bene, sto ascoltando sulla porta 46070 (256*179+246=46070) e, casomai te lo
fossi dimenticato, il mio indirizzo IP e' 193.63.255.4"
Poi il client invia il comando LIST e subito dopo si connette a
193.63.255.4:46070
; non appena il server si accorge della connessione, manda i
dati richiesti e poi la chiude.
Quindi in modo PASV le cose dovrebbero funzionare anche se l'indirizzo IP del
client e' privato e c'e' un NAT interposto.
(1) A meno che il NAT non vada a ficcare il naso nel contenuto dei segmenti TCP
che transitano e sia sufficientemente intelligente da seguire il filo della
negoziazione FTP, rilevando e sostituendo l'indirizzo IP nel comando PORT.  Ma
allora non e' piu' un semplice NAT: e' un rompiballe! :))
----------------------------------------------------------------------
Marco Coletti
Network Administrator, Webmaster, Computer Consultant
PGP public key:
http://keys.pgp.com:11371/pks/lookup?op=get&exact=on&search=0x96A79061
Fingerprint: 9F E5 80 61 F6 9F 05 2D  EA 53 6F 2D 82 8B C7 C2
----------------------------------------------------------------------

 NAT: e' un rompiballe! :)) 
L'IP masquerading di Linux fa tutto in automatico, e questo da piu' di
un anno! E non ha mai rotto le balle :-)
ciao
--
Dalla Silvestra Michele
Key fingerprint = 68 02 A9 C7 FB 05 9E 9C  C7 B6 4A 13 61 25 5B 43

un anno! E non ha mai rotto le balle :-)
Stai dicendo che IPm cambia il contenuto del comando PORT, si' o no?
E' necessario il modo PASV sul FTP client, si' o no?


marco....@ZZZeurofin.it (Marco Coletti) writes:
   Sicuro?  Essendo terminologie nuove, non si sa mai cosa il produttore
   intende esattamente con NAT...
Il NAT e`  descritto in rfc 1631,  del maggio '94.  Non so  se i produttori
tipicamente  chiamano "NAT"  qualcosa  che  non lo  e`,  non conosco  molti
sistemi commerciali, ma comunque NAT dovrebbe essere una cosa ben precisa e
definita (dal suddetto rfc).
 
   >IP masquerading significa mascherare un qualsiasi pacchetto che
   >transita da una interfaccia di rete ad un'altra con l'IP della
   >macchina in locale.
 
   Dunque secondo quello che dici IPm non modifica il payload dei
   pacchetti IP.
Lo cambia, perche` gioca con i numeri delle porte dei protocolli sopra IP.
 
   >NAT fa solo una conversione degli IP dei pacchetti in transito secondo
   >certe regole, ma se hai un solo IP disponibile per il collegamento
   >PPP, puoi servire una sola macchina della lan interna (che sara'
   >questa a sua volta a fornire accesso alle altre). Finisci per fare la
 
   Non e' vero e ti smentisco facilmente.
Giusto, non e`  vero.  Il numero di IP disponibili  ti dice quante macchine
interne puoi  avere che parlano contemporaneamente con  l'esterno.  Mi pare
che la differenza essenziale fra NAT e  IPm e` che con IPm puoi far parlere
piu`  di una  macchina interna  che  parla all'esetrno  attraverso un  solo
gateway  con  un solo  IP  esterno.  In  compenso,  pero`,  credo sia  meno
generale.    In  pratica,   credo  sia   piu`  elastico,   con   le  dovute
configurazioni.  La documentazione per partire sta in un mini howto.
   lo chiamano) negli ultimi aggiornamenti del software; e' spiegato
   chiaramente nel manuale che con un solo indirizzo IP pubblico a
   disposizione si puo' fornire accesso trasparente a Internet a tutte le
   macchine della LAN locale.
Contemporaneamente?

 E' necessario il modo PASV sul FTP client, si' o no?
Mettilo o no, funziona comunque.


Contemporaneamente?
Non ricordo se c'e' scritto "contemporaneamente", ma io ho inteso in
questo senso.
Del resto, non vedo la difficolta', dato che e' sufficiente che il NAT
mantenga e aggiorni una tabella che contiene le porte sorgente dei
segmenti TCP o datagrammi UDP che provengono dagli host interni; per
decidere a quale host interno va diretto un pacchetto IP proveniente
dall'esterno (mediante opportuna "traslazione" dell'indirizzo IP)
basta che il NAT esamini la porta TCP/UDP contenuta nel
segmento/datagramma di cui il pacchetto IP trasporta una parte
(eventualmente tutto) e la compari con la tabella.  Il problema nasce
quando due o piu' host interni mandano segmenti/datagrammi originati
dallo stesso numero di porta: in tal caso il NAT dovrebbe anche
mettersi a manipolare i numeri delle porte sorgente prima di inoltrare
i segmenti/datagrammi all'esterno; secondo quanto hai detto, in questo
modo diventerebbe probabilmente simile a un IPmasquerading.


da clienti della ditta dove lavoro non hanno certo "brillato".
Secondo me e' perche la gente non sa configurarli, dato che ci capisce
poco e ha ancor meno voglia di leggersi con calma il manuale; io
personalmente ne ho installati 2 (3Com) e, una volta capite certe
idiosincrasie, funzionano benone.
Ho visto router dial-on-demand installati da sedicenti ditte esperte
di networking che non andavano oppure, a piacere, creavano bollette da
due milioni per conto loro...


