Avanti Indietro Indice

3. Problemi durante l'esecuzione

3.1 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb

Questo messaggio viene segnalato dal codice NAT in quanto pacchetti multicast hanno raggiunto la tabella NAT. Il connection tracking al momento non è in grado di gestire questi pacchetti. Nel caso non si abbia idea di cosa sia il multicast o non se ne abbia bisogno si utilizzi:

iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8

3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

Il syslog o la console presentano il messaggio:

 "NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb"

Questo messaggio è segnalato dal codice NAT. I pacchetti sono scartati in quanto per effettuare il NAT sono necessarie informazioni valide sul tracciamento delle connessioni. Questo messaggio viene incluso per tutti i pacchetti per i quali il connection tracking non è in grado di determinare informazioni conntrack.

Possibili ragioni sono:

Se si desidera un logging dettagliato di questi pacchetti (es. se si sospettano pacchetti di scanning / probe remoto) si utilizzi la seguente regola:

iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID

E sì, si deve inserire la regola nella tabella mangle, in quanto i pacchetti sono scartati dal codice NAT prima che raggiungano la tabella filter.

3.3 Non riesco ad utilizzare netfilter in combinazione con il codice di bridging di Linux

Si vuole realizzare un completo firewall trasparente ? Ottima idea! Sfortunatamente il codice di bridging scavalca il normale stack di rete, incluso netfilter.

C'è comunque qualcuno che sta scrivendo un rimpiazzo per il codice di bridging attuale, visitare il sito <http://www.math.leidenuniv.nl/~buytenh/bridge/>.

Si noti che il supporto bridge per il firewall è considerato ancora altamente sperimentale.

3.4 Il modulo IRC è incapace di gestire il resume di DCC

Bene, questa è una mezza verità. Solo il modulo NAT non è in grado di gestirla. Se il firewall non utilizza il NAT allora dovrebbe funzionare bene.

3.5 Come opera il SNAT con gli indirizzi multipli?

Netfilter cerca di manipolare il meno possibile. Perciò se la macchina è appena stata riavviata, e qualcuno dietro la SNAT box apre una connessione utilizzando la porta locale 1234, la netfilter box cercherà di manipolare solo l'indirizzo IP mentre la porta resterà la stessa.

Se per effettuare il SNAT si usa un unico indirizzo IP, appena qualcuno aprirà un'altra connessione utilizzando la stessa porta sorgente, netfilter interverrà manipolando sia l'indirizzo IP sia la porta.

Se sono però disponibili più indirizzi allora dovrà continuare a maneggiare ancora ed esclusivamente la parte IP.

3.6 ip_conntrack: maximum limit of XXX entries exceeded

Se si nota il seguente messaggio nel syslog allora il database conntrack non ha un numero sufficiente di entry per il proprio "ambiente". Il connection tracking per default gestisce fino ad un certo numero di connessioni simultaneamente. Questo numero dipende dalla quantità massima di memoria disponibile nel proprio sistema (64MB: 4096, 128MB: 8192, ...).

Si può incrementare il numero massimo di connessioni da tracciare in modo alquanto semplice, tuttavia si presti attenzione al fatto che ogni connessione tracciata richiede circa 500 byte di memoria kernel non di swap.

Per elevare questo limite a 8192 per esempio, si deve impartire:

echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max

Ovviamente si può utilizzare un qualsiasi numero sempre che possa però essere contenuto, a seconda del proprio hardware, in un 'int' (ciò significa 32 bit nella maggior parte delle piattaforme). Si tenga presente che ogni connessione tracciata ha bisogno di un certo ammontare di memoria del kernel non di swap (  500 byte per connessione, tanto per indicare un numero).

3.7 Come posso avere un elenco di tutte le connessioni tracciate / mascherate in modo simile a 'ipchains -L -M' (2.2.x) ?

Nel filesystem proc è presente un file denominato /proc/net/ip_conntrack. E' possibile visualizzare questo file utilizzando:

cat /proc/net/ip_conntrack

3.8 Come posso visualizzare tutte le tabelle IP disponibili ?

Si può ottenere un elenco di tutte le tabelle IP disponibili utilizzando

cat /proc/net/ip_tables_names

3.9 segfault di iptables-save / iptables-restore con iptables-1.2

Bug noto. Si aggiorni utilizzando la CVS o si utilizzi iptables >= 1.2.1 appena sarà disponibile.

3.10 iptables -L impiega un tempo davvero lungo per visualizzare le regole

Ciò è dovuto a iptables il quale deve effettuare una consultazione del DNS per ogni indirizzo IP. Siccome ogni regola consiste di due indirizzi, il caso peggiore prevede due consultazioni del DNS per regola.

Il problema, se si utilizzano indirizzi IP privati (tipo 10.x.x.x oppure 192.168.x.x) è causato dall'impossibilità per il DNS di risolvere un hostname e quindi dal time out. La somma di tutti i time out può diventare davvero consistente, a seconda del proprio set di regole.

Si utilizzi l'opzione -n (numeric) di iptables per impedire le consultazioni inverse del DNS.

3.11 Come posso impedire al target LOG di visualizzare le registrazioni sulla console ?

E' necessario configurare sylogd in modo appropriato: il target LOG deve registrare utilizzando la facility kern con priority warning (4). Si consultino le pagine del manuale di syslogd.conf per ricavare maggiori informazioni su facility e priority.

Di default tutti i messaggi del kernel con priorità più rigorose di debug (7) sono inviati alla console. Se lo si imposta a 4, invece di 7, si ottiene che i messaggi non appariranno più sulla console.

Si presti attenzione in quanto potrebbero non essere visualizzati sulla console anche altri messaggi importanti (ciò non influenza syslog).

3.12 Come posso implementare un proxy trasparente utilizzando squid e iptables ?

Prima di tutto ovviamente è necessario un'opportuna regola NAT o REDIRECT. Si utilizzi REDIRECT solamente se squid è in esecuzione sulla NAT box stessa.

Esempio:

iptables -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128

Dopo di ché è necessario configurare squid in modo appropriato. E' possibile indicare qui solo brevi note, per ulteriori dettagli si consulti la documentazione di squid.

Per Squid 2.3 è necessario che il file squid.conf assomigli a quanto segue:

http_port 3128 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on
Squid 2.4 richiede l'aggiunta di un'ulteriore linea:
httpd_accel_single_host off

3.13 Come si utilizza il target LOG / Come utilizzare LOG e DROP ?

Il target LOG è ciò che si definisce un "target non terminante", ossia non causa l'interruzione della traversata del pacchetto tra le regole. Se si utilizza il target LOG il pacchetto sarà registrato e la traversata sarà continuata con la regola successiva.

Quindi come effettuare il log e il drop nello stesso istante ? Nulla di più semplice è sufficiente creare una catena con le seguenti due regole:

iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP

Ora ogni qualvolta si desideri il log e drop di un pacchetto è sufficiente utilizzare "-j logdrop".


Avanti Indietro Indice