Newsgroup: it.comp.os.linux.sys
Titolo: chiarimento su iptables (teoria)

Ciao a tutti,
ho un firewall che deve indirizzare tutto il traffico proveninte
dall'interfaccia pubblica e destinato alla porta xx su un server interno
della DMZ.
Per fare questo questo ho usato la regola:
iptables -t nat -A PREROUTING -p tcp -d x.x.x.x --dport xx -j DNAT
--to-destination 10.0.0.2
Questa regola perň non vuol saperne di funzionare se prima non aggiungo:
iptables -t nat -A POSTROUTING -j MASQUERADE.
Perchč?
C'č un modo diverso per far funzionare il tutto?
Grazie.
Ciao Antonio
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 iptables -t nat -A POSTROUTING -j MASQUERADE.
Il motivo č che oltre a dnattare il traffico in ingresso devi snattare 
il traffico in uscita (ovvio, no?). Invece della MASQ, puoi usare un
iptables -t nat -A POSTROUTING -p tcp -s 10.0.0.2 --sport xx -j SNAT 
--to-source x.x.x.x
In ogni caso, verifica di avere il modulo ip_conntrack caricato, perchč 
il connection tracking se ne occupa da solo, senza bisogno di 
specificare nat per il traffico di ritorno.
Inoltre, considera che se non "masqueri" o almeno snatti il resto del 
traffico uscente dalla macchina su cui fai il redirect (magari decidendo 
_cosa_ far passare, che č meglio), non funzionano protocolli quali 
ident, dns ecc. che possono richiedere l'uscita di pacchetti dalla 
macchina nattata e che potrebbero essere necessari all'applicazione che 
risponde alla richiesta esterna del servizio.
Byez
-- 
Emanuele "SKULL" Balla
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)

 Byez
Grazie per la spiegazione.
Non mi ero accorto che dovevo "masquerare" il traffico appena uscito dalla
DMZ non solo quello uscente dall'interfaccia pubblica.
Comunque devo studiare ancora un po'!!!
Hai qualche libro fatto bene da consigliarmi?


 Hai qualche libro fatto bene da consigliarmi?
Senza spendere soldi:
http://netfilter.samba.org/documentation/index.html#HOWTO
Per i tutorials, poi, molto buono quello indicato come prima voce dei 
tutorials (appunto)
Come testi sulla teoria e la pratica del tcp/ip, direi che TCP/IP 
Illustrated di Stevens č la bibbia ( ma mi risulta ci sia solo di 
importazione americana e comunque costa una montagna di soldi: 113 EUR, se 
non mi han fregato...)
Byez...


C'è un modo diverso per far funzionare il tutto?
ma il gateway del server interno sulla DMZ e' impostato con l'indirizzo del
firewall?
--
   Paolo

specificare nat per il traffico di ritorno.
appunto, pero' e' necessario che il gateway sul server sia impostato con
l'indirizzo del firewall
--
   Paolo

 l'indirizzo del firewall
claro que si, ma se non lo fosse non funzionerebbe nemmeno con lo snat o 
il masquerade. Forse con il teletrasporto...
byez


    Paolo
No, è impostato con un gateway di default.
Adesso ho capito perchè non funzionava. Ora provo a modificare un po' di
impostazioni.
Grazie,


 impostazioni.
Rettifico. E' impostato sull'indirizzo del firewall.


 iptables -t nat -A POSTROUTING -j MASQUERADE.
