NAT#
Il Network Address Translation (NAT) viene utilizzata per modificare le informazioni sugli indirizzi di rete negli header dei pacchetti durante il transito. Il NAT consente principalmente la traduzione degli indirizzi IP privati utilizzati all’interno di una rete locale in un indirizzo IP pubblico, permettendo a più dispositivi all’interno della rete locale di condividere un unico IP pubblico quando accedono a Internet. Per impostazione predefinita, tutti gli host all’interno della rete locale che accedono alla WAN tramite il firewall utilizzano il masquerade. Il masquerade è una forma di NAT che assegna automaticamente l’indirizzo IP di origine dei pacchetti in uscita all’indirizzo IP WAN del firewall. Questo garantisce che gli host interni che accedono a Internet appaiano ai server esterni come se provenissero dall’indirizzo IP pubblico del firewall.
Accedere alla pagina NAT nella sezione Firewall; questa pagina è organizzata in due schede: Regole e NETMAP e NAT helper.
La scheda Regole e NETMAP consente di configurare i seguenti tipi di regole NAT:
Si noti che queste regole NAT vengono applicate a tutti i protocolli di rete.
È possibile configurare anche le regole di NAT di destinazione (DNAT), solitamente chiamate port forward o port redirects, dalla pagina port forward.
La scheda NAT helper consente di abilitare o disabilitare i NAT helper:
SNAT#
Il Source NAT, spesso indicato come SNAT, modifica l’indirizzo IP di origine dei pacchetti in uscita. Viene comunemente utilizzato nelle reti in cui gli indirizzi IP privati vengono tradotti in un singolo indirizzo IP pubblico durante la comunicazione con reti esterne. SNAT garantisce che le risposte dai server esterni vengano instradate correttamente al dispositivo interno appropriato modificando l’indirizzo IP di origine dei pacchetti in uscita con l’indirizzo IP pubblico. Questo consente a più dispositivi interni di accedere a Internet utilizzando un indirizzo IP pubblico condiviso, migliorando la sicurezza e la scalabilità.
Esempio Si dispone di una piccola azienda con due indirizzi IP pubblici forniti dal proprio provider di servizi Internet (ISP). Si desidera utilizzare uno di questi IP (1.2.3.4) specificamente per il server di posta interno (192.168.1.33) al fine di migliorarne la reputazione e l’autenticazione del mittente. L’altro indirizzo IP verrà utilizzato per l’accesso generale a Internet.
Problema Per impostazione predefinita, tutto il traffico in uscita dalla rete utilizza lo stesso IP WAN, incluso il mail server. Questo può influire negativamente sulla reputazione del mail server, poiché gli spammer spesso utilizzano IP condivisi. Inoltre, potrebbero essere necessarie configurazioni specifiche per il mail server diverse da quelle per il resto del traffico internet.
Soluzione Configurare l’IP alias (1.2.3.4) sull’interfaccia WAN, quindi creare una regola SNAT (Static Network Address Translation) nel firewall per indirizzare tutto il traffico in uscita dal mail server verso l’indirizzo IP pubblico dedicato. La regola deve contenere l’indirizzo IP interno del mail server (192.168.1.33) come sorgente e l’indirizzo IP pubblico dedicato (1.2.3.4) come indirizzo di traduzione; la zona di uscita deve essere impostata su WAN; selezionare SNAT come azione.
Risultato Tutto il traffico in uscita proveniente dal server di posta verrà ora tradotto sull’indirizzo IP pubblico dedicato. Questo migliora la reputazione del server di posta e consente configurazioni specifiche adattate alle sue esigenze. Il traffico internet generale continuerà a utilizzare l’altro indirizzo IP pubblico.
Source NAT in uno scenario MultiWAN#
Se sono presenti più WAN e la regola SNAT riscrive su uno degli IP pubblici WAN, è necessario creare una regola MultiWAN oltre alla regola SNAT. Questa regola instraderà il traffico dall’indirizzo IP sorgente attraverso la WAN corretta con l’indirizzo IP pubblico.
Se non è stato ancora configurato, aggiungere una policy personalizzata che includa solo la WAN pertinente. Successivamente, creare una regola per applicare questa policy personalizzata al traffico proveniente dall’indirizzo IP interno (indirizzo sorgente) verso qualsiasi destinazione e protocollo.
MASQUERADE#
La regola di masquerade maschera tutto il traffico in uscita con l’indirizzo IP dell’interfaccia di uscita del firewall. Il traffico proveniente dagli host interni verso Internet viene automaticamente mascherato dal firewall. Masquerade può anche essere utilizzato per mascherare il traffico proveniente da una rete remota (ad esempio, VPN) con l’IP del firewall per evitare eventuali problemi di routing.
Esempio È necessario raggiungere un host sulla rete locale (instradata) dalla rete VPN (ad es. 192.168.7.0/24), ma l’host non ha un gateway configurato oppure ha un gateway diverso dal firewall.
Problema L’host non può raggiungere il dispositivo locale a causa dell’assenza di un gateway.
Soluzione Creare una regola NAT con azione di mascheramento per il traffico proveniente dalla VPN Network. Questo maschera il traffico dalla VPN network (192.168.7.0/24) verso la rete locale utilizzando l’indirizzo IP del firewall dell’interfaccia di destinazione. La regola deve contenere la VPN network (192.168.7.0/24) come sorgente e la rete interna degli host (192.168.1.0/24) come indirizzo di destinazione; la zona di uscita può essere lasciata vuota; selezionare MASQUERADE come azione.
Risultato L’host può raggiungere il dispositivo locale (ad esempio 192.168.1.78) come se la connessione provenisse dal firewall.
ACCEPT (disabilita NAT)#
Una regola ACCEPT disabilita il NAT (no-NAT) e consente di bypassare il processo NAT per traffico specifico. Questo è particolarmente utile quando si desidera evitare il masquerading WAN per destinazioni specifiche.
Esempio Il firewall è collegato a un router che, oltre a consentire l’accesso a Internet, permette anche di raggiungere reti private tramite connessioni CDN o tunnel IPsec. Per poter raggiungere le reti private remote, il traffico proveniente dalla rete locale deve uscire con il proprio indirizzo IP originale (senza riscrittura tramite masquerade).
Problema Le policy dei tunnel del router consentono il traffico solo tra la rete locale di NethSecurity e le reti di destinazione, ma tutto il traffico esce dal firewall con l’IP mascherato (IP WAN di NethSecurity). A causa del masquerading, la comunicazione diretta tra la LAN di NethSecurity e la rete remota non è possibile.
Soluzione: Creare una regola NAT (Network Address Translation) con ACCEPT nel firewall. Questa regola evita il masquerading per tutto il traffico verso la rete CDN, mantenendo invariato l’indirizzo IP sorgente locale. La regola dovrebbe includere la rete interna (192.168.1.0/24) come sorgente e la rete CDN (192.168.50.0/24) come indirizzo di destinazione.
Netmap#
Netmap è una tecnica NAT che offre una traduzione 1:1 a livello di rete senza modificare gli indirizzi dei singoli host. Questo significa che può mappare un’intera rete privata (ad esempio, 192.168.1.0/24) su un’altra rete (ad esempio, 10.5.6.0/24) in un’unica operazione, eliminando la necessità di configurare manualmente regole NAT individuali per ogni dispositivo.
Esempio 2 firewall, FW-A e FW-B, mantengono un tunnel VPN tra le reti A e B; le reti locali e remote si sovrappongono (192.168.1.0/24), il che rende impossibile instradare il traffico tra di esse. Tradurre le reti A e B su due reti alternative può risolvere il problema, evitando così la sovrapposizione delle reti.
Utilizziamo questo schema di traduzione.
Rete A: 192.168.1.0/24 -> viene tradotta in -> Rete ALT_A: 10.1.1.0/24
Rete B: 192.168.1.0/24 -> viene tradotta in -> Rete ALT_B: 10.2.2.0/24
Un host nella rete A che tenta di raggiungere un host nella rete B non deve contattare il vero IP, ma il suo indirizzo di rete tradotto (solo l’ultimo ottetto rimane invariato). Ad esempio, l’host 192.168.1.10 della rete A che vuole raggiungere 192.168.0.20 nella rete B deve invece contattare l’IP 10.2.2.20. Prima che la richiesta esca dal firewall FW-A, la sorgente del pacchetto verrà riscritta da FW-A come ALT_IP 10.1.1.10 per eliminare qualsiasi problema di routing nella rete B. Il processo inverso avverrà per i pacchetti di ritorno.
Soluzione Il problema può essere risolto utilizzando netmap per tradurre il traffico verso una rete privata diversa. Questo consente al traffico di essere instradato correttamente.
Come fare
Per consentire alla rete A di accedere a una risorsa nella rete B, sono necessarie due regole: una per il netmap di origine e una per il netmap di destinazione.
La prima regola, che agisce come una source netmap, specifica che tutto il traffico diretto verso la rete 10.2.2.0/24 (rete di destinazione) e proveniente dalla rete 192.168.1.0/24 (rete sorgente) verrà mappato sulla rete 10.1.1.0/24 (rete sorgente mappata).
La seconda regola funziona come una destination netmap, svolgendo un ruolo cruciale nel ricevere correttamente le risposte. È necessario che il traffico proveniente dalla rete 10.2.2.0/24 (rete sorgente) e destinato alla rete 10.1.1.0/24 (rete di destinazione) venga mappato sulla rete 192.168.1.0/24 (rete di destinazione mappata).
Risultato Tutte le richieste di traffico (e le relative risposte) dalla rete A alla rete B verranno instradate correttamente.
Nota
Se è necessario consentire le richieste dalla rete B verso la rete A, è necessario fare lo stesso nel firewall B.
Netmap sorgente#
La «source netmap» consente di determinare come deve cambiare la sorgente quando il traffico è diretto verso una destinazione specifica. Ad esempio, rete di destinazione 10.2.2.0/24, rete sorgente: 192.168.0.0/24, rete sorgente nattata: 10.1.1.0/24.
È possibile creare una regola di source netmap dall’interfaccia web all’interno della pagina NAT. Nella parte inferiore della pagina, fare clic sul pulsante Aggiungi NETMAP sorgente per creare una nuova regola. All’interno del drawer, compilare i campi come segue:
Nome: un nome per la regola
Rete di destinazione: la rete di destinazione in notazione CIDR, ad esempio 10.2.2.0/24 per l’esempio sopra
Rete di origine: la rete di origine, ad esempio 192.168.1.0/24
Rete mappata: la rete di origine tradotta, ad esempio 10.1.1.0/24
Nella sezione Impostazioni avanzate, è possibile specificare i dispositivi di input e output per la regola. Se il dispositivo non viene specificato, la regola verrà applicata a tutti i dispositivi.
Netmap destinazione#
La «destination netmap» consente di determinare come deve cambiare l’IP di destinazione quando il traffico proviene da una rete specifica. Ad esempio, rete sorgente 10.2.2.0/24, rete di destinazione: 10.1.1.0/24, rete di destinazione natted: 192.168.0.0/24.
È possibile creare una regola di destination netmap dall’interfaccia web all’interno della pagina NAT. Nella parte inferiore della pagina, fare clic sul pulsante Aggiungi NETMAP destinazione per creare una nuova regola. All’interno del drawer, compilare i campi come segue:
Nome: un nome per la regola
Rete di origine: la rete di origine in notazione CIDR, ad esempio 10.2.2.0/24
Rete di destinazione: la rete di destinazione, ad esempio 10.1.1.0/24
Rete mappata: la rete di destinazione tradotta, ad esempio 192.168.1.0/24
Nella sezione Impostazioni avanzate, è possibile specificare i dispositivi di input e output per la regola. Se il dispositivo non viene specificato, la regola verrà applicata a tutti i dispositivi.
Comandi CLI#
Per creare una regola netmap SOURCE dalla CLI
uci set netmap.r1=rule
uci set netmap.r1.name=source_nat
uci set netmap.r1.dest=10.2.2.0/24
uci set netmap.r1.map_from=192.168.1.0/24
uci set netmap.r1.map_to=10.1.1.0/24
è anche possibile specificare dispositivi di input/output opzionali in questo modo:
uci add_list netmap.r1.device_in='eth0'
uci add_list netmap.r1.device_out='tunrw1'
Quindi eseguire il commit e applicare:
uci commit netmap
ns-netmap
Per creare una regola netmap DESTINATION dalla CLI
uci set netmap.r2=rule
uci set netmap.r2.name=dest_nat
uci set netmap.r2.src=10.2.2.0/24
uci set netmap.r2.map_from=10.1.1.0/24
uci set netmap.r2.map_to=192.168.1.0/24
è anche possibile specificare dispositivi di input/output opzionali in questo modo:
uci add_list netmap.r2.device_in='tunrw1'
uci add_list netmap.r2.device_out='eth01'
Quindi eseguire il commit e applicare:
uci commit netmap
ns-netmap
/etc/init.d/firewall reload
Helper NAT#
I NAT helper sono meccanismi progettati per facilitare la comunicazione di alcuni protocolli che possono incontrare problemi quando utilizzati con il NAT di base. Alcuni protocolli comuni, come FTP, SIP o H.323, inseriscono indirizzi IP o numeri di porta all’interno del payload dei dati, il che può creare problemi con il NAT standard.
I NAT helper, noti anche come Application Layer Gateway (ALG), operano a livello applicativo. Il loro ruolo principale è modificare i dati specifici del protocollo, come indirizzi IP o porte incorporati nei pacchetti, garantendo che questi protocolli funzionino correttamente durante il transito attraverso il NAT.
Ad esempio, in FTP, i NAT helper modificano gli indirizzi IP e le porte all’interno dei pacchetti di controllo e dati FTP, consentendo una corretta attraversamento NAT per le connessioni FTP. Allo stesso modo, i NAT helper per SIP e altri protocolli garantiscono che i dispositivi che utilizzano questi protocolli possano stabilire connessioni attraverso i confini NAT senza problemi.
NethSecurity fornisce diversi tipi di NAT helper, tutti disabilitati per impostazione predefinita. Se necessario, è possibile abilitare specifici helper tramite l’interfaccia web.
Durante la configurazione dell’helper, l’interfaccia può mostrare alcuni parametri tipici del protocollo coinvolto. Questi parametri sono precompilati con i valori predefiniti più comunemente utilizzati. Poiché i parametri dipendono dal tipo di protocollo, variano sia per numero che per tipologia a seconda dell’helper (alcuni helper non mostrano alcun parametro).
Dopo qualsiasi modifica, il firewall notificherà se è necessario un riavvio. Questo avviene tipicamente quando un helper viene disabilitato o modificato (se è già attivo).
Quando alcuni helper sono abilitati, gli helper correlati vengono caricati automaticamente nel kernel come dipendenze. Ad esempio, se nf_nat_ftp è abilitato, l’helper correlato nf_conntrack_ftp verrà caricato automaticamente nel kernel. Per quell’helper, l’interfaccia web mostrerà Caricato con un’icona informativa per notificare l’utente.