Newsgroup: it.comp.os.linux.development
Titolo: NAT/PAT su messaggi in ingresso

Ciao a tutti,
ho configurato iptables su un server collegato ad un router ADSL.
I messaggi in ingresso da internet verso la porta 6000 del server vengono
reindirizzati alla porta 5500 di un PC sulla rete interna con
iptables....nat PREROUTING... -p tcp... --destination-port 6000 DNAT to....
pc_interno:5500 ,etc etc, e questo funziona.
Io devo anche fare il NAT sui messaggi UDP in ingresso sulla porta 8080
senza cambiare porta reindirizzandoli al pc_interno di cui sopra.
Era circa cosě: iptables....nat PREROUTING... -p udp... --destination-port
8080 DNAT to.... pc_interno
Il problema č che quando ho impostato iptables la prima volta (venerdě) ha
funzionato, mentre lunedě ho controllato la cosa e NON FUNZIONA PIU'!!
I messaggi arrivano alla linux box ma vengono respinti con un
icmp_destination_unreachable!!!! E non escono verso la rete interna, vengono
proprio respinti invece che ricevere il NAT! Eppure la sintassi č la stessa
della riga TCP con le opportune modifiche, e la catena OUTPUT e INPUT
lasciano passare TUTTI i msg UDP!
Avete un'idea? Garantisco che in TCP va e UDP no!
Grazie,
Osolemio

 lasciano passare TUTTI i msg UDP!
Se DNATti in  PREROUTING le chain INPUT e OUTPUT  non vengono prese in
considerazione, controlla la chain FORWARD.
-- 
Vuoi fare colpo su di lei con me?
Fai colpo su di lei con me! Fai colpo su di lei con me!
[Dr. Gonzo : Paura e delirio a Las Vegas]

 considerazione, controlla la chain FORWARD.
Ho dimenticato di includere la FORWARD: anche questa ha POLICY ACCEPT e non
ha entries.
Qualche opzione da attivare sul kernel? Non saprei...
Qualche servizio? Zebra č attivo, del resto il NAT su TCP 6000->5500
funziona egregiamente!!
Grazie
    Osolemio

Ho fatto altre analisi:
mettendo un -j LOG nelle varie catene e tabelle, risulta quanto segue:
0)Il pacchetto entra dalla eth0
1)Il pacchetto "passa" dalla tabella 'mangle', catena 'PREROUTING'
2)Il pacchetto "passa" dalla tabella 'mangle', catena 'INPUT'
3)Il pacchetto "passa" dalla catena 'INPUT'
La maledetta tabella nat non viene mai esaminata ma il pacchetto passa da
mangle e basta. A me risulta che dopo essere stato esaminato da mangle
dovrenne passare prima da nat-PREROUTING e poi nat-POSTROUTING!!!
Lo strano è che tutto funziona con il protocollo TCP!!!
Possibili cause?
Grazie ancora
Osolemio

 destination_unreachable è generato dalla Linux Box. Sigh!
...
Non fai prima a postare un estratto della configurazione in modo che si
capisca qualcosa?
E in ogni caso questo non e' il gruppo giusto.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! 3rd Law of Computing: Anything that can go wr
		fortune: Segmentation violation -- Core dumped !>-

 dovrenne passare prima da nat-PREROUTING e poi nat-POSTROUTING!!!
Qui non so dirti, non ho ancora mai avuto la necessita' di usare mangle.
Comunque prova  a postare la  configurazione di iptables (o  lo script
oppure iptables -L -v -n, ma non iptables-save/restore che li odio :-)
Ma stai usando  zebra?  Essendo un software di  routing potrebbe anche
essere il responsabile, ma di zebra non so nulla.  (L'unica sensazione
che ho  avuto e' stata questa:  se vuoi parlare di  zebra, spostati su
.sys :-))
PS,  potresti dire  anche  -cosa-  stai facendo  con  mangle, zebra  e
compagnia bella?
Ciao.


 Avete un'idea? Garantisco che in TCP va e UDP no!
probabilmente e' colpa del connection tracking (usato dal NAT)
che usa timeout troppo bassi per le tue esigenze,
prova ad aumentare i timeout relativi al protocollo UDP.
-- 
0RTICA

 prova ad aumentare i timeout relativi al protocollo UDP.
Facile a dirsi, piu' difficile a farsi penso... mica siamo in obsd ;-P
Per lo meno,  io non ho trovato nessun riferimento  ne' nel manuale di
iptables, ne' come  opzione di sysctl (ma forse cerco  male e il posto
dove guardare sono i sorgenti del kernel...).


 oppure iptables -L -v -n, ma non iptables-save/restore che li odio :-)
Ecco la mia config: è semplice semplice, doveva fare solo quello che mi
serve....
(fa anche SNAT in POSTROUTING per navigare in internet)
Ho provato a modificarla in mille modi ma nulla, UDP:8080 non natta ma
TCP:6000 sì, e patta anche!!
# !/bin/sh
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -t nat -A POSTROUTING -o eth0 -p tcp --source-port 5500 -j
SNAT --to 
192.168.3.1:6000
iptables -t nat -A POSTROUTING -o eth0 -p tcp --source-port ! 5500 -j
SNAT --to 192.168.3.1
iptables -t nat -A POSTROUTING -o eth0 -p udp -j SNAT --to 192.168.3.1
iptables -t nat -A POSTROUTING -o eth0 -p icmp -j SNAT --to 192.168.3.1
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.3.1
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 6000 -d 192.168.3.1 -j
DNAT --to 
192.168.1.18:5500
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 8080 -d 192.168.3.1 -j
DNAT --to 192.168.1.18
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#iptables -A INPUT -m state --state NEW -i ! eth0 -j ACCEPT
iptables -A INPUT -m state --state NEW -j ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -A FORWARD -p udp --dport 8080 -j ACCEPT
#iptables -A FORWARD -i eth0 -o eth0 -j REJECT
Grazie ancora, posto qui per proseguire il thread, semmai poi posterò come
consigliatomi su .sys...
Osolemio

 dove guardare sono i sorgenti del kernel...).