Strano, non dovrebbe essere necessario: hai provato con --to 10.10.10.2:xx
(cioe' specificando anche la porta di destinazione) ?
bye G.L.
--
La logica non attiene alla verosimiglianza delle ipotesi,
ma alla coerenza delle tesi con le ipotesi.

 Rettifico. E' impostato sull'indirizzo del firewall.
vale a dire che il gateway di default del server e' impostato 
sull'indirizzo del firewall?
se e' cosi va bene.
-- 
    Paolo

 iptables -t nat -A POSTROUTING -j MASQUERADE.
Non puoi... in quanto le risposte a quella connessione hanno come ip quello
locale (10.0.0.2)... funzionerebbe soltanto se il cliet riuscisse a contattare
direttamente l'indirizzo locale o che la tavola di route sappia instradare i
pacchetti verso quell'indirizzo.
 
-- 
| /
| \Byte - Andrea Briganti - 
kbyt...@freemail.it
http://www.kbytesystem.fasturl.it
 ICQ: 40872731
*** Chi non ha rispetto non merita considerazione

 pacchetti verso quell'indirizzo.
???
Non capisco. Prima della decisione di routing (PREROUTING), l'indirizzo pubblico
di destinazione viene alterato in quello locale, conntrack fa poi il resto nel
gestire la connessione. Ma forse ho capito male quello che vuoi dire.


 C'č un modo diverso per far funzionare il tutto?
A pensarci bene, forse faresti meglio a postarci tutto l'output di
iptables-save. Le eventuali regole e la policy della catena forward sono
coinvolte...


 dire.
Il conntrack traccerebbe una connessione da xxx.xxx.xxx.xxx<->10.0.0.2
Ma l'indirizzo dei pacchetti da 10.0.0.2 non subiscono alcun source nat per cui
ad xxx.xxx.xxx.xxx arrivano pacchetti provenienti da 10.0.0.2 che ovviamente
non sa a chi e come instradare 


 
Onestamente non ti seguo: se il conntrack è caricato, all'atto del nat 
al SYN di inizio connessione, viene creata una entry nella tabella di 
state. Tutto il traffico che faccia parte di tale sessione subisce 
automaticamente la stessa sorte del pacchetto di inizio connessione. Per 
gli udp vale la stessa cosa (anche se lì la gestione dello stato è meno 
intuitiva...).
Per cui, non c'è nessuna necessità di specificare una regola di nat sul 
traffico di ritorno: ci pensa il conntrack. Casomai, se viene aperta una 
nuova sessione necessaria al server per le sue smazzate, questa non 
avrebbe un ip sorgente valido. Ecco perchè, per protocolli di questo 
tipo, esistono gli appositi helper (vedi ftp, tftp, h323, ecc...).
Con questi netfiler è in grado di seguire lo stato della sessione anche 
su altre porte e connessioni, oltre a quelle iniziali.
Va da sè che, come dicevo in post precedente, questo non ti ripara dal 
fatto che eventuali query dns o interrogazioni di qualsiasi tipo a 
server esterni non vengano snattate.
Byez...


non sa a chi e come instradare 
quando l'indirizzo x.x.x.x contatta il firewall, questi ridirige la
connessione verso il server (DNAT), per cui il server vede arrivare
pacchetti con source address  x.x.x.x
Se sul server il gateway di default e' impostato sul firewall, il server
invia la risposta al firewall, il quale, tenendo traccia delle connessioni,
ritorna a sua volta la risposta all'indirizzo x.x.x.x, ma con source
address uguale a quello del firewall.
--
   Paolo

traffico di ritorno: ci pensa il conntrack. Casomai, se viene aperta una 
infatti e' cosi, per questo dicevo che in generale basta utilizzare una
sola regola ipchains che fa il DNAT, se il resto della rete e' configurato
bene, (e bisogna anche vedere le regole di forward) funziona perfettamente.
--
   Paolo

PM wrote:



Sì, è così. Comunque devo sempre mascherare tutto il traffico che esce dal
server altrimenti la cosa non funziona pur avendo il modulo ip_conntrack
caricato. Invece mi è sembrato di capire che con tale modulo caricato la
regola sul traffico in uscita non dovrebbe servire. 
Sbaglio qualcosa? 
Grazie. 
Ciao Tony 


 Sbaglio qualcosa?
Dipende anche da protocolli che richiedono una gestione particolare del
tracking. Io ho attualmente questi moduli caricati:
ipt_state
ipt_MASQUERADE
ipt_TOS
iptable_mangle
iptable_filter
ip_nat_irc
ip_conntrack_irc
ip_nat_ftp
ip_conntrack_ftp
iptable_nat
ip_conntrack
ip_tables
iptable_mangle
Malfunzionamenti potrebbe IMHO anche dipendere dall'icmp: magari e' meglio
impostare dei dnat anche per l'icmp.
Poi dipende dai servizi che offri verso l'esterno: se alcuni servizi tentano
di effettuare un reverse dns, e' meglio offrire al server in dmz almeno la
possibilita' di risolvere i nomi, impedendogli comunque di andare in lan o di
uscire realmente sull'internet.


regola sul traffico in uscita non dovrebbe servire. 
ma non si puo' sapere qual'e' il servizio dnattato?
ad esempio per la porta 80 non ci sono problemi, altri tocca vedere...
puoi comunque sempre vedere il traffico sul firewall con tcpdump e capire
dove si ferma.
--
   Paolo

 ma non si puo' sapere qual'e' il servizio dnattato?
Si tratta di un servizio di VPN sulla porta 1723. 
Ciao Antonio


 sorte del pacchetto di inizio connessione.
Il problema non è da tuo lato... ma da parte di xxx.xxx.xxx.xxx che non sa come
far ritornare (giustamente) a 10.0.0.2 i pacchetti...
Altrimenti non credi che non avrebbe mai senso di parlare di masquerade?
Sai come funziona il route su ogni singolo nodo? 


 bisogna anche vedere le regole di forward) funziona perfettamente.
