9.1 Dalla teoria alla pratica

Passando dalla teoria alla pratica, occorre prima di tutto parlare in maniera un pochettino più approfondita dei target di default messi a disposizione dalla tabella di NAT.

• SNAT: serve per modificare il mittente di un pacchetto (l'indirizzo ip sorgente). Viene utilizzato nella catena di POSTROUTING proprio perché il cambiare il mittente non interferisce sulla scelta dell'interfaccia da utilizzare per raggiungere il destinatario. Consente anche di modificare manualmente la porta sorgente di un pacchetto. Attenzione! Funziona solo con indirizzi ip statici!
• DNAT: serve per modificare il destinatario di un pacchetto (l'indirizzo ip destinatario). Viene utilizzato nella catena di PREROUTING in quanto la modifica deve essere effettuata prima di decidere da che parte fare uscire il pacchettino. E' possibile inoltre specificare una diversa porta di destinazione.
• MASQUERADE: è un tipo particolare di SNAT: fa in modo che i pacchettini abbiano come mittente l'indirizzo IP della interfaccia di rete dalla quale usciranno. Si utilizza nella tabella di POSTROUTING (modifica il mittente) e viene utilizzato al posto dello SNAT su interfacce con IP assegnato dinamicamente, ad esempio tramite dhcp o bootp.
• REDIRECT: è una versione semplificata del DNAT mantenuta più che altro per motivi di compatibilità e fa in modo che il pacchettino venga rediretto sulla macchina locale (127.0.0.1) ad una porta specifica. Equivale a qualcosa del tipo: -j DNAT --to 127.0.0.1:porta <--> -j REDIRECT --to-ports porta.

Tornando invece al nostro esempio (presentato nei paragrafi sul filtraggio), è per noi indispensabile utilizzare il NAT in quanto:

• dobbiamo ``deviare'' tutti le connessioni web verso internet sul nostro proxy server che si trova nella dmz (transparent proxy).
• dobbiamo fare in modo che la nostra rete interna che utilizza indirizzi ip di classe 192.168.200.x (indirizzi per reti private) possa navigare su internet.

Avendo però spesso a che fare con reti di discrete dimensioni dove il dhcp è raramente utilizzato, mi piace aggiungere alcune regole per rendere le macchine ``indipendenti'' dalle modifiche del provider di turno o eventuali riconfigurazioni della rete (vi è mai capitato di dover cambiare l'ip del dns su n macchine diverse, dove n tende ad infinito?).

Per fare questo normalmente si possono utilizzare diversi approcci:

• Se la rete è divisa in diverse sottoreti (subnet), si possono ``inventare'' due indirizzi ip che non risiedano su nessuna delle nostre reti ed impostare tutti i client per utilizzare quegli indirizzi ip come dns primario e secondario.
• Si possono semplicemente deviare tutti i pacchetti destinati ad un dns verso il dns reale (c'è il problema del dns secondario, però).
• Semplicemente ignorare il problema inizialmente ed in caso di cambio di ISP aggiungere due regole per deviare il traffico sui nuovi dns.

Vediamo quindi le nostre prime regole di NAT:

77: iptables -t nat -A PREROUTING -p tcp -i eth0 --dport www -j DNAT --to nostro.proxy.server:8080
78: iptables -t nat -A POSTROUTING -o eth2 -s 192.168.200.0/24 -j SNAT --to 123.45.68.1

Attenzione però che proxy server come squid devono essere configurati per poter accettare connessioni deviate in questo modo, in quanto non seguono perfettamente lo standard utilizzato dai proxy (leggete la documentazione di squid!).

Tornando a parlare delle regole, la seconda dice di modificare il mittente (l'indirizzo ip sorgente) dei pacchetti uscenti da eth2 e provenienti dalla nostra LAN (192.168.200.0/24) con l'indirizzo ip esterno del nostro firewall.

A proposito di queste due regole ci sono alcune cose importanti da dire:

• Prima di tutto, nella prima regola si è reso necessario indicare la scheda di rete sorgente in modo da non deviare le richieste del nostro proxy server. Per la cronaca: quando facciamo una richiesta al nostro proxy server, questo se non ha le pagine richieste in cache dovrà collegarsi al server web richiesto, e dobbiamo quindi stare attenti a non deviare anche le richieste provenienti dal proxy (si creerebbe una sorta di circolo vizioso (loop) né molto bello né molto positivo per la salute della nostra rete).
• Nella seconda regola, invece, è importante fare in modo che soltanto i pacchetti provenienti dalla nostra rete interna (e non dalla DMZ!) vengano modificati e soltanto quelli uscenti verso internet (quelli destinati al nostro proxy non devono essere toccati: saremo così in grado di fare un minimo di statistiche sui siti più interessanti per i nostri utenti).
• Nella seconda regola, è fondamentale fare in modo che i pacchetti abbiano come mittente uno degli indirizzi ip esterni del firewall. Per chi si accontenta di poche parole, basti dire che in caso contrario non funzionerebbe. Per tutti gli altri, invece, il motivo sta nell'arp, address resolution protocol. Ovvero, se l'indirizzo ip non fosse uno di quelli del firewall (aggiunti con ip o ifconfig, per intenderci), il firewall non risponderebbe alle query ARP, ed i pacchetti uscirebbero felici dalla rete ma il gateway di default del nostro firewall non sarebbe in grado di rimandare i pacchetti indietro. Come sempre, linux lascia la massima libertà: sta all'amministratore evitare di farsi male con errori di questo tipo.
• Riferendosi al funzionamento del SNAT come prima descritto, a volte (in reti particolarmente affollate) potrebbe essere indispensabile utilizzare più indirizzi ip per effettuare lo SNAT (il numero di porte disponibili ed utilizzabili su un host per fare il giochettino descritto è abbastanza limitato). Il target fortunatamente consente di indicare più indirizzi ip (date un'occhiata al manuale di iptables).

  L'esperienza però mi insegna che in tali reti si supererebbe molto prima il numero massimo di connessioni tracciabili rispetto alle porte disponibili. Per aumentare questo numero, basta dare un:

    echo 16384 > /proc/sys/net/ipv4/ip_conntrack_max
  

  o, in maniera del tutto equivalente, scrivere qualcosa come

  net.ipv4.ip_conntrack_max=16384
  

  nel file /etc/sysctl.conf. Comunque sia, tenete presente che già una rete di 100-200 computer potrebbe aver bisogno di essere in grado di tracciare più connessioni, mentre non mi è ancora capitato di dover utilizzare più di un indirizzo ip in uscita.

  Il kernel comunque, vi avviserà in caso fosse necessario aumentare questi limiti, con un messaggio nei log per ogni connessione scartata.

• Nell'ultima regola, infine, se avessimo avuto a disposizione una connessione dial-up (come isdn) o tramite adsl con indirizzi ip assegnati dinamicamente, si sarebbe dovuto usare come target ``MASQUERADE'', senza però specificare alcun indirizzo ip sorgente. Attenzione! Lo SNAT proprio non funziona su interfacce con ip dinamici assegnati! Potete vedere un esempio di come utilizzare il target MASQUERADE in uno dei paragrafi introduttivi...
• Per quanto riguarda le regole di NAT e filtraggio, è fondamentale notare (per poter ottenere un firewall funzionante) che le regole di firewalling, inserite nella tabella di filter, vedranno i pacchetti con i loro indirizzi reali. Nel caso di DNAT, per esempio, il filtro vedrà pacchetti con la destinazione modificata (in questo caso, il proxy server). In caso invece di SNAT, il filtro vedrà come mittente l'indirizzo reale del mittente (non quello modificato), come se il codice di filtraggio fosse inserito dopo la catena di PREROUTING ma prima della catena di POSTROUTING.

80: iptables -t nat -A PREROUTING -p tcp --dport domain -j DNAT --to nostro.dns
81: iptables -t nat -A PREROUTING -p udp --dport domain -j DNAT --to nostro.dns

83: iptables -t nat -A PREROUTING -p tcp -d un.dns --dport domain -j DNAT --to nostro.dns
84: iptables -t nat -A PREROUTING -p udp -d un.dns --dport domain -j DNAT --to nostro.dns