Linux 2.4 NAT HOWTO
Rusty Russell, mailing list netfilter@lists.samba.org
$Revision: 1.15 $ $Date: 2001/07/29 03:59:37 $
Questo documento descrive come effettuare il masquerading, il proxy
trasparente, il port forwarding e altre forme di traduzione degli ind
irizzi di rete (NAT) con i kernel Linux 2.4. Traduzione a cura di
Masetti Marco marcomas@libero.it <mailto:marcomas@libero.it>
______________________________________________________________________
Indice Generale
1. Introduzione
2. Dove si trovano la pagina Web ufficiale e la lista ?
2.1 Cos'è il Network Address Translation?
2.2 Perché si dovrebbe aver bisogno del NAT?
3. I due tipi di NAT
4. Guida rapida alla transizione dai kernel 2.0 e 2.2
4.1 Voglio giusto il masquerading! Aiuto!
4.2 Che cosa a riguardo di ipmasqadm?
5. Come impostare il NAT
5.1 Semplici selezioni usando iptables
5.2 Note utili sulla selezione dei pacchetti da manipolare
6. Spiega come manipolare i pacchetti
6.1 Source NAT
6.1.1 Masquerading
6.2 Destination NAT
6.2.1 Redirezione
6.3 Mapping in dettaglio
6.3.1 Selezione di indirizzi multipli in un intervallo
6.3.2 Creare mapping NAT nullo
6.3.3 Comportamento Standard del NAT
6.3.4 Mapping implicito delle porte sorgenti
6.3.5 Cosa succede quando il NAT fallisce
6.3.6 Mapping multipli, sovrapposizioni, conflitti
6.3.7 Alterare la destinazione delle connessioni generate localmente
7. Protocolli speciali
8. Avvertimenti riguardo il NAT
9. Source NAT e Instradamento
10. Destination NAT nella stessa rete
11. Ringraziamenti
______________________________________________________________________
1. Introduzione
Benvenuto, caro lettore.
Stiamo per addentrarci nell'affascinante mondo del NAT: Network
Address Translation, e questo HOWTO sta per diventare la propria guida
accurata al kernel 2.4 di Linux ed altro.
In Linux 2.4 è stata introdotta un'infrastruttura per il mangling
(manipolamento) dei pacchetti, chiamata `netfilter'. Uno strato
superiore a questo provvede al NAT, completamente reimplementato
rispetto ai kernel precedenti.
(C) 2000 Paul `Rusty' Russell. Licenza GNU GPL.
2. Dove si trovano la pagina Web ufficiale e la lista ?
Ci sono tre siti ufficiali:
· Grazie a Filewatcher <http://netfilter.filewatcher.org/>.
· Grazie a The Samba Team e SGI <http://netfilter.samba.org/>.
· Grazie a Harald Welte <http://netfilter.gnumonks.org/>.
Per la mailing list ufficiale di netfilter visitare Samba Listserver
<http://lists.samba.org>.
2.1. Cos'è il Network Address Translation?
Normalmente i pacchetti nella rete viaggiano dalla sorgente (come il
proprio computer di casa) verso la loro destinazione (come ad esempio
www.gnumonks.org) passando attraverso diversi collegamenti, nel mio
caso circa 19 da dove mi trovo in Australia. Nessuno di questi
collegamenti altera in realtà i propri pacchetti, non fanno altro che
farli proseguire.
Se uno di essi però effettua il NAT, allora sarà in grado di alterare
la sorgente o la destinazione del pacchetto così come solo di
lasciarlo passare. Come si può ben immaginare, il sistema non è stato
creato per funzionare in questo modo, e quindi il NAT è sempre un
qualcosa di particolare. In genere i collegamenti che effettuano il
NAT ricordano come hanno manipolato il pacchetto, e quindi quando
arriva un pacchetto di risposta dall'altra parte, effettuano su di
esso la manipolazione inversa, in questo modo tutto funziona.
2.2. Perché si dovrebbe aver bisogno del NAT?
In un mondo perfetto non se ne avrebbe bisogno. Le principali ragioni
sono:
Connessioni via modem a internet
La maggior parte degli ISP, quando ci si collega, fornisce un
singolo indirizzo. Si possono naturalmente inviare pacchetti
con qualsiasi indirizzo sorgente, ma i pacchetti di risposta che
si riceveranno saranno solo quelli relativi ai pacchetti inviati
con l'indirizzo fornito dal proprio ISP. Se si desidera usare
più di una macchina (come ad esempio la propria rete locale di
casa) per connettersi a Internet attraverso questo unico
collegamento, allora si avrà bisogno del NAT.
Questo è oggi l'utilizzo più comune del NAT, noto come
`masquerading' (mascheramento) nel mondo Linux. Io lo chiamo
SNAT, in quanto ciò che si modifica è l'indirizzo sorgente del
primo pacchetto.
Server multipli
Talvolta si vuole cambiare nella propria rete la destinazione
dei pacchetti. Questo perché spesso (come sopra) si ha solo un
indirizzo IP, ma si desidera che le persone siano in grado di
accedere alle macchine che stanno dietro a quella che possiede
l'indirizzo IP `reale'. Ciò si può ottenere se si riscrive la
destinazione dei pacchetti che arrivano. Questo tipo di NAT era
chiamato port-forwarding nelle versioni precedenti di Linux.
Una variante comune di ciò è il load-sharing, dove un gran
numero di pacchetti sono distribuiti su una serie di macchine.
Se si sta utilizzando questa tecnica su larga scala allora si
potrebbe essere interessati al Linux Virtual Server
<http://linuxvirtualserver.org/>.
Proxy trasparente
Talvolta si vuole che ogni pacchetto che attraversa la Linux box
sia destinato ad un programma della Linux box stessa. Questo è
usato per realizzare il proxy trasparente: un proxy è un
programma collocato tra la propria rete e il mondo esterno che
regola la comunicazione. Si dice trasparente perché la propria
rete non saprà mai di dialogare con un proxy, a meno che
naturalmente il proxy non funzioni.
Squid può essere configurato per operare in questa maniera,
detta redirezione o proxy trasparente nelle versioni precedenti
di Linux.
3. I due tipi di NAT
Ho diviso il NAT in due parti: Source NAT (SNAT) e Destination NAT
(DNAT).
Il Source NAT si ha quando si altera l'indirizzo sorgente del primo
pacchetto ossia si cambia da dove la connessione proviene. Source NAT
è sempre effettuato in fase di post-routing, appena prima che il
pacchetto sia immesso nella rete. Il mascheramento (masquerading) è
una forma specializzata di SNAT.
Il Destination NAT invece si ha quando si altera l'indirizzo
destinazione del primo pacchetto ossia si cambia dove la connessione è
diretta. Destination NAT è sempre effettuato in fase di pre-routing,
appena il pacchetto arriva dalla rete. Port forwarding, load sharing e
il proxy trasparente sono tutte forme di DNAT.
4. Guida rapida alla transizione dai kernel 2.0 e 2.2
Mi dispiace per tutti coloro che sono rimasti traumatizzati dal
passaggio dalla 2.0 (ipfwadm) alla 2.2 (ipchains). Ci sono novità
buone e cattive.
Prima di tutto, si possono utilizzare ipchains e ipfwadm come prima.
E' necessario però usare insmod per caricare i moduli del kernel
`ipchains.o' o `ipfwadm.o' presenti nell'ultima distribuzione di
netfilter. Questi sono mutuamente esclusivi, o si usa uno o l'altro
(siete avvertiti), e non dovrebbero essere combinati con nessun modulo
di netfilter.
Quando si è installato uno o l'altro di questi moduli si può usare
ipchains e ipfwadm come al solito, con però le seguenti differenze:
· Impostare i timeout del masquerading con le opzioni -M -S di
ipchains, o le opzioni -M -s di ipfwadm non serve più a nulla.
Dato che i timeout sono più "lunghi" nella nuova infrastruttura NAT
non dovrebbero più interessare.
· I campi init_seq, delta e previous_delta nell'elenco verbose del
masquerade risulteranno sempre posti a 0.
· Azzerare ed elencare i contatori nello stesso momento con le
opzioni `-Z -L' non funzionerà più: i contatori non saranno
azzerati.
· Lo strato di compatibilità con il passato non scala molto bene nel
caso in cui siano presenti un gran numero di connessioni: non lo si
utilizzi con il gateway della propria azienda !
Gli hacker inoltre noteranno che:
· adesso è possibile collegarsi alle porte 61000-65095 anche se si
sta utilizzando il masquerading. Il codice del masquerading
assumeva qualsiasi porta di questo intervallo come un facile
bersaglio, perciò i programmi non potevano usarle.
· Il non documentato `getsockname', che i programmi di proxy
trasparente potevano utilizzare per ricavare la reale destinazione
delle connessioni, ora non funziona più.
· Il non documentato bind-to-foreign-address non è implementato; era
usato per completare l'illusione del proxy trasparente.
4.1. Voglio giusto il masquerading! Aiuto!
Questo è ciò che vuole la maggior parte delle persone. Se si ha un
indirizzo IP dinamico PPP (dialup) (se non lo si sa, allora lo si ha),
quello che si desidera è di poter dire alla propria box che tutti i
pacchetti provenienti dalla propria rete locale devono essere visti
come provenienti dalla box collegata in dial-up.
# Carica il modulo NAT (questo aggiunge tutti gli altri).
modprobe iptable_nat
# Nella tabella NAT (-t nat), appendi una regola (-A) che dopo il routing
# (POSTROUTING) per tutti i pacchetti in uscita dalla ppp0 (-o ppp0)
# mascheri la connessione (-j MASQUERADE).
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
# Attiva l'IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
Si noti che qui non si sta effettuando alcun filtraggio dei pacchetti,
per questo tipo di operazioni si legga il Packet Filtering HOWTO:
`Mescolare NAT e filtraggio dei pacchetti'.
4.2. Che cosa a riguardo di ipmasqadm?
Questo è un bacino di utenza ancora più ristretto, perciò non mi sono
preoccupato molto di garantire la compatibilità. Per effettuare il
port forwarding si può semplicemente usare `iptables -t nat'. Per
esempio, in Linux 2.2 probabilmente si è fatto uso di:
# Linux 2.2
# Fai proseguire i pacchetti TCP diretti alla porta 8080 indirizzo 1.2.3.4
# verso l'indirizzo 192.168.1.1 porta 80
ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80
Ora invece si dovrebbe usare:
# Linux 2.4
# Appendi una regola di pre-routing (-A PREROUTING) alla tabella NAT (-t nat)
# in modo che i pacchetti TCP (-p tcp) destinati all'indirizzo 1.2.3.4 (-d
# 1.2.3.4) porta 8080 (--dport 8080) siano diretti (-j DNAT) verso l'indirizzo
# 192.168.1.1, porta 80 (--to 192.168.1.1:80).
iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 8080 \
-j DNAT --to 192.168.1.1:80
5. Come impostare il NAT
Si devono creare delle regole di NAT che segnalino al kernel quali
connessioni cambiare e come cambiarle. Per fare ciò, si userà il
programma iptables, il quale oltre ad essere veramente versatile,
permette anche di alterare la tabella NAT specificando l'opzione `-t
nat'.
La tabella delle regole NAT contiene tre liste chiamate comunemente
`catene' (chains): ogni regola è esaminata per ordine finché una non è
soddisfatta. Due catene sono chiamate PREROUTING (per il Destination
NAT sui pacchetti in arrivo) e POSTROUTING (per il Source NAT sui
pacchetti in uscita).
Il seguente diagramma, se ho un talento artistico, dovrebbe illustrare
tutto ciò molto bene.
_____ _____
/ \ / \
PREROUTING --->[Decisioni] --------------->POSTROUTING----->
\D-NAT/ [di routing ] \S-NAT/
[instradamento] ^
| |
| |
| |
| |
| |
| |
--------> Processi locali ----
Per ogni punto, quando un pacchetto passa viene osservata quale
connessione vi è associata. Se è una nuova connessione, per sapere
cosa fare, si osserverà la catena corrispondente nella tabella NAT.
La risposta che si otterrà sarà poi applicata anche a tutti i
pacchetti successivi appartenenti a questa connessione.
5.1. Semplici selezioni usando iptables
iptables vanta una serie di opzioni standard elencate sotto. Tutte le
opzioni con doppio trattino possono essere abbreviate, sempre che
iptables possa distinguerle dalle altre opzioni disponibili. Se il
proprio kernel supporta iptables usando un modulo, si dovrà prima di
tutto caricare il modulo ip_tables.o utilizzando `insmod ip_tables'.
L'opzione più importante è l'opzione di selezione della tabella `-t'.
Per tutte le operazioni di NAT si dovrà sempre utilizzare `-t nat'.
La seconda opzione più importante è `-A' usata per appendere una nuova
regola alla fine della catena (es. -A `POSTROUTING') o `-I' per
inserirne una all'inizio (es. `-I PREROUTING').
Si può specificare la sorgente (`-s' o `--source') e la destinazione
(`-d' o `--destination') dei pacchetti su cui si vuole effettuare il
NAT. Queste opzioni possono essere seguite da un indirizzo IP singolo
(es. 192.168.1.1), da un nome (es. www.gnumonks.org) oppure da un
indirizzo di rete (es. 192.168.1.0/24 oppure
192.168.1.0/255.255.255.0).
Si può inoltre specificare l'interfaccia di ingresso (`-i' o `--in-
interface') o l'interfaccia di uscita (`-o' o `--out-interface'), ma
quale usare dipende dalla catena in cui si vuole aggiungere la regola,
nella catena PREROUTING si può specificare solo l'interfaccia di
ingresso, nella catena POSTROUTING solo quella di uscita. Se si usa
quella sbagliata iptables comunque restituirà un errore.
5.2. Note utili sulla selezione dei pacchetti da manipolare
Come detto precedentemente si può specificare un indirizzo sorgente o
di destinazione. Se si omette l'opzione di indirizzo sorgente, allora
si intenderà qualsiasi indirizzo sorgente. Se si omette l'opzione di
indirizzo destinazione, allora si intenderà qualsiasi indirizzo
destinazione.
Si può anche indicare uno specifico protocollo (`-p' o `--protocol'),
come ad esempio TCP o UDP, in questo modo solo i pacchetti con quel
protocollo saranno sottoposti alla regola. La ragione principale per
cui è utile specificare il protocollo è che tcp e udp consentono di
utilizzare delle opzioni extra, precisamente le opzioni `--source-
port' e `--destination-port' (abbreviate `--sport' e `--dport').
Queste opzioni permettono di specificare che solo i pacchetti con
quella certa porta sorgente e destinazione dovranno essere sottoposti
alla regola. Questo è utile per le richieste di redirezione del web
(TCP porta 80 o 8080) e per lasciar stare gli altri pacchetti.
Queste opzioni devono essere inserite dopo l'opzione `-p' (che ha come
effetto quello di caricare la libreria estensione del protocollo).
Per le porte si possono utilizzare i numeri corrispondenti, o i nomi
presenti nel file /etc/services.
Tutte le differenti caratteristiche utilizzabili per selezionare un
pacchetto sono dettagliate in modo esauriente nelle pagine del manuale
(man iptables).
6. Spiega come manipolare i pacchetti
Ora si è appreso come selezionare i pacchetti che si vogliono
manipolare. Per completare la propria regola è inoltre necessario
specificare al kernel con precisione che cosa si vuole fare a questi
pacchetti.
6.1. Source NAT
Se si vuole effettuare il Source NAT allora si deve cambiare
l'indirizzo sorgente della connessione con qualcosa di differente.
Questo però deve essere fatto nella catena POSTROUTING, appena prima
che il pacchetto sia inviato. Questo è un dettaglio importante,
perché solo così qualsiasi altra cosa nella Linux box (instradamento,
filtraggio dei pacchetti) vedrà il pacchetto come invariato. Ciò
significa inoltre che si potrà utilizzare l'opzione `-o' (interfaccia
uscente).
Il Source NAT si specifica usando `-j SNAT', l'opzione `--to-source'
permette di indicare un indirizzo o un intervallo di indirizzi IP e
opzionalmente una o un intervallo di porte (però solo con i protocolli
UDP e TCP).
## Cambia l'indirizzo sorgente in 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
## Cambia l'indirizzo sorgente in 1.2.3.4, 1.2.3.5 oppure 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
## Cambia l'indirizzo sorgente in 1.2.3.4, porte 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
6.1.1. Masquerading
Esiste un caso specializzato di Source NAT denominato mascheramento
(masquerading): dovrebbe essere utilizzato solo se gli indirizzi IP
sono assegnati dinamicamente, come ad esempio nel caso di connessione
via modem (dial up), nel caso di indirizzi IP statici invece si usi il
già citato SNAT.
Non è necessario con il mascheramento (masquerading) indicare
esplicitamente l'indirizzo sorgente in quanto sarà utilizzato
l'indirizzo dell'interfaccia da cui il pacchetto uscirà. Ancora più
importante è il fatto che se il collegamento dovesse interrompersi, la
connessione sarà dimenticata (sarebbe comunque persa), in questo modo
non ci saranno grossi problemi quando la connessione sarà ristabilita,
naturalmente con un nuovo indirizzo IP.
## Maschera qualsiasi cosa esca da ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
6.2. Destination NAT
Questo avviene nella catena PREROUTING, appena il pacchetto arriva;
ciò significa che qualsiasi cosa nella Linux box (instradamento,
filtraggio dei pacchetti) vedrà il pacchetto arrivato con il suo
indirizzo di destinazione `reale'. Ciò permette di utilizzare
l'opzione `-i' (interfaccia ingresso).
Destination NAT si specifica usando `-j DNAT', l'opzione `--to-
destination' permette di specificare un indirizzo o un intervallo di
indirizzi IP e opzionalmente una o un intervallo di porte (solo per i
protocolli UDP e TCP).
## Cambia l'indirizzo di destinazione in 5.6.7.8
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8
## Cambia l'indirizzo di destinazione in 5.6.7.8, 5.6.7.9 oppure 5.6.7.10.
# iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 5.6.7.8-5.6.7.10
## Cambia l'indirizzo di destinazione del traffico web in 5.6.7.8, porta 8080.
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \
-j DNAT --to 5.6.7.8:8080
6.2.1. Redirezione
Esiste un caso specializzato di Destination NAT chiamato redirection
(redirezione), ed è semplicemente una comodità in più in quanto
esattamente uguale al DNAT effettuato però esclusivamente
sull'indirizzo associato all'interfaccia di ingresso.
## Invia i pacchetti diretti alla porta 80 verso il proxy (trasparente)
## squid
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j REDIRECT --to-port 3128
Si tenga presente che squid deve essere configurato in modo tale da
sapere che deve agire come proxy trasparente!
6.3. Mapping in dettaglio
Ci sono alcune sottigliezze nel NAT con cui la maggior parte delle
persone non avrà mai a che fare. Queste sono documentate qui di
seguito per i curiosi.
6.3.1. Selezione di indirizzi multipli in un intervallo
Se è dato un intervallo di indirizzi IP, l'indirizzo IP da usare è
scelto in base all'IP correntemente meno utilizzato per le connessioni
conosciute dalla macchina. Questo garantisce il load-balancing
primitivo.
6.3.2. Creare mapping NAT nullo
Si può utilizzare l'obiettivo `-j ACCEPT' per lasciare che la
connessione prosegua senza che avvenga alcuna operazione di NAT.
6.3.3. Comportamento Standard del NAT
Il comportamento standard è di alterare la connessione il meno
possibile entro i vincoli delle regole date dall'utente. Questo
significa che le porte non saranno rimappate a meno che non ce ne sia
bisogno.
6.3.4. Mapping implicito delle porte sorgenti
Anche quando il NAT non è richiesto per una connessione, la traduzione
della porta sorgente può avvenire implicitamente se un'altra
connessione è stata mappata sopra la nuova. Si consideri il caso del
mascheramento che è comune:
1. Una connessione è stabilita da una box 192.1.1.1 dalla porta 1024
verso www.netscape.com porta 80
2. Questa è mascherata dalla masquerading box per usare il suo
indirizzo IP sorgente (1.2.3.4).
3. La masquerading box prova a effettuare una connessione web con
www.netscape.com sulla porta 80 dall'indirizzo 1.2.3.4 (indirizzo
dell'interfaccia esterna) porta 1024.
4. Il codice NAT altera la porta sorgente della seconda connessione
ponendola a 1025, così le due non si intralciano.
Quando si ha questo mapping implicito della sorgente, le porte sono
divise in tre classi:
· Porte sotto la 512
· Porte tra la 512 e la 1023
· Porte 1024 e successive.
Una porta non sarà mai mappata implicitamente in una classe
differente.
6.3.5. Cosa succede quando il NAT fallisce
Se non esiste un modo per mappare unicamente una connessione come
richiede l'utente, allora sarà rifiutata. Questo accade anche ai
pacchetti che non possono essere classificati come appartenenti ad una
qualsiasi connessione, in quanto malformati o perché la box ha
esaurito la memoria, ecc.
6.3.6. Mapping multipli, sovrapposizioni, conflitti
Si possono avere regole NAT che mappano i pacchetti sullo stesso
intervallo; il codice del NAT è sufficientemente abile ad evitare
conflitti. Perciò pur avendo due regole che mappano gli indirizzi
sorgente 192.168.1.1 e 192.168.1.2 su 1.2.3.4 tutto funzionerà
correttamente.
In aggiunta si possono mappare gli indirizzi IP reali usati, sempre
che questi indirizzi attraversino la box che effettua il mapping.
Quindi se si ha una rete assegnata (1.2.3.0/24) e una rete interna che
usa questi indirizzi, e un'altra ancora che usa indirizzi internet
privati del tipo 192.168.1.0/24, si può effettuare tranquillamente il
NAT dei pacchetti con indirizzo sorgente 192.168.1.0/24 sulla rete
1.2.3.0, senza aver paura di eventuali sovrapposizioni.
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0/24
La stessa logica si può applicare agli indirizzi usati dalla NAT box
stessa: è così che funziona il masquerading (condividendo l'indirizzo
dell'interfaccia tra pacchetti mascherati e pacchetti reali
provenienti dalla box stessa).
Inoltre, si possono mappare gli stessi pacchetti su differenti
obiettivi, ed essi saranno suddivisi. Per esempio, se non si vuole
mappare nulla sopra 1.2.3.5, allora si può usare:
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254
6.3.7. Alterare la destinazione delle connessioni generate localmente
Il codice NAT consente di inserire delle regole nella catena OUTPUT ma
ciò non è pienamente supportato nel kernel 2.4 (potrebbe esserlo ma
richiederebbe una nuova opzione di configurazione, una fase di test e
lo sviluppo di una buona quantità di codice, quindi fino a quando
qualcuno non contatterà Rusty per realizzarlo esso non sarà
disponibile in tempi brevi.
L'attuale limitazione consente di cambiare la destinazione solo verso
la macchina locale (es. `j DNAT --to 127.0.0.1') e non verso una
qualsiasi altra macchina. In caso contrario le risposte non saranno
tradotte correttamente.
7. Protocolli speciali
Alcuni protocolli non amano subire il NAT. Per ciascuno di questi
protocolli bisognerebbe scrivere due estensioni, una per il
"connection tracking" e una per il NAT.
Nella distribuzione di netfilter ci sono al momento dei moduli per
ftp: ip_conntrack_ftp.o e ip_nat_ftp.o. Se si caricano questi moduli
(o se sono compilati nel kernel), ogni tipo di NAT effettuato sulle
connessioni ftp dovrebbe funzionare. Altrimenti, si potrà utilizzare
solo ftp passivo, e perfino questo potrebbe non funzionare
correttamente se si sta facendo qualcosa di più del semplice Source
NAT.
8. Avvertimenti riguardo il NAT
Se si sta effettuando il NAT su una connessione, tutti i pacchetti che
transitano in entrambe le direzioni (dentro e fuori la rete) devono
passare attraverso la NAT box, altrimenti il NAT non funzionerà
correttamente. In particolare il codice di "tracciamento" della
connessione si occupa di riassemblare i frammenti, quindi non solo il
tracciamento potrebbe non essere affidabile ma anche i pacchetti
potrebbero non passare del tutto, i frammenti infatti potrebbero
essere rifiutati.
9. Source NAT e Instradamento
Se si sta effettuando il SNAT, ci si vorrà assicurare che tutte le
macchine, verso cui sono diretti i pacchetti modificati, provvedano
poi a inviare i pacchetti di risposta alla NAT box. Ad esempio, se si
stanno mappando alcuni pacchetti in uscita utilizzando l'indirizzo
sorgente 1.2.3.4, il router esterno dovrà sapere che i pacchetti di
risposta (che avranno come destinazione 1.2.3.4) dovranno essere
inviati alla suddetta box. Ciò si può ottenere nei seguenti modi:
1. Se si sta effettuando il SNAT utilizzando l'indirizzo proprio della
box (dove il routing e tutto il resto funzionano correttamente)
allora non sarà necessario alcun intervento.
2. Se si sta effettuando il SNAT sfruttando un indirizzo non
utilizzato della LAN locale (ad esempio, si sta mappando
utilizzando 1.2.3.99, indirizzo libero della propria rete
1.2.3.0/24), la vostra NAT box dovrà rispondere alle richieste ARP
per questo indirizzo esattamente come fa per il proprio indirizzo:
la soluzione più semplice consiste nel creare un IP alias, ossia:
# ip address add 1.2.3.99 dev eth0
3. Se si sta effettuando il SNAT utilizzando un indirizzo
completamente differente, allora ci si dovrà assicurare che le
macchine che saranno raggiunte dai pacchetti modificati provvedano
ad instradarli verso la NAT box. Ciò già avviene se la NAT box è
il gateway di default, altrimenti sarà necessario notificare un
instradamento (se c'è un protocollo di routing attivo) oppure
aggiungere manualmente un instradamento in ogni macchina coinvolta.
10. Destination NAT nella stessa rete
Se si sta effettuando il portforwarding all'interno della stessa rete,
ci si dovrà assicurare che sia i pacchetti inviati sia i pacchetti in
risposta attraversino la NAT box (in questo modo potranno essere
alterati). Il codice NAT ora (sin dalla 2.4.0-test6) blocca il
pacchetto ICMP redirect in uscita, il quale viene prodotto quando il
pacchetto modificato utilizza la stessa interfaccia da cui è arrivato,
tuttavia il server ricevente cercherà comunque di rispondere
direttamente al client (il quale non riconoscerà la risposta).
Il caso classico è quello che vede lo staff interno cercare di
accedere al vostro web server `pubblico', il quale è attualmente
sottoposto al DNAT dall'indirizzo pubblico (1.2.3.4) verso una
macchina interna (192.168.1.1), come in questo caso:
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp --dport 80 -j DNAT --to 192.168.1.1
Una possibile soluzione consiste nell'utilizzare internamente un
server DNS che conosca l'indirizzo IP reale (interno) del vostro sito
web pubblico, e che provveda inoltre a inoltrare tutte le altre
richieste verso un server DNS esterno. Ciò significa che le
registrazioni sul vostro server web presenteranno correttamente gli
indirizzi IP interni.
L'altra possibile soluzione consiste nel far sì che la NAT box mappi
per queste connessioni l'indirizzo IP sorgente con il proprio,
ingannando in questo modo il server, il quale invierà le risposte
attraverso di esso. In questo caso si dovrebbe utilizzare (assumendo
che l'indirizzo IP interno della NAT box sia 192.168.1.250):
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
-p tcp --dport 80 -j SNAT --to 192.168.1.250
Siccome la regola PREROUTING viene eseguita per prima, i pacchetti
avranno già come destinazione il server web interno: si potranno
riconoscere quali sono stati internamente modificati in base agli
indirizzi IP sorgenti.
11. Ringraziamenti
Grazie prima di tutto alla WatchGuard, e a David Bonn, che hanno
creduto nell'idea di netfilter così tanto da darmi il loro supporto
mentre ci lavoravo.
E a tutti coloro che hanno sopportato i miei sproloqui affinché
potessi apprendere le bruttezze del NAT, e specialmente infine quelli
che hanno letto il mio diario.
Rusty.