Il resto della rete (locale poi spiego il perchč) deve avere come gateway
predefinito un percorso che sappia man mano reindirizzare i pacchetti per
10.0.0.2 a chi di dovere...
Ma se fosse cosě il DNAT non sarebbe neppure necessario, basterebbero le
tabelle di route opportunamente settate... a meno di non eseguire un virtual
server.
invece per traslazioni di indirizzi, a meno che gli indirizzi traslati non sia
comunque pubblici il masquerade č necessario, altrimenti il client non saprebbe
piů a chi restituire le risposte che riceve visto che per il route dal suo nodo
in cascata il delivery del pacchetto č sconosciuto.


far ritornare (giustamente) a 10.0.0.2 i pacchetti...
si sta facendo confusione, qui stavamo parlando di:
x.x.x.x (il client, un host qualsiasi) non conosce 10.0.0.2 (il server, su
di una rete interna) e neanche lo deve conoscere.
x.x.x.x conosce e puo contattare solo y.y.y.y (il firewall) il quale con il
DNAT ridirige su 10.0.0.2 
a sua volta 10.0.0.2 ritorna sul firewall il quale ritorna su x.x.x.x
e la regola iptables -t nat -A PREROUTING -p tcp -d x.x.x.x --dport xx -j
DNAT --to-destination 10.0.0.2:xx e' piu' che sufficiente.
naturalmente parlo a ragion veduta, avendolo sperimentato di persona (nel
mio caso xx = 80).
poi possono esserci diverse configurazioni di rete da esaminare caso per
caso.
--
   Paolo

 Sai come funziona il route su ogni singolo nodo? 
Tutto ciň che ti deve interessare č che fuori lo vedano con ip pubblico 
e dentro con privato. Dato che per definizione il firewall deve essere 
l'unico gateway tra pubblico e privato, č chiaro che il pacchetto di 
ritorno debba passare di lě e non da un'altra parte. E' l'unica cosa 
richiesta affinchč il nat funzioni. Il fatto che il pacchetto arrivi qui 
attraverso un cavo cross o altri 12 router in cascata č irrilevante.


 a sua volta 10.0.0.2 ritorna sul firewall il quale ritorna su x.x.x.x
Si vede che di come funziona il tcp/ip e il netfilter te ne intendi poco eh?
10.0.0.2 senza un masquerade su y.y.y.y invia i suoi pacchetti in forward con
l'indirizzo sorgente 10.0.0.2 e destinazione x.x.x.x attraverso y.y.y.y
y.y.y.y vede se può forwardarlo e lo invia senza modificare l'indirizzo
sorgente, e questo lo puoi vedere con un tcpdump sul client che si vedrà
arrivare pacchetti da 10.0.0.2 anche se non lo conosce.
Naturalmente x.x.x.x non saprà più come restituire delle risposte a 10.0.0.2
per il motivo che tu stesso hai detto sopra.
La soluzione è usare o un SNAT in POSTROUTING oppure nel caso di ip dinamico di
y.y.y.y il masquerade.
Il conntrack non effettua ALCUNA modifica degli indirizzi, sia in entrata che
in uscita, traccia solo le connessioni e solo quando il pacchetto entra nella
tabella del filter, quindi dopo la tabella di prerountin e mangle e prima della
tabella di postrouting.
Se non lo capisci ora ti consiglio di studiare e capire cosa è il NAT, come
funziona il conntrack, il netfilter e come si implementa un virtual server.


 in cascata il delivery del pacchetto č sconosciuto.
