Newsgroup: it.comp.os.linux.iniziare
Titolo: Differenze tra POSTROUTING E PREROUTING

ragazzi chi mi spiega brevemente con un esempio
la differenza tra POSTROUTING E PREROUTING?
Ho letto gli how-to ma non ci capisco una mazza?

 Ho letto gli how-to ma non ci capisco una mazza?
Lettura breve e non esaustiva, ma prova a dare una occhiata al mio sito,
in particolare gli ultimi due esempi su iptables...
Ciao...
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Skull says:
The old signature is gone...
Won't you suggest me a new one?!?

 altrimenti finisce dalla parte sbagliata), mentre in post fai SNAT...
Mi fai un piccolo esempio per favore...
cosě se capisco bene provo a fare delle prove.
Grazie skull.

 fare delle prove.
Visto che il mio sito proprio non lo vuoi vedere, cito me stesso e la
pagina cui mi riferivo... :-D 
ne traggo due estratti:
1) Attraversamento delle chain:
 Per capire il comportamento di iptables e il modo in cui le vostre regole
 dovranno essere costruite, è necessario per prima cosa capire quali sono
 le chain su cui dovrete agire e in quale ordine vengono attraversate.
 Evitiamo qui di prendere in considerazione attività di mangling e altro,
 ma ci limitiamo a parlare delle funzionalità di base, ovvero il
 filtering e il nat. Quando parleremo di "firewall", ci riferiremo alla
 macchina stessa su cui stiamo configurando iptables. Abbiamo 3 casi
 distinti da affrontare:
 
- Pacchetti originati dal firewall e diretti a qualcuno nel resto del mondo
 
- Pacchetti originati da qualcuno nel resto del mondo e diretti al firewall
 
- Pacchetti originati da qualcuno nel resto del mondo e diretti a qualcun
altro, ma che si trovano a passare per il firewall
 
E' evidente che l'ultimo caso vale solo se stiamo gestendo del routing.
 
 Rispettivamente, le chain di iptables attraversate saranno:
 
- OUTPUT -> POSTROUTING
 
- PREROUTING -> INPUT
 
- PREROUTING -> FORWARD -> POSTROUTING
 
Ognuna delle categorie citate prende in considerazione il traffico
"origine" e non quello di risposta, che sarà ad esso inverso, ovvero
l'inverso della 1 è la 2, l'inverso della 2 è la 1, l'inverso della 3 è
sempre la 3 (anche se le interfacce di ingresso e uscita saranno
ovviamente invertite).
 Questo è di per sè ovvio, ma risulterà importante quando avrete a che
 fare con la macchina di state e con il NAT.
 
 
 
                  ---- O ---- O ---- O ---- O
2) Esempi pratici
Ridirigere una porta su una macchina nella stessa rete del chiamante
 
Per quanto questa configurazione sia in sè abbastanza assurda, pare lì
fuori sia pieno di gente che la vuole.
 Immaginiamo questo caso: abbiamo un webserver che ospita dei virtualhost,
 e, poichè ci vogliamo del male, lo abbiamo messo nella nostra LAN
 anzichè in DMZ. Che accade? Che nel momento in cui cercate di
 raggiungere uno dei siti ivi ospitati, e interrogate un dns pubblico,
 questi risponde con l'ip pubblico del vostro webserver. Al che il vostro
 client, ringalluzzito, cerca di contattarlo ma non ce la fa. Perchè?
 Semplice, se pensate a quello che sta accadendo:
 
il client invia un SYN all'ip pubblico ottenuto via dns (non può sapere
che lo ha lì accanto sotto mentite spoglie)
 
il SYN cerca di uscire dal firewall, che, a seconda di come è configurato
(ovvero se fa -correttamente IMHO- o no un check sull'interfaccia da cui
il SYN lo ha ricevuto) lo DNATta oppure no. Se non lo DNATta, è chiaro
che non funziona nulla, poichè a rispondere a quell'indirizzo ip è il
firewall stesso. Se lo NATta, invia il pacchetto al webserver di
destinazione.
 
il webserver destinatario si vede arrivare 'sto benedetto SYN con mittente
una macchina interna. Risponde pertanto con un SYN/ACK direttamente ad
essa
 
il client, che ha inviato il SYN a un ip pubblico, vede arrivare il
SYN/ACK da un ip privato. Dato che non ha mai contattato quest'ultimo,
cestina il SYN/ACK e continua ad aspettare risposta dall'ip pubblico.
 
Le soluzioni sono almeno 3, in ordine di "correttezza":
 
Spostate quella macchina in DMZ
 
Usate un dns interno per risolvere i virtualhost con gli ip privati
 
Barbatruccate il firewall
 
Anche se è la via meno corretta, qui esamineremo come applicare la 3
(d'altra parte parliamo di iptables...).
 Il problema è dato dal fatto che il webserver risponde direttamente al
 client senza passare dal firewall. La soluzione è obbligarlo a passare
 dal firewall. Pertanto, per prima cosa applichiamo la regola di DNAT come
 al solito:
 
iptables -A PREROUTING -t nat -d $web_ext -p tcp --dport 80 -j DNAT
--to-destination $web_int
 A questo punto, provvediamo a far sì che quelle connessioni che ivi
 giungono proveniendo dall'interno vengano SNATtate per sembrare
 provenienti dal firewall:
 
iptables -A POSTROUTING -t nat -s $int_net -d $web_int -p tcp --dport 80
-j SNAT --to-source $fw
 In questo modo la macchina interna risponderà sempre al firewall,
 permettendo così a netfilter di "correggere" la sessione di ritorno.
Spero aiuti... 
