Comprendere il NAT su Sophos Firewall: SNAT, DNAT, MASQ e PAT

Il NAT modifica gli indirizzi o le porte di un pacchetto. Non stabilisce se la connessione è consentita e non crea alcuna rotta. Affinché il flusso funzioni, la regola NAT, la regola firewall, il routing e il percorso di ritorno devono essere coerenti.

Il punto di partenza più rapido non è quindi chiedersi «Quale tipo di NAT mi serve?», bensì: Quale indirizzo o porta deve cambiare tra ingresso e uscita? Se non c’è una risposta chiara, la soluzione riguarda di solito il routing o la regola firewall, non il NAT.

⚠️ Una regola NAT non autorizza il traffico. Se la regola firewall consente il traffico, ma nessuna regola NAT corrisponde, SFOS inoltra il pacchetto senza traduzione. Se manca la regola firewall corrispondente, il pacchetto viene scartato e l’evento viene registrato.

Quando è opportuno utilizzare il NAT?

• I client LAN hanno bisogno di accesso a Internet: di solito SNAT con MASQ.
• Un servizio interno deve essere raggiungibile tramite un indirizzo pubblico: DNAT; per HTTP/HTTPS, valutare prima WAF.
• Le porte esterne e interne differiscono: tradurre il servizio con Translated service (PAT).
• I client interni utilizzano il nome pubblico di un server interno: preferire lo Split DNS oppure utilizzare una Loopback Rule mirata.
• Reti non sovrapposte comunicano attraverso una VPN site-to-site: normalmente bastano il routing e le regole firewall, senza NAT.
• Le reti si sovrappongono: pianificare il NAT in base al tipo di VPN; non improvvisare con una regola MASQ generica.
• Occorre solo consentire o bloccare l’accesso: modificare la regola firewall; non creare una regola NAT.

Per pubblicare concretamente un server, Pubblicare un server con DNAT su Sophos Firewall illustra l’assistente, la regola manuale, l’hardening, la messa in produzione e il rollback. Questo articolo spiega il modello NAT, così da poter leggere queste regole e circoscrivere gli errori.

Altri casi speciali strettamente correlati includono NAT64 con Direct Web Proxy, Proxy ARP per ulteriori indirizzi IPv4 pubblici e NAT per problemi IPsec.

Come interpretare correttamente Original e Translated

In Rules and policies > NAT rules > Add NAT rule, Original descrive il pacchetto quando arriva al firewall. Translated descrive la modifica applicata da SFOS.

La regola viene selezionata in base a questi campi:

• Original source
• Original destination
• Original service
• Inbound interface
• Outbound interface

I campi Translated source (SNAT), Translated destination (DNAT) e Translated service (PAT) rappresentano il risultato, non ulteriori criteri di corrispondenza. Le regole NAT vengono valutate dall’alto verso il basso; prevale la prima regola corrispondente.

Le regole NAT sono disponibili per IPv4 e IPv6. Prima di crearne una, selezionare la famiglia di indirizzi in Rules and policies > NAT rules; gli indirizzi IPv4 degli esempi non vanno inseriti in una regola IPv6. Add NAT rule > New NAT rule apre la configurazione manuale. Le nuove regole sono abilitate per impostazione predefinita. Rule position offre Top e Bottom; in seguito è possibile modificarne l’ordine tramite trascinamento. Prima di Save, verificare criteri e posizione per evitare che la nuova regola intercetti involontariamente traffico di produzione.

Due esempi di pacchetti

Un client 10.10.10.80 si connette a 198.51.100.20:443 tramite Port2. Una regola SNAT può modificare soltanto la sorgente impostandola su MASQ. La destinazione e il servizio rimangono Original.

Quando si pubblica un servizio, un client esterno si connette a 203.0.113.10:5555. DNAT cambia la destinazione in 172.16.16.10; PAT cambia il servizio in 443. La regola risultante è:

• Original destination: 203.0.113.10
• Original service: TCP 5555
• Translated destination (DNAT): 172.16.16.10
• Translated service (PAT): TCP 443

PAT non è quindi un tipo di traduzione degli indirizzi distinto, da affiancare a SNAT e DNAT. È la traduzione delle porte o dei servizi all’interno di una regola NAT.

SNAT e MASQ per il traffico in uscita

SNAT modifica l’indirizzo sorgente. Una tipica regola LAN-WAN utilizza la rete interna come Original source, l’interfaccia WAN come Outbound interface e MASQ come Translated source. La destinazione e il servizio rimangono impostati su Original oppure vengono limitati all’ambito effettivamente necessario.

Per impostazione predefinita, MASQ utilizza l’indirizzo dell’interfaccia di uscita. La configurazione di fabbrica include la regola Default SNAT IPv4 per questo scopo. Se non serve, Sophos consiglia di disabilitarla piuttosto che eliminarla: può essere ricreata quando viene creata o aggiornata un’interfaccia WAN.

Dopo una migrazione da SFOS 17.5 o precedente, in fondo alla tabella può comparire un’ulteriore regola SNAT predefinita disabilitata. Serve a sostituire le regole Linked MASQ eliminate durante la pulizia e non va confusa con una regola di fabbrica attiva.

Più client o server interni possono condividere lo stesso IP sorgente pubblico: SFOS distingue le connessioni tramite numeri di porta differenti. Questa associazione delle porte sorgente non equivale all’inoltro di un servizio DNAT verso un server.

