Newsgroup: it.comp.os.linux.sys
Titolo: NAT ANCORA NON VA

Ritorno, scusandomi con i partecipant al forum con il mio problema di NAT
per evitare casini vari e per testare il funzionamento di questa NAT ho
fatto la configurazione seguente
Una linux box con 2 schede di rete eth0 ed eth1 e sono rispettivamente
indirizzate come:
eth0 192.168.1.1
eth1 10.2.4.126
ho fatto l'instradamento con il comando:
route add -net 10.2.4.0 netmask 255.255.255.0 gw 10.2.4.126
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1
poi o collegato 1 pc su eth0 con IP 192.168.1.3 e 1 pc collegato si eth1 con
IP 10.2.4.5
essendo una simulazione di quella che poi sara la realta, vorrei, mediant e
la NAT che il PC 192.168.1.3 diventasse in uscita 10.2.4.3 e ovviamnte il
traffico di ritorno dal pc 10.2.4.5 arrivi al "reale" 192.168.1.3
e questo il lavoro della NAT no???
Ho letto tutta la documentazione possibile e immaginabile nonché how-to in
italiano segnalatomi da un gentile frequentatore di questo Newsgroup.
per vedere come vanno le cose ho messo uno sniffer sulla macchina 10.2.4.5
ed effettivamente la traslazione dell'indirizzo viene fatta, ovvero se la
macchina 192.168.1.3 manda un ping verso la 10.2.4.5 lo sniffer mi dice che
c'e stato echo-request da parte della 10.2.4.3 (che e la 192.168.1.3
traslata); quindi in una direzione sembra che funzioni.
Il problema sembra esistere nella direzione inversa, ovveroquando la
macchine 10.2.4.5 deve rispondere con un echo-response alla macchina
10.2.4.3 (che e la 192.168.1.3  traslata).
Le regole date nella catena di POSTROUTING é la seguente:
iptables -t nat -A POSTROUTING -s 192.168.1.3 -o eth1 -j SNAT --to 10.2.4.3
quindi come verificato, dopo essere instradato,( e quindi gia arrivato su
eth1) il pacchetto subbisce l'alterazione del sorgente in 10.2.4.3
Le regola del PREROUTING é la seguente:
iptables -t nat -A PREROUTING -d 10.2.4.3 -i eth1 -j DNAT --to 192.168.1.3
quindi (come NON verificato) quando un pacchetto arriva su eth1 e la sua
destinazione é 10.2.4.3 dovrebbe alteranne l'indirizzo di destinazione e poi
fare il routing. Si chiama PREROUTING apposta no??!!
In precedenza ho sempre fatto le prove con il ping, ma poi ho pensato che il
sistema non funzionasse con ICMP.
ho provato con telnet, ftp, netmeeting .... come ne esco???
spero questa volta di essere stato esaustivo nel presentare la panoramica
del problema.

 del problema.
Prima vediamo cosa da' "route -na" e "ifconfig -a", senza i comandi route,
iptables che hai eventualmente dato dopo, poi si puo' discutere del resto...
;-)
bye G.L.
--
La logica non attiene alla verosimiglianza delle ipotesi,
ma alla coerenza delle tesi con le ipotesi.

> iptables -t nat -A PREROUTING -d 10.2.4.3 -i eth1 -j DNAT --to 192.168.1.3
Scusa ma quando fai un NAT non dovresti dirgli anche qual'e' la porta in
questione?
Prova cosi' che a me funziona:
iptables -A PREROUTING -t nat -p tcp -d 10.2.4.3 --dport <porta da
nattare> -j DNAT --to 
192.168.1.3
:<Porta da nattare>
Ciao!

 questione?
Non e' obbligatorio: se non specifichi la porta, "natta" tutto alterando gli
indirizzi ma non le porte.



Ho toppato!
Solo che io lo ho sempre usato così xkè quando faccio un lavoro del genere
so a priori quali porte voglio nattare e le altre le chiudo.
Chiedo scusa per il consiglio sbagliato.

Davide D'Amico wrote:

Macche' scuse!  :-) Anch'io giustamente lo uso specificando le porte sorgenti
e destinazione. Altrimenti crei un colabrodo, altro che NAT.. ;-)
byeG.L.


 gestito dal connection tracking.
... di questo ne avevo sentito la puzza :-)
Spero che queste informazioni ti possono illuminare per aiutarmi :-)
Ciao grazie

 -----