esatto, fino al kernel 2.4.22 non puoi far altro che
modificare il file /net/ipv4/netfilter/ip_conntrack_proto_udp.c:
#define UDP_TIMEOUT (30*HZ)
#define UDP_STREAM_TIMEOUT (180*HZ)
ma nel kernel 2.4.23 sono state aggiunte le seguenti voci al 
file /include/linux/sysctl.h che permettono di gestire i 
parametri del conntrack:
/* /proc/sys/net/ipv4/netfilter */
enum
{
	NET_IPV4_NF_CONNTRACK_MAX=1,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_SYN_SENT=2,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_SYN_RECV=3,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_ESTABLISHED=4,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_FIN_WAIT=5,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_CLOSE_WAIT=6,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_LAST_ACK=7,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_TIME_WAIT=8,
	NET_IPV4_NF_CONNTRACK_TCP_TIMEOUT_CLOSE=9,
	NET_IPV4_NF_CONNTRACK_UDP_TIMEOUT=10,
	NET_IPV4_NF_CONNTRACK_UDP_TIMEOUT_STREAM=11,
	NET_IPV4_NF_CONNTRACK_ICMP_TIMEOUT=12,
	NET_IPV4_NF_CONNTRACK_GENERIC_TIMEOUT=13,
};
 
invece per avere piu' parametri da gestire, nel 
"patch-o-matic extra repository", c'e' la patch 
tcp-window-tracking, che estende le funzionalita' del 
connection tracking e permette la gestione di numerosi 
parametri in /proc/sys/net/ipv4/netfilter/*
-- 
0RTICA

 consigliatomi su .sys...
sys piu' che altro te lo consigliavo di base se avevi dei problemi con
zebra,  visto che  se  ne  parla veramente  poco  e sembra  abbastanza
complesso... cosi' non so, vedi tu.
Hai provato anche il consiglio di 0rtica?


 parametri in /proc/sys/net/ipv4/netfilter/*
Grazie dell'info. :-)
Ciao.


 features come ho inteso io?
dicevo in generale, ma imho, la caratteristica che rende
netfilter/iptables preferibile a PF e' l'estendibilita',
ci vogliono pochi minuti per estendere iptables e nella
maggioranza dei casi non e' necessario ricompilare il 
kernel, poi c'e' la libreria libipq che permette di gestire
in userspace i pacchetti accodati da ip_queue, poi ci
sono gli hook di netfilter, c'e' il connection tracking...
per quel che riguarda le funzionalita' basta dare uno sguardo
alla directory extensions/ nei sorgenti di iptables, per
rendersi conto delle grandi potenzialita' di questo firewall,
ad oggi ci sono altre cento estensioni (tra match e target) 
e questo significa che e' possibile impostare altri cento
parametri nelle regole di filtraggio/nat/...
il fatto e' che, stranamente, c'e' poca attenzione attorno
a netfilter a differenza di PF, 
ad esempio quando e' stato aggiunto il supporto per l'OS 
fingerprinting a PF se ne e' parlato ovunque, ma pochi sanno 
dell'esistenza di ipt_osf "OS fingerprint matching module" 
che permette di impostare regole del genere:
iptables -A INPUT -p tcp -m osf --genre Windows -j REJECT
e poi come dici tu, bisogna tenere presente anche le prestazioni,
che per un firewall sono fondamentali...
ovviamente anche PF ha delle caratteristiche che mancano a 
iptables, e inoltre bisogna considerare che PF e' un progetto
relativamente recente e quindi in continua evoluzione...
-- 
0RTICA

 #define UDP_STREAM_TIMEOUT (180*HZ)
Questo significa che devo modificare tale file e ricompilare... il kernel?
(Non č 2.4.23)
30*HZ cosa significa? Che ordine di grandezza ha, us-ms-s???
In effetti se una volta la macchina ha funzionato, non č che ci sono proprio
problemi di tempistiche, e per qualche oscuro motivo quando ha funzionato il
sistema era UN FILO piů veloce?
Scusate per il "tampinamento" ma, veramente, ci sto impazzendo dedicando una
buona ora quotidiana in prove e riprove. Per fortuna che il fatturato
aziendale non č condizionato da questo problema...
Eppoi non credevo di arrivare a livelli cosě bassi (kernel), speravo in
qualche servizio non attivato o qualche errore logico nella configurazione
iptables... del resto tutto č come era quando andava! Bah.

 30*HZ cosa significa? Che ordine di grandezza ha, us-ms-s???
per l'architettura i386 significa 30 secondi

 relativamente recente e quindi in continua evoluzione...
Meno male che hai concluso cosi', mi stavi letteralmente demolendo pf,
da  me finora  considerato  inattaccabile (non  per  una mia  opinione
reale, piu' che altro per sentito dire pero'...).
BTW, sto litigando con altq in pf e ci sono molte cose che mi sfuggono
ancora,   preparati  ad   un  post   da  qualche   parte   (magari  su
free.it.comp.os.unix.freebsd),   che   il   tuo   intervento   sarebbe
"fondamentale" :-)
Ciao  e grazie.


 per l'architettura i386 significa 30 secondi
Okkappa
Grazie ancora tantissime... spero domani o max. dopo di avere il tutto
perfettamente configurato!
Osolemio