Creare una regola SNAT LAN-WAN indipendente

Una regola SNAT indipendente può servire più regole firewall. Verificare prima regole NAT esistenti, rotta, interfaccia di uscita e percorso di ritorno, salvando lo stato precedente con ID e posizioni. L’esempio consente solo HTTPS dalla rete client a una destinazione di test specifica; sostituire tutti gli indirizzi e le interfacce con i propri valori.

1. Aprire Rules and policies > NAT rules, selezionare IPv4, quindi Add NAT rule > New NAT rule. Impostare Rule name, ad esempio LAN-Web-Standalone-MASQ. In Rule position scegliere Top o Bottom, poi trascinare consapevolmente la regola sopra quelle più generali corrispondenti; non metterla automaticamente al primo posto.
2. Impostare Original source su Clients_LAN (10.10.10.0/24), Original destination su un oggetto host per 198.51.100.20 e Original service su HTTPS. L’indirizzo di documentazione non è un vero server di test. Per l’accesso generale a Internet si può ampliare deliberatamente la destinazione, limitando comunque i servizi a quelli necessari.
3. Impostare Translated source (SNAT) su MASQ, Translated destination (DNAT) e Translated service (PAT) su Original. Selezionare l’effettiva interfaccia LAN in Inbound interface, nell’esempio Port2, e quella WAN in Outbound interface, qui Port1. Selezionare Save e annotare il NAT Rule ID.
4. In Rules and policies > Firewall rules, scegliere IPv4 > Add firewall rule > New firewall rule se manca una regola di autorizzazione adatta. Impostare nome e posizione, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks sulla stessa destinazione e Services HTTPS. Configurare le impostazioni di sicurezza appropriate e Log firewall traffic, quindi Save. Non creare un’altra Linked NAT Rule.
5. Aprire una nuova connessione HTTPS alla propria destinazione di test e chiuderla normalmente. Confrontare entrambi i Rule IDs in Log Viewer; Packet capture deve mostrare in uscita l’indirizzo sorgente WAN previsto. Se la regola NAT è errata, controllare prima quelle superiori; se mancano risposte, verificare routing e ritorno. Per il rollback, disabilitare solo le regole aggiunte e ripristinare le posizioni modificate; non rimuovere una regola di autorizzazione condivisa. Verificare lo stato precedente con una nuova sessione.

Creare una regola LAN-WAN con NAT collegato

Per consentire un flusso IPv4 ben delimitato, è possibile collegare SNAT durante la creazione della regola firewall. Verificare prima se una regola SNAT esistente traduce già il flusso come richiesto; in tal caso non serve un’altra Linked NAT Rule. La rotta e il percorso di ritorno devono essere corretti indipendentemente dal NAT.

1. Aprire Rules and policies > Firewall rules, selezionare IPv4 e creare una regola tramite Add firewall rule > New firewall rule. Scegliere un nome chiaro, come LAN-Web-Out, e una posizione adeguata; impostare Action su Accept e attivare Log firewall traffic.
2. Impostare Source zones su LAN e limitare Source networks and devices alla rete dei client che richiede l’accesso. Ad esempio, usare un oggetto di rete Clients_LAN per 10.10.10.0/24; adattare il nome e la subnet al proprio ambiente. Impostare Destination zones su WAN. In Destination networks, selezionare le destinazioni necessarie e, in Services, solo i servizi richiesti, come HTTPS per questo flusso web. Any non è un requisito generale. Considerare separatamente DNS e gli altri servizi necessari.
3. Selezionare Create linked NAT rule. Assegnare alla regola NAT un nome distinto, come LAN-Web-MASQ, e una posizione adeguata. Impostare Translated source (SNAT) su MASQ: il flusso deve usare l’indirizzo dell’effettiva interfaccia di uscita, mentre la regola firewall continua a limitare sorgenti, destinazioni e servizi.
4. Selezionare prima Save nella configurazione del NAT collegato, poi nuovamente Save per salvare la regola firewall. Salvare soltanto la finestra NAT interna non completa la procedura.
5. Controllare la regola firewall in Firewall rules e la regola SNAT collegata in NAT rules; annotare entrambe le voci e i rispettivi Rule IDs. Verificare separatamente l’ordine in ciascuna tabella. Una regola NAT corrispondente posizionata più in alto può avere la precedenza; il collegamento non garantisce la priorità.
6. Da un client autorizzato, stabilire una connessione realmente nuova alla destinazione e al servizio consentiti, quindi chiudere normalmente la connessione di test per consentire la generazione del log di sessione. Filtrare il flusso in Log Viewer e confrontare Firewall Rule ID e NAT Rule ID con gli ID annotati. Se l’ID firewall è errato, verificare prima i criteri e l’ordine delle regole firewall; se l’ID NAT è errato, controllare prima le regole NAT superiori. La sola presenza di entrambe le voci non conferma che l’accesso a Internet funzioni.

Limitazioni importanti di SNAT

Oltre a MASQ, Translated source (SNAT) può utilizzare un singolo IP o un intervallo IP. La descrizione SFOS 22 indica esplicitamente qualsiasi IP assegnato a un’interfaccia come sorgente e Add per creare un oggetto IP/intervallo. La descrizione dei tipi NAT in SFOS 23 continua a includere singoli IP e intervalli; l’assenza di queste frasi nella descrizione Add non significa che il supporto sia stato rimosso. L’indirizzo fisso deve essere raggiungibile nell’ambiente e compatibile con il ritorno previsto.

