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 ______________________________________________________________________ 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 . · Grazie a The Samba Team e SGI . · Grazie a Harald Welte . Per la mailing list ufficiale di netfilter visitare Samba Listserver . 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 . 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.