Ripeto: lascia perdere il routing. Netfilter, a quanto ne so, non opera sul routing:
questa e' una cosa che viene da se', per come e' stato concepito e strutturato.
E' il connection tracking che si occupa poi di tutto trasparentemente (e non puo'
essere che cosi'), di cio' che entra ed esce nella connessione, una volta stabilita
la connessione. E cio' e' stato spiegato bene da the skull.
Puoi rendererti conto di questi concetti leggendo a fondo la documentazione in
netfilter.samba.org


 arrivare pacchetti da 10.0.0.2 anche se non lo conosce.
Ora gli indirizzi di reti private sarebbero "routabili" sull'internet?
Ahem...


funziona il conntrack, il netfilter e come si implementa un virtual server.
non perdo tempo a ribattere alle tue affermazioni, e ribadisco quello che
ti hanno detto gli altri: quello che deve studiare meglio sei tu
--
   Paolo

traffico di ritorno: ci pensa il conntrack.
E io ti ho risposto che è falso in quanto il conntrack non effettua alcuno
source nat implementato come SNAT o MASQUERADE.


 source nat implementato come SNAT o MASQUERADE.
Il man di iptables dice:
    DNAT
        This  target  is	 only valid in the nat table, in the PRE­
        ROUTING and OUTPUT chains, and user-defined  chains  which
        are  only called from those chains.  It specifies that the
        destination address of the packet should be modified  (and
        all  future  packets  in this connection will also be man­
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        gled), and rules should cease being  examined.	It  takes
        ^^^^
Mi pare abbastanza chiaro, no?
In ogni caso, partendo dalla tua sola affermazione:
Ipotesi: hai 27 macchine e 1 firewall. Il firewall fa masq verso l'esterno.
3 delle macchine interne aprono la porta 137 e da questa cercano di 
contattare altre 3 macchine esterne e vengono pertanto mascherate dal FW.
Dato che il masq è esattamente identico allo SNAT, nel momento il cui le 
tre macchine remote rispondono, deve sapere a chi deve ritornare le 
risposte.
Ti rammento che quello che transita in rete pubblica ha come source le 
macchine remote e destination il firewall, in tutti e tre i casi.
Nel momento in cui 'sti pacchetti arrivano sul FW, questo che fa? se li 
gioca alla morra? Dato che i pacchetti hanno come dest l'ip del 
firewall, li deve DNATtare. Ma come fa a sapere come dnattare chi?
Risposta: conntrack. Se ne hai altre, benvenuto.
Da me il masq non esiste, ho uno snat che masquera una rete in classe C, 
  oltre a 7 macchine in DMZ. Ovviamente non c'è nessuna rule che faccia 
il dnat inverso della roba della LAN (nemmeno può esserci, no?). Secondo 
te, come mi funziona? Ho una buona stella?
Byez


 te, come mi funziona?
Con un tunneling...  :-)))


 Ora gli indirizzi di reti private sarebbero "routabili" sull'internet? Ahem...
Se è possibile generare pacchetti con ip sorgente a piacimento figurati se non
sia possibile con un DNAT implementato male....
Altrimenti perchè una delle preoccupazioni di ogni admin serio è proprio di
"blindare" la catena di forward???
Altrimenti non sai che bei bounce ci sarebbero... da usare come ognuno meglio
crede 


 a fondo la documentazione in 
netfilter.samba.org
Io credo che quello che deve studiare la documentazione sul netfilter non debba
essere io...
Poi te devi dimostrare il contrario... non per altro come tu stesso hai detto
senza usare il masquerade o l'SNAT non ti funziona... un motivo ci sarŕ non
credi?


traffico di ritorno: ci pensa il conntrack.
Il che è falso, in quanto è il target SNAT a effettuare la traslazione.


 hanno detto gli altri: quello che deve studiare meglio sei tu
Io allora ancora aspetto spiegazioni per cui al creatore di questo thread senza
un SNAT (o masquerade come volete che sia) il suo virtual server non funzioni. 


 provengono da x.x.x.x)
s/x.x.x.x<->y.y.y.y/x.x.x.x<->z.z.z.z/


 arrivare pacchetti da 10.0.0.2 anche se non lo conosce.
ed e' qua che casca l'asino: essendoci il DNAT, i pacchetti 
proveniente dal server 10.0.0.2 vengono inviati verso il client 
MODIFICANDO L'INDIRIZZO IN QUELLO DEL FIREWALL!!!!!!!!!!!!!!!
il DNAT tiene traccia delle connessioni, per cui i pacchetti 
provenienti dal server che sono risposta al client vengono ritornati 
al client con L'INDIRIZZO DEL FIREWALL!!!
e se non ci credi prova tu ad esaminare il traffico con tcpdump
-- 
    Paolo

 te, come mi funziona? Ho una buona stella?