• Un intervallo configurato in Translated source non crea una corrispondenza uno-a-uno fissa. SFOS utilizza il prossimo indirizzo disponibile nell’intervallo.
• Un’interfaccia pubblica appartenente a un bridge non può essere utilizzata come interfaccia SNAT. Se un’interfaccia in uso diventa successivamente membro di un bridge, SFOS elimina le regole SNAT interessate.
• Override source translation for specific outbound interfaces consente a una regola SNAT di utilizzare sorgenti tradotte diverse a seconda dell’interfaccia di uscita. Utilizzare Expand per aggiungere altre associazioni.
• Per le VPN route-based con Any come subnet locali e remote, o con una configurazione dual-IP, MASQ può utilizzare l’indirizzo XFRM come sorgente all’interno del tunnel. L’indirizzo WAN rimane visibile nell’intestazione esterna del tunnel.

Prima di modificare un bridge o i pool SNAT in produzione, documentare le regole interessate e poi testarle con un flusso di traffico realmente nuovo.

DNAT, PAT, Loopback e Reflexive Rules

DNAT cambia l’indirizzo di destinazione. PAT cambia anche il servizio o la porta richiesti. Il protocollo deve rimanere lo stesso: una porta TCP può essere tradotta in un’altra porta TCP e una porta UDP in un’altra porta UDP, ma TCP non può essere tradotto in UDP.

Se sono selezionati più servizi originali o Any, Translated service (PAT) deve essere Original. Un inoltro di porta univoco usa un servizio originale specifico e un servizio tradotto specifico. Translated destination (DNAT) può essere un indirizzo IP o un FQDN. La traduzione dei servizi consente una singola porta di destinazione oppure lo stesso numero di porte originali e tradotte: ad esempio, più porte di un unico servizio originale verso una porta (many-to-one), o insiemi di porte di uguale dimensione (many-to-many). Per many-to-many il numero di porte deve essere uguale; più servizi originali selezionati separatamente non consentono invece la traduzione PAT. Il protocollo deve sempre rimanere lo stesso.

La regola del firewall corrispondente a DNAT

Per il traffico in entrata, SFOS determina prima la regola DNAT corrispondente. Valuta quindi la regola firewall. Questo si traduce in una mappatura insolita ma importante:

• Destination zone: la zona della destinazione interna dopo DNAT, come DMZ.
• Destination networks: l’indirizzo di destinazione pubblico prima di DNAT.
• Services: senza PAT, il servizio richiesto dal client. Con PAT, l’esempio ufficiale di Sophos include sia il servizio originale sia quello tradotto nella regola firewall.

Nella direzione inversa, la regola del firewall viene valutata prima; SFOS quindi applica la regola SNAT corrispondente.

Una regola NAT non sostituisce questa regola firewall. Per una configurazione DNAT completa, con restrizioni sulle sorgenti, IPS, registrazione e un test di accettazione dall’esterno, consultare la guida DNAT.

Loopback Rule

Una Loopback Rule può consentire ai client interni di connettersi attraverso l’indirizzo IP pubblico o il FQDN pubblico. Split DNS è spesso più trasparente: all’interno della rete, lo stesso nome si risolve direttamente nell’indirizzo interno del server, evitando la necessità di hairpin NAT.

Il Server Access Assistant crea una Loopback Rule solo se si seleziona un’interfaccia WAN del firewall come indirizzo pubblico e si imposta External source networks and devices su Any. Se si inserisce un indirizzo IP pubblico o si restringono maggiormente le sorgenti esterne, questa Loopback Rule automatica non viene creata.

Nella configurazione DNAT manuale, Create loopback rule è un’opzione separata. La regola DNAT di partenza deve usare Original source Any, Translated source (SNAT) MASQ e Translated destination (DNAT) diversa da Original. Non sono i campi dell’assistente. Non eliminare una restrizione delle sorgenti esterne solo per ottenere loopback: valutare prima Split DNS o una regola interna pianificata separatamente. Dopo il salvataggio, testare separatamente accesso interno e restrizioni esterne.

Reflexive Rule

Una Reflexive Rule crea una regola SNAT inversa per una regola DNAT. Inverte i criteri di corrispondenza e può tradurre il traffico in uscita del server utilizzando la corrispondente identità pubblica. Se la destinazione originale non è un indirizzo IP oppure viene tradotta, la Reflexive Rule utilizza MASQ come sorgente tradotta.

Durante la creazione manuale di DNAT, Create reflexive rule genera questa regola speculare; Create loopback rule è indipendente. Le regole generate usano ID e nome della regola iniziale, ma restano separate. Nel rollback, identificare e disabilitare ogni voce generata separatamente, poi verificare con nuove connessioni interne ed esterne.

Le Loopback Rules e le Reflexive Rules rimangono regole separate. La modifica o l’eliminazione della regola DNAT originale non le aggiorna né le rimuove automaticamente. Dopo aver cambiato l’indirizzo pubblico, la destinazione interna o il servizio, controllare separatamente le regole derivate.

