Iptables
Nat da dentro a dentro
Quando si usa un NAT da fuori a dentro per esporre sull' ip pubblico alcune porte di un server che si trova in LAN, il problema e` che dalla LAN queste porte non sono accessibili se si tenta di connettersi all' ip pubblico. Cioe` un client in LAN che provi a connettersi al server usando il suo ip pubblico (che ovviamente e` in realta` attestato su una interfaccia pubblica del firewall) non riuscira` a connettersi.
La soluzione "pulita" e` avere un DNS interno che risolve il nome sull' IP privato del server, ma non sempre e` possibile farlo. La soluzione "sporca" e` quella di fare il NAT in modo che anche dalla LAN una connesione all' ip pubblico vada a buon fine. Il limite di questa soluzione e` che le connessioni che vengono dalla LAN sembreranno provenire dal firewall stesso e non dal client che realmente ha iniziato la connessione. Per fortuna quelle dall'esterno manterranno il loro IP sorgente vero, quindi il server sara` ancora in grado di distinguere le connessioni originanti dall'esterno da quelle originanti dall'interno.
Facciamo un esempio:
- Il firewall ha ip pubblico 100.100.100.100 e ip privato 192.168.1.1
- Il server di posta ha ip privato 192.168.1.2
- Il server di posta e` accessibile sulla porta 25 dall'esterno tramite una regola di NAT sul firewall, che dice che il traffico entrante dall'esterno diretto alla porta 25 dell' ip pubblico del firewall (100.100.100.100) va diretto alle 25 del mail server (192.168.1.2)
Un client che si trova nella LAN (129.168.1.0/24, per dire) vuole mandare una mail: per farlo puo` iniziare una connessione con il mail server a 192.168.1.2, ma NON PUO` normalmente iniziare una connessione verso 100.100.100.100. Il nat infatti si incasina e la connessione resta appesa.
Vediamo come rendere possibile una connessione da dentro la LAN all'indirizzo pubblico 100.100.100.100. Per farlo occorrono due regole di NAT: una e` quella "classica" del NAT da fuori a dentro, e l'altra e` un "helper" che aiuta le connessioni da dentro a dentro ad essere comunque gestite.
# NAT "classico" da fuori a dentro iptables -t nat -A PREROUTING -d 100.100.100.100 -p tcp --dport 25 -j DNAT --to 192.168.1.2 # Regola aggiunta per gestire il NAT da dentro a dentro iptables -t nat -A POSTROUTING -d 192.168.1.2 -s 192.168.1.0/24 -p tcp --dport 25 -j SNAT --to 192.168.1.1
Ovvero, in altri termini:
iptables -t nat -A PREROUTING -d <ip pubblico del firewall> -p tcp --dport <porta> -j DNAT --to <ip del mail server in LAN> iptables -t nat -A POSTROUTING -d <ip del mail server in LAN> -s <classe di ip della LAN/netmask> -p tcp --dport <porta> -j SNAT --to <ip privato in LAN del firewall>
Non e` banalissima da capire, ma in pratica il trucco e` che le connessioni dalla LAN verso l' ip pubblico del firewall vengono ributtate dentro la LAN dopo che il source address e` stato modificato per essere quello del firewall stesso (lato LAN).
Nota bene: tutto questo non funziona se nella prima delle due regole si specifica una interfaccia di ingresso (che e` quella WAN del firewall) in quanto in questo caso non avviene MAI il NAT dalla LAN alla LAN, e il pacchetto destinato alla porta 25 verrebbe semplicemente "ricevuto" dal firewall stesso, il quale non ha nessun mail server a bordo e comunque non e` il destinatario che vorremmo raggiungere.