Qui c'e' qualcosa che non va, se "U" sta per "up", e "G" sta per "use gateway",
e tra l'altro non compare il tuo vero gateway 10.2.4.3. La tabella e' IMHO
sballata... A che serve una route del genere verso se stesso come gateway (flag
"G"), per eth0 e eth1? E' invece corretta una cosa del genere:
192.168.0.0  0.0.0.0  255.255.255.0  U   0   0   0 eth0
10.2.4.0     0.0.0.0  255.255.255.0  U   0   0   0 eth1
127.0.0.0    0.0.0.0  255.0.0.0      U   0   0   0 lo
0.0.0.0      10.2.4.3 0.0.0.0        UG  0   0   0 eth0
L'ultima riga sarebbe il tuo router.
Ti ho chiesto di darmi queste informazioni, e *complete*, *SENZA* aver dato
quegli IMHO INUTILI COMANDI route!  Non ci siamo proprio...   :-(


 quegli IMHO
specifica cos'e' IMHO perche' con ti capisco (sono nuovo del Newsgruop)


 specifica cos'e' IMHO perche' con ti capisco (sono nuovo del Newsgruop)
In My Humble Opinion: secondo il mio modesto parere.


Bogo wrote:
Un'altra considerazione (se finalmente fossi riuscito a capire cio' che diavolo
vuoi fare): se vuoi semplicemente effettuare una connessione fra lan e dmz, il
NAT e' semplicemente inutile. Una volta abilitato il forwarding (echo "1" >
/proc.../ip_forward), puoi contattare l'host in dmz 192.168.0.x dai client senza
nessuna configurazione particolare su linux, a parte specificare sui client che
il gateway e' la tua linux box 10.2.4.126 (L'hai comunque fatto, vero?)
Oppure, per evitare casini se hanno un altro gateway, specie se sono windows,
dirgli che la route per 
192.168.0.0/24
 e' 10.2.4.126... con un apposito comando
route sul client.
Se invece la tua linux box fa da firewall/NAT per un'altra rete remota (o
internet) attraverso un router, allora si' che e' opportuno impostare un NAT.


 ha scritto nel messaggio
news:3D495885...@tiscalinet.it...

FUNZIONAAAAAAA !!!!!
 non avevo dato Alias al'interfaccia eth0 !!!!!
scusami, io ero STRACONVINTO   che la riconversione dell'indirizzo da quello
nettato a quello privato lo facesse direttamente la NAT!!
e invece manco pe' niente !!!
Quindi in generale, se io voglio nettare X indirizzi IP devo dare X alias
sull'interfaccia di uscita! e giusto ???
Ma suglio How-to c'e scritto o mi e sfuggioto??? verifichero'!
CMQ ho spento la macchina, l'ho riavviata e ha preso i paramentri di default
per la route che erano quelle che dicevi tu, ho aggiunto l'ulteriore
instradamento e PUFF e andato !!
Domani provero sulla vera rete, ma credo non ci siano problemi!
ti faro' sapere
GRAZIE 1*10^ 900000

 sull'interfaccia di uscita! e giusto ???
Non e' detto, ed e' per quello che IMO manca negli howto: se tu avessi un router
verso una rete remota, e lo istruissi dicendogli che la route per il singolo
indirizzo 10.2.4.3 e' 10.2.4.126, potrebbe non essere necessario (non ho
comunque provato, ma sono abbastanza sicuro dato che ho visto il comportamento
con un router cisco a cui era rimasta una entry arp in cache dopo che avevo
buttato giu' un alias sulla if pubblica per un server in dmz... questo veniva
contattato ugualmente dall'esterno per un po', fino alla scadenza della entry).
Questo perche', in tal modo, il router dirige comunque il pacchetto destinato a
10.2.4.3 alla linux box 10.2.4.126, e la linux box se lo "pappa" lo stesso e lo
"dnatta"   ;-).
Sempre per la logica che sta dietro... arp, se non esiste la precedente route
definita sul router (metti che non ci puoi mettere le mani, come su quelli dati
in comodato con il contratto di accesso...), la linux box si manifesta comunque
essere... "arpisticamente" 10.2.4.3, oltre che 10.2.4.126, e quindi no
problem...  :-)


 E tra me ed ngi ci sono almeno tre nat.
Il dubbio su un ip aggiuntivo configurato in aliasing e dnattato sulla dmz: ti
risponde la linux box oppure l'host sulla dmz? Io sul momento non lo so perche' non
ho verificato...


 ho verificato...
Verificato adesso adesso tramite tcpdump lanciato sull'host in dmz: al ping risponde il
firewall, l'host non riceve nulla...


 al ping risponde il firewall, l'host non riceve nulla...
Sarebbe adesso interessante fare una prova di DNAT dei pacchetti icmp echo... suppongo che
cosi' vada. Ma non ho ne tempo ne voglia, solo tanto sonno...
Buonanotte....   :-)


 problem...  :-)
Infatti, ecco perche dicevo che il pacchetto all'uscita veniva SNATttato,
pero poi non ritornava indietro perche mancava quel maledetto alias sulla
eth1
.. a saperlo !
cmq se gradisci (prossimamente) ti mando per posta uno schema della rete
anche per capire meglio il tutto.
Il casino é nato perché voevo proteggere la mia rete da quella alla quale
sono collegato con il router.
adesso che tutto va' posso iniziare ad implementare le regole del firewall.
Ma questo dopo le vacanze :-)
Saluti