Se una regola DNAT distribuisce il traffico tra più destinazioni interne, SFOS le considera disponibili in assenza di Health check. Il controllo è obbligatorio per First alive; per gli altri metodi di distribuzione, abilitarlo esplicitamente e configurare ICMP o TCP in base al servizio, in modo che SFOS non invii nuovo traffico a un server guasto.

Scegliere la distribuzione fra più destinazioni DNAT

Scegliere Load balancing method in base al comportamento richiesto, non solo al numero di server:

• Round robin: le connessioni vengono inviate in sequenza. Con destinazioni da 10.10.10.1 a 10.10.10.3, la quarta richiesta torna a .1. Serve a distribuire senza persistenza della sessione.
• First alive: tutte le richieste vanno al primo server disponibile; gli altri sono di riserva. L’Health Check determina quando passare al successivo.
• Random: selezione casuale, senza associazione fissa di un client.
• Sticky IP: un hash della sorgente e della destinazione originale associa la coppia a un server. Con Health Check abilitato, una destinazione disponibile subentra in caso di guasto. Quando torna il server originale, vi tornano solo le nuove connessioni; le sessioni esistenti rimangono attive.
• One-to-one: prima destinazione originale alla prima tradotta, seconda alla seconda e così via. Le due liste devono contenere lo stesso numero di indirizzi IP. È una mappatura DNAT fissa, non un’assegnazione da un pool SNAT.

Per Health check, scegliere Probe method ICMP o TCP e, per TCP, la porta effettiva da controllare. Probe interval imposta l’intervallo fra controlli, Response time-out il tempo massimo di risposta e Deactivate host after il numero di tentativi falliti. Un ping conferma la raggiungibilità dell’host, non il funzionamento del servizio web. Adattare i tempi al servizio: valori troppo sensibili possono escludere inutilmente una destinazione lenta. Prima della messa in produzione, verificare la distribuzione con nuove connessioni e il comportamento durante un guasto e un ripristino pianificati. Salvare metodo e valori precedenti per il rollback.

Verificare i conflitti di porta prima della pubblicazione

Prima di inoltrare HTTPS, annotare le porte effettive di WebAdmin, User Portal e VPN Portal in Administration > Admin and user settings. Non dedurre quale servizio usa 443 da una vecchia guida NAT. WebAdmin e User Portal richiedono ciascuno una porta esclusiva. Risolvere prima i conflitti con un altro IP pubblicato o un’altra porta esterna; non cambiare le porte di gestione senza preparazione. Se necessario, assicurare un accesso di gestione indipendente e poi verificare separatamente portali, client VPN e accesso DNAT esterno. La guida DNAT illustra la pubblicazione.

Linked NAT Rule e Server Access Assistant

Una Linked NAT Rule è sempre una regola SNAT collegata a una regola firewall. Continuano ad applicarsi tutti i criteri di corrispondenza della regola firewall, compresi gli utenti e gli orari. Nella regola NAT si possono modificare solo le sorgenti tradotte e le associazioni di sorgente tradotta specifiche per ciascuna interfaccia.

Il collegamento non modifica il normale ordine delle regole NAT: una regola NAT indipendente posizionata più in alto nella tabella può corrispondere prima. Se una regola SNAT generica copre già lo stesso traffico, Sophos sconsiglia di aggiungere un’altra Linked NAT Rule. In modalità MTA, SFOS ne crea una automaticamente.

Il Server access assistant (DNAT) crea una regola DNAT, una Reflexive Rule e una regola firewall. Aggiunge una Loopback Rule solo per la combinazione descritta di interfaccia WAN e sorgente esterna Any. Posiziona le regole in cima alle tabelle e le abilita. Controllare quindi sorgenti, posizione, regole aggiuntive generate e uso degli alias IP. Per un alias IP, l’assistente imposta inizialmente l’interfaccia fisica come sorgente tradotta nelle Reflexive o Loopback Rules; per usare l’indirizzo alias, selezionare manualmente l’IP Host corrispondente.

Pulire con cautela le regole Linked MASQ migrate

Dopo una migrazione può apparire un avviso sotto il filtro. Delete linked NAT rules (only MASQ; Destination: WAN) elimina solo le regole collegate con sorgente tradotta MASQ la cui regola firewall usa esclusivamente la zona di destinazione WAN. Non è una pulizia priva di rischi: le condizioni relative agli utenti e agli orari, insieme all’ordine precedente, possono far parte del comportamento voluto.

Salvare prima configurazione, ID e flussi interessati. La regola disabilitata Default SNAT IPv4 o Default SNAT IPv6, oppure una regola SNAT indipendente progettata appositamente, deve fornire la traduzione necessaria come sostituta delle regole migrate, nella posizione corretta. Verificare la regola sostitutiva e le restrizioni firewall, abilitarla e confrontare nuovi flussi consentiti e vietati prima di eliminare le vecchie regole. In caso di differenze, ripristinare regole e ordine salvati. Understood. Don’t delete rules conserva le regole e nasconde definitivamente l’avviso; X lo nasconde temporaneamente. In caso di dubbio, documentare prima di eliminare.

Distinguere NAT, VPN e SD-WAN

Il NAT non cambia una decisione di routing. Anche dopo la traduzione, SFOS ha bisogno di una rotta verso la destinazione. Per il traffico VPN, il punto corretto in cui configurare la traduzione dipende anche dal tipo di tunnel:

• IPsec policy-based: utilizzare le impostazioni NAT della connessione IPsec per tradurre le subnet locali e remote, soprattutto quando si sovrappongono. Se una regola SNAT aggiuntiva deve corrispondere al traffico policy-based, impostare Outbound interface su Any; la regola non si applica se si selezionano interfacce WAN specifiche.
• IPsec route-based con subnet locali e remote selezionate: utilizzare le impostazioni NAT della connessione IPsec per tradurre queste subnet.
• IPsec route-based con Any/Any: utilizzare le regole NAT per il traffico inoltrato.

Per il traffico VPN nelle regole NAT, impostare Inbound interface su Any. Per le VPN e DNAT da IP pubblici a privati, anche Outbound interface deve essere Any. È un requisito di corrispondenza delle interfacce, non un’autorizzazione per sorgenti o servizi arbitrari: i criteri Original e le regole firewall continuano a limitarli.

Le reti non sovrapposte generalmente non richiedono NAT. Per le reti sovrapposte, documentare le reti reali e tradotte su entrambi i lati; altrimenti, DNS, le regole e i registri diventano ambigui in seguito.

Per DNAT verso un server dietro un tunnel IPsec route-based, Sophos documenta una configurazione SD-WAN particolare: la regola DNAT utilizza MASQ come Translated source affinché le risposte tornino al firewall. La rotta SD-WAN usa come criteri di corrispondenza l’indirizzo WAN originale o l’interfaccia WAN come destinazione e, quando si utilizza PAT, la porta esterna. L’oggetto gateway punta all’interfaccia XFRM. Non applicare questo caso particolare ai server locali come modello generale di DNAT.

Raggiungere un server remoto con DNAT e una rotta SD-WAN

Questa procedura IPv4 riguarda solo un server dietro il firewall remoto. Verificare prima connessioni IPsec route-based su entrambi i firewall, stato del tunnel, raggiungibilità remota, sorgenti autorizzate, servizio, ritorno e ordine NAT/SD-WAN esistente. Salvare configurazione e posizioni interessate. L’esempio usa TCP 5555 esterno e TCP 443 interno, non RDP pubblico; sostituire gli indirizzi di documentazione con i propri valori. Restano necessarie una regola firewall di autorizzazione separata e misure di hardening.

1. In Hosts and services > IP host > Add, creare Remote_Web: IP version IPv4, Type IP, IP address l’indirizzo del server remoto, ad esempio 172.16.16.10; Save.
2. In Routing > Gateways, IPv4 gateway > Add, scegliere un nome chiaro. Impostare Gateway IP sull’indirizzo del gateway remoto, ad esempio 10.12.13.2, e Interface sull’interfaccia XFRM associata, ad esempio xfrm1-10.12.13.1. In Monitoring condition, inserire l’indirizzo IP di un host effettivamente raggiungibile dietro il gateway; controllare stato di gateway e tunnel prima della pubblicazione.
3. In Rules and policies > NAT rules > Add NAT rule > New NAT rule, creare una regola IPv4 con nome. Limitare Original source alle sorgenti esterne autorizzate. Impostare Original destination sull’interfaccia WAN pubblicata, ad esempio #Port1, Translated source (SNAT) su MASQ, Translated destination (DNAT) su Remote_Web, Original service su un oggetto servizio TCP 5555 e Translated service (PAT) su TCP 443. Per questo caso VPN-DNAT, entrambi i campi interfaccia devono essere Any. Controllare la posizione e selezionare Save. In questo caso particolare, MASQ garantisce il ritorno al firewall.
4. In Routing > SD-WAN routes, scegliere IPv4 > Add e un nome. In Destination networks, rimuovere Any e selezionare la stessa interfaccia WAN originale #Port1, non Remote_Web. In Services, rimuovere Any e selezionare il servizio esterno TCP 5555, non TCP 443. In Link selection settings, scegliere Primary and Backup gateways e impostare Primary gateway sul gateway remoto; scegliere un backup solo se il relativo percorso remoto esiste ed è stato verificato. Selezionare Save.
5. Stabilire una nuova connessione da una sorgente esterna autorizzata. Controllare ID NAT/firewall, destinazione e servizio tradotti, uscita XFRM e risposte nella cattura. Se l’uscita è errata, verificare i criteri SD-WAN, l’ordine e il monitoraggio del gateway; se mancano risposte, controllare il servizio remoto e il percorso di ritorno. Per altri server sullo stesso gateway, estendere la stessa rotta SD-WAN con le loro porte esterne e gli indirizzi WAN; usare rotte separate per gateway diversi. Le combinazioni aggiunte devono restare limitate da NAT e firewall.

In caso di errore, disabilitare la nuova regola DNAT remota, rimuovere la nuova rotta SD-WAN o ripristinarne la configurazione precedente e le posizioni. Non eliminare oggetti gateway/host condivisi. Annullare separatamente le regole NAT derivate e verificare il flusso precedente con una nuova connessione.

Tradurre il traffico generato dal firewall con sys-traffic-nat

Le regole NAT di WebAdmin traducono il traffico inoltrato. Per il traffico generato dal firewall e per tradurre gli indirizzi delle sue interfacce, utilizzare sys-traffic-nat nella Device Console.

Motivi tipici per tradurre l’indirizzo sorgente tramite CLI:

• Inviare richieste DHCP e di autenticazione generate dal firewall attraverso IPsec site-to-site; la traduzione può anche supportare richieste ai servizi firewall attraverso tunnel VPN. Non sostituisce la configurazione dei servizi e della VPN.
• Usare indirizzi alias quando i collegamenti WAN superano il numero di interfacce WAN fisiche, traducendo l’interfaccia fisica nell’alias appropriato.
• Inviare posta con l’indirizzo sorgente alias richiesto dal relay a monte o dal record MX.
• Nascondere gli indirizzi interni alle destinazioni WAN, ad esempio per richieste DHCP di un’interfaccia LAN; usare una specifica identità sorgente verso destinazioni MPLS interne o determinati server web.

Annotare prima la destinazione, l’identità sorgente richiesta, la rotta e i requisiti della controparte. Poi generare una nuova richiesta dal servizio interessato e controllare l’indirizzo sorgente e la risposta nella cattura. Una voce CLI non dimostra da sola il funzionamento di DHCP, autenticazione o posta.

⚠️ Questo comando della Device Console modifica il traffico generato dal sistema. Salvare prima l’output completo di show advanced-firewall. Le voci NAT della CLI vengono elaborate nell’ordine indicato.

Accedere alla Command-line console e selezionare 4 – Device Console, non Advanced Shell. L’esempio seguente traduce il traffico verso la singola destinazione 192.0.2.10 in uscita da Port1, utilizzando l’indirizzo alias 203.0.113.10:

show advanced-firewall
set advanced-firewall sys-traffic-nat add destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

La destinazione, la maschera di rete, l’interfaccia e l’indirizzo SNAT devono corrispondere all’ambiente. Per un singolo host è necessario 255.255.255.255; una maschera più ampia comprende l’intera rete di destinazione corrispondente. Senza interface, la voce si applica al traffico diretto alla destinazione indicata attraverso qualsiasi interfaccia del firewall.

Per annullare la modifica, utilizzare la stessa mappatura completa con delete:

set advanced-firewall sys-traffic-nat delete destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Per impostazione predefinita, il traffico generato dal sistema utilizza WAN Link Load Balancing. Con un IP alias, l’interfaccia principale rimane decisiva per la decisione di routing; sys-traffic-nat garantisce soltanto che l’indirizzo alias desiderato compaia come sorgente. Una voce visibile conferma quindi la configurazione, non il percorso, il percorso di ritorno o il servizio.

Cambiare e testare le regole NAT in modo sicuro

Usare consapevolmente tabella e contatori

In Rules and policies > NAT rules, IPv4 o IPv6 seleziona la famiglia delle regole. Disable filter nasconde il filtro, Enable filter lo mostra e Reset filter lo reimposta. Nascondere il filtro non disabilita una regola NAT. Prima delle modifiche, verificare che siano visibili le voci corrette.

Le regole selezionate possono essere disabilitate insieme con Disable o eliminate con Delete. Trascinare il Rule handle per spostare una regola; quelle specifiche devono precedere le generali. More options offre l’interruttore di abilitazione, modifica, eliminazione e inserimento di una regola adiacente. Unlink rule rimuove il collegamento alla regola firewall: documentare prima la dipendenza e non usarlo come scorciatoia diagnostica.

Reset usage count in More options azzera il contatore di utilizzo. Annotare prima valore e orario, quindi generare un nuovo flusso di test e verificarne l’incremento insieme ai Rule IDs; il solo contatore non identifica il flusso. Il valore precedente non viene ripristinato. Prima delle modifiche, salvare ID, criteri, stato e ordine, preferire la disabilitazione all’eliminazione e cambiare solo le voci selezionate. Se emergono problemi, ripristinare stato e posizioni e testare con una nuova sessione; una regola eliminata va ricreata dalla configurazione salvata.

SFOS valuta NAT solo per il primo pacchetto di una connessione. Le sessioni esistenti conservano la loro precedente traduzione quando una regola viene cambiata o spostata. Il test successivo alla modifica deve quindi creare una nuova connessione; in caso contrario, si rischia di valutare il vecchio stato.

Un test affidabile inizia con un flusso documentato: sorgente, destinazione, servizio, interfacce di ingresso e di uscita e valori attesi di Firewall Rule ID e NAT Rule ID. Quindi:

1. Creare una nuova connessione e filtrare per sorgente, destinazione e servizio in Log Viewer.
2. Confrontare Firewall Rule ID e NAT Rule ID con i valori attesi.
3. Se il NAT Rule ID è errato, controllare le regole precedenti, tutti i campi Original e le interfacce.
4. In Diagnostics > Packet capture, verificare che il pacchetto arrivi e venga inoltrato con gli indirizzi attesi.
5. Controllare la rotta, il percorso di ritorno, il sistema di destinazione e il suo firewall locale.

Per DNAT, eseguire almeno un test dall’esterno della rete. L’accesso interno al nome pubblico verifica soltanto Split DNS o loopback, non l’effettiva pubblicazione da Internet.

Interpretare correttamente i risultati