mah... forse per magia... :-)
-- 
    Paolo

 QUELLO DEL FIREWALL!
No, quello lo fa per te l'SNAT o il MASQUERADE.
Fa questa prova... A rules pulite (altre eventuali rules di policy aggiungile)
iptables -t nat -A PREROUTING -d ipdiprova --dport 12345 -J DNAT
--to-destination ipdiprova2
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -i interfacciaesterna
-o interfaccia interna-j ACCEPT
iptables -A FORWARD -i interfacciaesterna -o interfaccia interna --dport 12345
-j ACCEPT
poi dimmi da chi riceve le risposte un client esterno se da ipdiprova o
ipdiprova2...
Se non vuoi aspettare la risposta te lo dico io: arriverebbero da iplocale2


 Questo dimostra ancora una volta che non sai di cosa stai parlando...
Si, si, si. Hai ragione tu.


 credi?
Gia' fatto. Rileggi, se ti sei perso il passaggio.
*PLONK*


 credi?
Gia' fatto. Rileggi, se ti sei perso il passaggio.
*PLONK*
--


 credi?
N.B. E mi e' pure sfuggita una tecnica che denota il suo agire da probabile troll.
Mai fatto una affermazione del genere...


Fa questa prova... A rules pulite (altre eventuali rules di policy aggiungile)
non ho bisogno di fare nessun prova perche' l'ho gia' implementato, vediamo
l'output di tcpdump sul firewall:
x.x.x.x = client
f.f.f.f = firewall
192.168.1.10 = server
[root@xyz ~]# tcpdump tcp port 80
Kernel filter, protocol ALL, TURBO mode (575 frames), datagram packet
socket
tcpdump: listening on all devices
08:44:42.682967 eth1 < x.x.x.x.1036 > f.f.f.f.http: S
138316895:138316895(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
08:44:42.682967 eth0 > x.x.x.x.1036 > 192.168.1.10.http: S
138316895:138316895(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
08:44:42.682967 eth0 < 192.168.1.10.http > x.x.x.x.1036: S
3935491141:3935491141(0) ack 138316896 win 5840 <mss 1460,nop,nop,sackOK>
(DF)
08:44:42.682967 eth1 > f.f.f.f.http > x.x.x.x.1036: S
3935491141:3935491141(0) ack 138316896 win 5840 <mss 1460,nop,nop,sackOK>
(DF)
cosa dice questa riga di sopra secondo te? che indirizzo ritorna verso il
client?????
08:44:42.682967 eth1 < x.x.x.x.1036 > f.f.f.f.http: . 1:1(0) ack 1 win
17520 (DF)
08:44:42.682967 eth0 > x.x.x.x.1036 > 192.168.1.10.http: . 1:1(0) ack 1 win
17520 (DF)
08:44:42.682967 eth1 < x.x.x.x.1036 > f.f.f.f.http: P 1:263(262) ack 1 win
17520 (DF)
08:44:42.682967 eth0 > x.x.x.x.1036 > 192.168.1.10.http: P 1:263(262) ack 1
win 17520 (DF)
08:44:42.692967 eth0 < 192.168.1.10.http > x.x.x.x.1036: . 1:1(0) ack 263
win 6432 (DF)
08:44:42.692967 eth1 > f.f.f.f.http > x.x.x.x.1036: . 1:1(0) ack 263 win
6432 (DF)
e cosi via...
l'unica regola che c'e' e' quella per il DNAT:
[root@xyz  ~]# iptables -L -v -t nat
Chain PREROUTING (policy ACCEPT 1489 packets, 251379 bytes)
 pkts bytes target     prot opt in     out     source
destination
    15   3346  DNAT       tcp  --  eth1   any     anywhere
anywhere           tcp dpt:http to:
192.168.1.10:80
Chain POSTROUTING (policy ACCEPT 5 packets, 240 bytes)
 pkts bytes target     prot opt in     out     source
destination
Chain OUTPUT (policy ACCEPT 51 packets, 4457 bytes)
 pkts bytes target     prot opt in     out     source
destination
attendo spiegazioni.
--
   Paolo