• Firewall Rule ID e NAT Rule ID sono corretti: la corrispondenza è corretta; esaminare quindi il sistema di destinazione, il percorso di ritorno e i Security Profiles.
• Firewall Rule ID è corretto, ma NAT Rule ID è errato: prevale un’altra regola NAT oppure i criteri Original non corrispondono.
• Nessun NAT Rule ID, benché sia prevista una traduzione: nessuna regola NAT corrisponde; se la regola firewall consente il flusso, continua senza traduzione.
• Diverso Firewall Rule ID: controllare le zone, le reti, il servizio e l’ordine delle regole del firewall.
• Nessuna voce di registro: la registrazione è disabilitata o il traffico non raggiunge il firewall. Eseguire una cattura sull’interfaccia WAN o di ingresso e controllare i router a monte o le regole del cloud.
• DNAT corrisponde, ma il server non risponde: controllare il servizio del server, il firewall locale, il gateway predefinito e l’eventuale asimmetria del percorso di ritorno.

Per un’analisi più approfondita, vedere Testare una regola firewall, Analizzare la corrispondenza delle regole, Classificare i pacchetti scartati e Packet Capture in WebAdmin.

Inquadrare NATRule nell’API XML

Per le automazioni, NATRule rappresenta lo stesso modello Original/Translated. La descrizione dell’oggetto Add NAT policy / Edit NAT policy è identica nei riferimenti SFOS 22 e SFOS 23 confrontati. Questo attesta lo stato della documentazione, non l’esecuzione riuscita su una determinata build. Prima di un processo di scrittura si applicano le regole di sicurezza centrali per l’API XML: accesso di gestione ristretto, verifica TLS, account di servizio separato, segreti protetti, backup, query di lettura e un’operazione esplicita su Set, confermata per l’oggetto e la build installata. La sola descrizione dell’oggetto non costituisce una richiesta eseguibile completa.

Criteri di corrispondenza, traduzione e identità della regola

• OriginalSourceNetworks contiene voci Network ripetibili per le sorgenti originali; OriginalDestinationNetworks contiene voci Network per le destinazioni originali. OriginalServices contiene voci Service ripetibili. Sono riferimenti a oggetti per la corrispondenza prima del NAT, non un’autorizzazione firewall. Per questi nomi di reti e servizi, il riferimento indica un massimo di 60 caratteri ciascuno.
• TranslatedSource, TranslatedDestination e TranslatedService sono ciascuno un singolo valore per la traduzione. Per un campo invariato, l’esempio utilizza Original; per il masquerading della sorgente, MASQ. Indicazioni come IPAddress, IPRange, IPList, FQDN o TCPUDP_Service descrivono nell’esempio il tipo di oggetto appropriato, non un valore letterale arbitrario da inviare. Verificare gli oggetti host, intervallo, lista, FQDN e servizio effettivamente presenti e il loro supporto nella build. Le limitazioni PAT descritte in precedenza restano valide. Per il valore o il nome dell’oggetto servizio in TranslatedService, la tabella dei parametri indica esplicitamente un massimo di 60 caratteri; per TranslatedSource e TranslatedDestination, questa tabella non indica alcun limite massimo corrispondente.
• InboundInterfaces e OutboundInterfaces contengono ciascuno voci Interface ripetibili. Limitano la corrispondenza delle interfacce, ma non creano una rotta. Le condizioni VPN/DNAT illustrate sopra valgono anche per le automazioni: ingresso e uscita VPN utilizzano Any; per DNAT da indirizzi pubblici a privati, anche l’uscita è Any. Questo non elimina le restrizioni imposte dai criteri Original e dalle regole firewall.
• Name direttamente sotto NATRule è il nome obbligatorio della regola: massimo 60 caratteri, UTF-8 consentito, nessuna virgola. Description è facoltativo e limitato a 255 caratteri. IPFamily consente IPv4 o IPv6; il riferimento indica IPv4 come valore predefinito. Status consente Enable o Disable; lo stato predefinito documentato è abilitato. Impostare consapevolmente famiglia e stato nel payload di scrittura approvato, anziché affidarsi ai valori predefiniti senza verificarli.
• Nell’esempio, LinkedFirewallrule è previsto solo per creare una Linked NAT Rule all’interno di una richiesta Set. A tale scopo, identificare con precisione la regola firewall esistente. Il collegamento non trasforma la regola SNAT in una regola DNAT e non le garantisce alcuna priorità; le limitazioni di Linked NAT restano valide.

Pianificare separatamente posizione e override delle interfacce

Position mostra nell’esempio XML i valori top, bottom, after e before con questa esatta grafia. Per il posizionamento relativo, After o Before contiene un proprio Name con il nome della regola di riferimento. Questo nome non è il nome obbligatorio della regola nuova o modificata. L’esempio indica esplicitamente che entrambi i blocchi sono applicabili solo alle richieste Set. Utilizzare soltanto il riferimento appropriato al posizionamento desiderato; non copiare entrambi i blocchi di esempio alla cieca. Verificare prima l’esistenza e la posizione attuale della regola di ancoraggio, poi controllare l’ordine effettivamente salvato. Uno stato dell’oggetto che indica successo non dimostra ancora che il traffico previsto incontri per prima questa regola.

OverrideInterfaceNATPolicy è un interruttore separato con Enable o Disable, valore predefinito documentato Disable e riferimento alla traduzione SNAT della sorgente specifica per interfaccia. La relativa InterfaceNATPolicyList fa parte del caso pianificato solo quando l’override è abilitato. Contiene blocchi Override ripetibili con specific_interface per l’interfaccia di uscita e specific_translatedsourceid per la sorgente tradotta desiderata su tale interfaccia. L’interfaccia specifica descritta come campo obbligatorio è quindi un requisito di questo caso di override condizionale, non un obbligo per ogni regola NAT.

In un punto, i commenti dell’esempio citano invece OverrideInterfaceDefaultNATPolicy, mentre l’elemento e la tabella dei parametri utilizzano OverrideInterfaceNATPolicy. Non inventare un ulteriore tag XML sulla base di questa differenza. La tabella descrive la lista come facoltativa con valore predefinito NULL; non è un’istruzione a inviare il testo NULL. Anche per monitorindex, menzionato nello stesso punto, l’esempio non fornisce una posizione di inserimento chiara. Se un’automazione dipende da questi dettagli non chiariti, chiarirli prima della scrittura in API help della build installata oppure con il supporto; non ipotizzare sintassi o effetti aggiuntivi.

Load Balancing e Health Check sono campi condizionali

NATMethod è rilevante per il caso di distribuzione DNAT, non come scelta obbligatoria per una normale regola SNAT. Il riferimento API ne descrive l’applicabilità con la zona sorgente WAN dell’Hosted Server e un Protected Server di tipo IP Range o IP List. Non trasformare queste denominazioni precedenti in ulteriori campi XML assenti dall’esempio. I valori documentati sono Round-robin, First_alive, Random, StickyIP e OnetoOne; il valore predefinito del riferimento è denominato Sticky IP. La guida alla scelta dei cinque metodi e il requisito dello stesso numero di indirizzi per One-to-one sono riportati sopra.

HealthCheck consente Enable o Disable ed è descritto nella tabella API come facoltativo, con valore predefinito OFF e applicabile solo al Load Balancing. Questo non significa che ogni richiesta NAT debba contenere campi Health Check. Non garantisce però nemmeno che First_alive debba funzionare senza controlli: le istruzioni NAT specifiche impongono l’Health Check per First alive. Per questo caso, pianificare consapevolmente il controllo e i valori e verificarli nello stato salvato, anziché affidarsi al valore predefinito generale OFF.

Quando l’Health Check è abilitato, i valori di controllo si trovano nel blocco LoadBalance:

• ProbeMethod: ICMP o TCP. L’indicazione di obbligatorietà vale qui per il caso in cui il controllo è attivo.
• Port: solo per TCP, intervallo 1–65535; non dedurre un obbligo generale di indicare una porta per ICMP.
• ProbeInterval: intervallo dei controlli in secondi, intervallo 5–65535, valore predefinito documentato 60. L’intervallo proviene dalla tabella dei parametri; l’elemento vuoto dell’esempio non prescrive un proprio valore numerico.
• ResponseTimeOut: tempo massimo di risposta in secondi, intervallo 1–10, valore predefinito documentato 2.
• DeactivateHostAfter: numero di tentativi di controllo falliti prima della disattivazione, facoltativo, intervallo 1–10, valore predefinito documentato 3.

Non separare le indicazioni di obbligatorietà per metodo, intervallo e tempo massimo di risposta dal loro contesto di Health Check abilitato. Anche queste informazioni confermano soltanto il contratto API descritto. Il funzionamento della sonda, del servizio e del failover desiderato deve essere verificato con il nuovo flusso di dati descritto sopra e con un test pianificato di guasto e ripristino.

Valutare le risposte NATRule in modo specifico per l’oggetto

Le associazioni seguenti provengono da Status Message Information per questo oggetto. Sono codici di stato dell’oggetto XML, non codici di stato HTTP. I valori Message.* sono chiavi di messaggio non risolte del riferimento, non testi di messaggi verificati su un firewall. Valutare quindi insieme operazione, codice, risposta effettiva e stato salvato; non dedurre dal nome della chiave un limite o la sicurezza di un nuovo tentativo.

• Add NAT policy: 200 è associato a Message.NATPolicyAddSuccess, 500 a Message.NATPolicyAddFail e 502 a Message.NATPolicyRecordExists.
• Edit NAT policy: 200 è associato a Message.NATPolicyUpdateSuccess, 500 a Message.NATPolicyUpdateFail e 502 a Message.NATRuleUpdateRecordExist. In particolare, la chiave 502 è diversa da quella della creazione.

Per entrambe le operazioni Add NAT policy e Edit NAT policy sono inoltre documentate le stesse associazioni:

In particolare, quindi, 504 non deve essere interpretato qui, sulla sola base della tabella API generale, come un’eliminazione fallita a causa di un riferimento: queste righe NATRule riguardano Add/Edit e riportano la chiave del conflitto di porta. Anche i due codici 548 e 549, pur avendo una chiave identica, non attestano un numero massimo concreto di server.

Prima di ogni nuovo tentativo di scrittura, anche in caso di timeout o di presunto successo, leggere la voce NAT effettivamente salvata e verificarla in Rules and policies > NAT rules: nome, famiglia, stato, valori Original/Translated, interfacce, associazioni di override, valori di controllo condizionali e posizione. Confrontare la risposta con lo stato precedentemente salvato; in caso di conflitti, non aggirarli rinominando, ampliando i criteri o ripetendo alla cieca. Le differenze non chiarite devono interrompere il processo. Solo dopo la verifica dello stato, controllare con una nuova sessione entrambi i Rule IDs e la traduzione effettiva. Per il rollback, ripristinare lo stato salvato e l’ordine e considerare separatamente le regole derivate; la pubblicazione pratica del server resta descritta nella guida DNAT.

FAQ