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

NAT è uno degli argomenti sul Sophos Firewall che diventa rapidamente confuso nella pratica. I termini sembrano simili, la maschera delle regole funziona con Original e Translated e in Log Viewer vedi indirizzi diversi dal previsto a seconda della posizione.

Questo articolo spiega i tipi NAT più importanti, mostra casi pratici tipici e descrive un esempio DNAT con una regola firewall adatta.

Il punto pratico più importante è: NAT deve essere considerato insieme alla regola del firewall, al routing, al percorso di ritorno e al logging. Molti problemi NAT non derivano dalla traduzione in sé, ma da un ordine errato delle regole, da un Original destination frainteso, da registrazioni mancanti o da test provenienti dalla rete sbagliata.

Orientamento

Prima di costruire una regola NAT, dovrebbe essere chiaro quale problema si sta realmente risolvendo. NAT traduce indirizzi o porte, ma non sostituisce l’autorizzazione del firewall e la progettazione pulita del routing.

Quale articolo NAT è adatto?

NAT si sovrappone rapidamente alle regole firewall, routing, WAF, VPN e Packet Capture. A seconda dell’attività, questo articolo di base non è sempre il modo migliore per iniziare:

• Comprendere NAT, SNAT, DNAT, MASQ, PAT, loopback e regole reflexive: questo articolo.
• Pubblicare un server interno tramite port forwarding: Pubblicare un server tramite DNAT su Sophos Firewall.
• Pubblicare un’applicazione HTTP o HTTPS: Sophos Firewall WAF: pubblicare un server Web in modo sicuro.
• Inquadrare insieme regole firewall e NAT: Comprendere e configurare in sicurezza le regole Sophos Firewall.
• Testare una singola connessione con log e Packet Capture: Testare una regola firewall con Log Viewer, Policy Test e Packet Capture.
• Verificare NAT per IPsec, XFRM, SD-WAN o reti sovrapposte: Troubleshooting IPsec VPN Sophos Firewall.
• Analizzare drop, Violation, Rule ID o NAT Rule ID: Analizzare i pacchetti scartati da Sophos Firewall.

Ciò rende la risoluzione dei problemi più rigorosa: innanzitutto chiarire se si tratta di traduzione, rilascio, routing, protezione del server web o flusso di pacchetti. Successivamente, dovrebbe essere modificato solo il livello interessato.

NAT è una traduzione, non una release

Traduzione degli indirizzi di rete modifica gli indirizzi o le porte di un pacchetto mentre passa attraverso Sophos Firewall. Tuttavia, NAT non decide da solo se il traffico è consentito.

⚠️ Una regola NAT non consente il traffico. La regola traduce solo indirizzi o porte. Anche per il traffico attraverso il firewall è sempre necessaria una regola firewall adeguata.

Casi tipici di NAT:

• I client interni accedono a Internet tramite il pubblico WAN-IP.
• Un server interno viene pubblicato tramite un IP pubblico.
• Una porta pubblica viene tradotta in un’altra porta interna.
• Le reti sovrapposte vengono tradotte per le connessioni VPN.
• I client interni accedono a un server interno tramite il nome DNS pubblico.

Decisione rapida: NAT o no NAT?

Molti errori NAT si verificano perché NAT viene utilizzato come soluzione predefinita, anche se il routing o una regola firewall sarebbero sufficienti. Prima di ogni nuova regola NAT si dovrebbe decidere se è veramente necessario modificare un indirizzo o una porta.

• Il client del LAN dovrebbe accedere a Internet normalmente: Una regola generale SNAT o MASQ è solitamente sufficiente.
• Il server interno deve essere accessibile da Internet: utilizzare DNAT o per HTTP/HTTPS verificare prima WAF.
• È necessario utilizzare una porta diversa esternamente rispetto a quella internamente: Pianifica DNAT con PAT e aggiungi la regola firewall appropriata.
• Gli utenti interni accedono allo stesso FQDN pubblico: controllare prima il DNS diviso, utilizzare il loopback NAT solo se necessario.
• Le reti VPN locali e remote sono chiare: Di solito non utilizzano NAT, ma creano regole di routing e firewall in modo pulito.
• Le reti VPN si sovrappongono o la stazione remota richiede una fonte specifica: Utilizzare SNAT o DNAT mirati con rete sostitutiva documentata.
• È consentita o limitata una sola regola firewall: Non creare NAT. Modifica la regola del firewall.

Se la risposta a “Cosa dovrebbe essere tradotto?” non è chiaro, non deve essere creata una regola NAT. Quindi controlla prima il flusso dei pacchetti, l’indirizzo di destinazione, il percorso di ritorno e Log Viewer. Soprattutto per le VLAN interne, le VPN da sito a sito senza reti sovrapposte e le reti di server instradati, nessun NAT è spesso la soluzione più pulita.

Comprendere le nozioni di base di NAT

La maschera delle regole diventa molto più semplice se si distingue prima tra traffico originale e traffico tradotto. Sarà allora più chiaro se sarà necessario modificare la fonte, la destinazione o il servizio.

Le principali specie NAT

• SNAT: Traduce la fonte IP. In genere quando si suppone che client o server interni accedano a Internet con uno specifico IP pubblico.
• MASQ: Traduce l’origine IP nel IP dell’interfaccia in uscita. Questo è il caso standard per i modelli da LAN a WAN.
• DNAT: Traduce la destinazione IP. Ciò rende un server interno accessibile tramite un IP pubblico.
• PAT: Traduce porta o servizio. Ciò significa che una porta esterna punta a un’altra porta interna.
• Loopback NAT: consente l’accesso interno tramite IP pubblico o FQDN pubblico. I client interni utilizzano lo stesso nome DNS degli utenti esterni.
• Regola riflessiva: Crea una regola NAT di origine riflettente. Ciò consente a un server pubblicato di apparire al traffico in uscita con un’identità pubblica appropriata.

Come modello mentale aiuta: NAT non risponde alla domanda “È consentito questo traffico?”, ma piuttosto “Come dovrebbe essere l’indirizzo o la porta lungo il percorso?”

Leggi l’originale e tradotto correttamente

Nelle regole NAT, Original descrive il traffico quando arriva al Sophos Firewall. Translated lo descrive dopo la traduzione.

• Original source: Indirizzo di origine prima di NAT.
• Translated source (SNAT): Indirizzo di origine a NAT.
• Original destination: Indirizzo di destinazione prima di NAT.
• Translated destination (DNAT): Indirizzo di destinazione dopo NAT.
• Original service: Servizio o porta prima di NAT.
• Interfacce e VPN: Any è spesso corretto per le interfacce in ingresso e in uscita in scenari DNAT o VPN, perché i tunnel VPN non sono sempre gestiti come normali interfacce fisiche.
• Servizio tradotto (PAT): Servizio o porta a NAT.

Se ci sono errori, dovresti prima notare come appare il pacchetto prima di NAT. Quindi definisci cosa dovrebbe farne il firewall.

Pianifica NAT prima della modifica

Prima di apportare una modifica NAT, non dovresti solo guardare la regola NAT stessa. L’intero flusso dei pacchetti è cruciale: dove arriva il pacchetto, quale regola del firewall consente il traffico, quale regola NAT lo traduce, dove va la risposta e come viene controllato il risultato?

Questi punti dovrebbero essere chiari prima della modifica:

• Pacchetto prima di NAT: Origine, Destinazione e Servizio devono corrispondere al lato Original della regola NAT.
• Pacchetto secondo NAT: Translated source, Translated destination e Translated service devono essere impostati deliberatamente.
• Regola firewall di autorizzazione: NAT non consente il traffico. Senza una regola firewall adeguata, la traduzione rimane inefficace.
• Regole NAT più generali: Vince la prima regola NAT corrispondente. Una regola SNAT o MASQ ampia può nascondere regole più specifiche.
• Percorso di ritorno: Molti problemi NAT sono in realtà problemi di routing, percorso di ritorno o sistema di destinazione.
• Metodo di test: Log Viewer, ID regola, NAT Rule ID e Packet Capture devono essere preparati prima del test.

Comprensione e configurazione sicura delle regole Sophos Firewall aiuta a trovare la regola firewall corretta. Se non è chiaro se la regola si applica, Sophos Firewall La regola non si applica: controlla le cause è il modo migliore per iniziare la risoluzione dei problemi.

Esempi pratici: Quando usi cosa?

• I client di LAN devono accedere a Internet: MASQ o SNAT. Esempio: 10.10.10.80 esce con il firewall WAN-IP.
• Il server web interno deve essere accessibile dall’esterno: DNAT. Esempio: il pubblico WAN-IP punta a 172.16.16.10.
• Una porta diversa viene utilizzata esternamente da quella interna: PAT. Esempio: TCP 5555 esterno, TCP 443 interno.
• Gli utenti interni utilizzano lo stesso FQDN degli utenti esterni: Loopback NAT. Esempio: service.example.com punta allo stesso servizio internamente ed esternamente.
• Il server pubblicato dovrebbe apparire in uscita con il pubblico IP specifico: SNAT o regola riflessiva. Esempio: un server di posta invia con il pubblico definito IP.
• Le reti VPN si sovrappongono: SNAT o DNAT. Esempio: il sito A vede il sito B tramite una rete tradotta.
• Il traffico interno dovrebbe rimanere invariato: No NAT. Sono sufficienti le regole di routing e firewall.

Non tutto il traffico necessita di NAT. Tra VLAN interne, VPN da sito a sito senza reti sovrapposte o reti instradate direttamente, NAT è spesso addirittura dannoso perché i log, le stazioni remote e i sistemi di destinazione perdono la vera fonte IP. Una buona pianificazione NAT quindi decide innanzitutto se è necessario eseguire la traduzione.

Specie NAT nella pratica

I seguenti tipi NAT risolvono compiti diversi. Negli ambienti produttivi, si dovrebbe selezionare consapevolmente quale traduzione è necessaria invece di utilizzare NAT come soluzione generale per i problemi di routing.

SNAT: Fonte NAT

SNAT modifica l’indirizzo di origine. Il caso classico è l’accesso a Internet in uscita dal LAN. I client mantengono internamente i loro indirizzi IP interni, ma l’indirizzo pubblico del firewall o un IP pubblico definito appare esternamente.

Tipica regola SNAT per LAN a WAN:

• Original source: LAN interno o rete server.
• Translated source (SNAT): MASQ o pubblico fisso IP.
• Original destination: Any.
• Translated destination (DNAT): Original.
• Original service: Any o definito Services.
• Servizio di traduzione (PAT): Original.
• Inbound interface: interfaccia interna o Any.
• Interfaccia in uscita: interfaccia WAN. Per ambienti semplici, una regola SNAT generica è spesso più chiara di molte singole regole NAT collegate.

MASQ: Mascherarsi

MASQ è una comoda variante SNAT. Per impostazione predefinita, MASQ traduce l’indirizzo di origine nell’indirizzo IP dell’interfaccia in uscita. Per il normale accesso a Internet, di solito si tratta del WAN-IP.

Nella configurazione di base, Sophos Firewall ha una regola SNAT predefinita con MASQ. Se non desideri utilizzare questa regola, la disattivazione è solitamente più semplice dell’eliminazione. In caso contrario, la regola predefinita potrebbe riapparire durante la creazione o l’aggiornamento di un’interfaccia WAN.

Ostacolo: con le VPN basate su percorso, MASQ potrebbe apparire diverso dal previsto. Se le sottoreti locali e remote sono impostate su Any o vengono utilizzate configurazioni doppie IP, il firewall può utilizzare XFRM-IP come origine tradotta. In Packet Capture o tcpdump puoi quindi vedere WAN-IP nell’intestazione esterna e XFRM-IP nel contesto interno. Altri ostacoli riguardano il IPsec basato su policy. Se il traffico tradotto deve essere assegnato a uno specifico tunnel IPsec, i percorsi IPsec e l’impostazione Interfaccia in uscita nelle regole SNAT possono essere fondamentali. Il processo è in IPsec Crea percorso su Sophos Firewall.

NAT su VPN, SD-WAN e reti sovrapposte

NAT diventa rapidamente più complesso negli ambienti VPN e SD-WAN rispetto al semplice traffico da LAN a WAN. Il principio più importante rimane lo stesso: in primo luogo, il percorso previsto deve essere chiaro. Quindi decidi se NAT è necessario.

Scenari tipici:

• VPN da sito a sito con reti univoche: Per lo più niente NAT, ma regole firewall e routing puliti.
• VPN da sito a sito con reti sovrapposte: Regola SNAT o DNAT mirata con rete di backup documentata.
• VPN basato su percorso con XFRM e SD-WAN: Controllare insieme l’interfaccia XFRM, il percorso, il percorso SD-WAN e NAT.
• IPsec basato su policy con traffico tradotto: Controlla il percorso IPsec e la regola SNAT con Outbound interface corrispondente.
• Remote Access VPN alle reti interne: Normalmente no NAT, a meno che un sistema di destinazione non si aspetti una fonte specifica.

Per le reti sovrapposte, NAT non dovrebbe essere improvvisato. Entrambe le parti devono sapere quale rete reale si trova dietro quale rete tradotta. Altrimenti i test individuali funzionano, ma le applicazioni, il DNS, il logging o le regole di accesso diventano difficili da comprendere in seguito. Se un tunnel VPN è verde ma non passa traffico utile, NAT è solo una delle possibili cause. Occorre quindi verificare in parallelo stato IPsec, Route Lookup, regola firewall, rotta SD-WAN e Packet Capture. Per un processo strutturato sono adatti Troubleshooting IPsec VPN Sophos Firewall, routing SD-WAN per Reply Packets e System Traffic e verificare MTU e MSS su Sophos Firewall per problemi VPN.

DNAT: Destinazione NAT

DNAT modifica l’indirizzo di destinazione. Ad esempio, puoi pubblicare un server interno tramite una IP pubblica o una porta pubblica. Il traffico in entrata all’indirizzo WAN viene tradotto sul server interno.

Regola tipica DNAT:

• Original source: Any o reti IP di origine definite.
• Original destination: Oggetto host WAN-IP o WAN.
• Original service: servizio esterno, ad esempio HTTPS o Synology_5555.
• Translated destination (DNAT): server interno.
• Servizio di traduzione (PAT): Original o porta di destinazione interna.
• Translated source (SNAT): principalmente Original.
• Inbound interface: Interfaccia Any o WAN.
• Interfaccia in uscita: principalmente Any a DNAT.

Per i servizi pubblici, non dovresti solo creare NAT, ma anche controllare immediatamente la registrazione, l’IPS, le restrizioni sull’origine, la logica geo-IP e il livello di patch del server di destinazione. Istruzioni dettagliate più dettagliate sono disponibili nell’articolo Pubblicare il server su Sophos Firewall tramite DNAT. Per le applicazioni HTTP e HTTPS, dovresti anche verificare se un Sophos Firewall WAF è più adatto del puro DNAT. DNAT è un port forwarding. WAF può includere nomi host, certificati, percorsi, profili di protezione web e facoltativamente autenticazione. Per servizi semplici non HTTP, DNAT spesso rimane corretto; per le applicazioni Web accessibili pubblicamente, WAF è spesso un punto di partenza migliore.

PAT: Traduzione dell’indirizzo della porta

PAT modifica il servizio o la porta. Sul Sophos Firewall, il campo Servizio tradotto (PAT) è responsabile di ciò.

Esempio:

• Da esterno TCP 5555 a interno TCP 443.
• Da esterno TCP 20120 a interno TCP 22.
• Da TCP 8443 esterno a TCP 443 interno.

Il client esterno si connette a una porta pubblica, ma internamente viene indirizzata una porta diversa. Importante: il protocollo deve essere corretto. TCP può essere tradotto in TCP, UDP in UDP. Una traduzione da TCP a UDP non è un port forwarding pulito.

DNAT esempio con regola firewall

L’esempio mostra la tipica pubblicazione di un servizio interno. Ciò che è fondamentale è che la regola NAT e la regola del firewall corrispondano.

Esempio pratico: pubblicare Synology tramite DNAT

Nell’esempio, un servizio dovrebbe essere accessibile tramite un WAN-IP pubblico. Il servizio Synology_5555 è indirizzato dall’esterno. Internamente il server ascolta HTTPS. Pertanto la regola NAT traduce l’indirizzo di destinazione pubblico nel server interno e il servizio pubblico nel servizio interno.

Regola DNAT campo per campo

• Rule name: Nome chiaro, ad esempio DNAT_SYNOLOGY_5555.
• Descrizione: Documenta il motivo per cui esiste la regola e chi l’ha creata. Ciò aiuterà enormemente in seguito.
• Rule position: Le regole specifiche dovrebbero essere poste al di sopra delle regole generali.
• Original source: Può essere limitato nella regola NAT. In pratica, spesso è più pulito mantenere la restrizione dell’origine nella regola del firewall in modo che la stessa restrizione non debba essere mantenuta due volte.
• Original destination: L’indirizzo di destinazione pubblico prima di NAT. È preferibile utilizzare un oggetto host per WAN-IP piuttosto che direttamente l’interfaccia WAN. Un oggetto host di solito rimane più stabile durante le modifiche o gli aggiustamenti dell’interfaccia.
• Original service: Il servizio o la porta raggiungibile dall’esterno, ad esempio Synology_5555.
• Translated source (SNAT): Per le regole classiche DNAT solitamente Original. Cambiare solo se il server interno deve vedere il firewall come origine. Ma poi perdi il vero cliente IP.
• Translated destination (DNAT): Il server interno o un elenco di server a cui reindirizzare.
• Servizio tradotto (PAT): Il servizio interno o la porta su cui riscrivere, ad esempio HTTPS. Se non è necessario alcun cambio di porta, il servizio rimane Original.
• Inbound interface: Interfaccia da cui entra il traffico. Per DNAT spesso Any o WAN. Any è spesso richiesto per i contesti VPN perché le VPN non vengono trattate come normali interfacce.
• Interfaccia in uscita: Per DNAT solitamente Any, poiché il firewall decide il routing e la zona di destinazione.

Crea una regola firewall per la regola DNAT

Una regola DNAT non è sufficiente. Inoltre, è necessaria una regola firewall che consenta il traffico.

Per DNAT è importante: la regola del firewall si riferisce al traffico nel contesto DNAT. All’inizio questo sembra insolito, soprattutto con le zone target e le reti target.

• Source zones: Principalmente WAN quando l’accesso avviene da Internet.
• Source networks and devices: Se possibile, non Any se può essere evitato. È meglio utilizzare paesi, IP individuali, reti, host o gruppi FQDN.
• Destination zones: La zona del target interno, ad esempio SERVER o DMZ, non semplicemente WAN.
• Destination networks: L’indirizzo di destinazione pubblico o l’oggetto host WAN da Original destination.
• Services: Il servizio esterno da Original service, ovvero la porta a cui accedono i client dall’esterno.
• Log firewall traffic: Abilita per i servizi pubblicati. Senza registrazione, Log Viewer non è utile con questa regola. Se gli utenti globali necessitano di accesso e Source networks and devices non può essere limitato in modo significativo, è comunque necessario rafforzare la regola: aprire solo le porte richieste, attivare IPS, attivare la registrazione, mantenere aggiornato il sistema di destinazione e utilizzare MFA, VPN o ZTNA se possibile.

💡 I servizi accessibili al pubblico vengono spesso scansionati molto rapidamente dai bot. I feed sulle minacce Sophos Firewall aiutano a bloccare tempestivamente IP, domini o URL dannosi noti. Ciò non sostituisce una regola pulita, ma riduce significativamente il traffico bot non necessario.

Regola di loopback: accesso interno tramite il nome DNS pubblico

È necessaria una regola di loopback se i client interni devono raggiungere un server interno tramite il relativo IP pubblico o FQDN pubblico.

Esempio:

• Esternamente service.example.com punta al pubblico WAN-IP.
• Internamente, i client utilizzano lo stesso nome service.example.com.
• Senza loopback, il traffico dal LAN va al IP pubblico del firewall e deve tornare al server interno.

In ambienti semplici, il DNS diviso è spesso più pulito: internamente service.example.com punta direttamente al server interno IP. Quindi non è necessario Hairpin-NAT. Se il DNS diviso non è possibile, può avere senso una regola di loopback.

Con Server Access Assistant, Sophos Firewall può creare automaticamente regole di loopback. Tuttavia, ciò funziona solo in determinate condizioni, ad esempio se l’interfaccia WAN viene utilizzata come Pubblica IP e le fonti esterne sono definite in modo appropriato in generale. Con le regole manuali, il loopback dovrebbe essere pianificato consapevolmente e poi testato.

Regola riflessiva: rispecchia il traffico in uscita dal server

Una Regola riflessiva è una regola SNAT generata automaticamente per la regola DNAT. Questa regola può essere utile se si desidera che il server pubblicato appaia a partire da uno specifico pubblico IP. Importante: le risposte normali a una connessione DNAT in entrata di solito non richiedono una regola riflessiva separata. Il firewall con stato garantisce che i pacchetti di risposta appartengano alla connessione esistente.

Dovresti attivare le regole riflessive solo se ne capisci lo scopo. In ambienti con più IP WAN, più regole DNAT o più server, una regola SNAT aggiuntiva potrebbe altrimenti provocare un comportamento difficile da comprendere.

⚠️ Le regole Loopback o Reflexive generate automaticamente restano regole indipendenti. Se la regola DNAT originale viene modificata o eliminata in seguito, queste regole derivate non vengono aggiornate automaticamente in modo logico. Dopo ogni modifica alla regola originale, le regole Loopback e Reflexive associate devono essere controllate manualmente.

Funzionalità avanzate NAT

Queste opzioni non sono necessarie in ogni ambiente. Diventano importanti quando i client interni utilizzano lo stesso nome pubblico, sono coinvolti più server di destinazione o le regole NAT vengono create dalle regole del firewall.

Server Access Assistant o regola manuale NAT?

Server Access Assistant può creare automaticamente regole DNAT, loopback, riflessive e firewall. Questo è utile se vuoi pubblicare rapidamente un servizio.

Per gli ambienti produttivi, le regole manuali sono spesso più facili da comprendere:

• Puoi vedere esattamente quale regola fa cosa.
• Le restrizioni sulla fonte vengono deliberatamente mantenute nelle regole del firewall.
• La regola NAT rimane più snella.
• La posizione della regola e la registrazione sono impostate in modo pulito.
• I cambiamenti successivi sono meno sorprendenti.

L’Assistente è utile, ma non sostituisce la comprensione delle singole regole.

Regole NAT collegate

Una Regola NAT collegata viene creata da una regola firewall. È una regola Source NAT nella tabella delle regole NAT.

Sembra pratico, ma ha dei limiti:

• La maggior parte dei criteri di corrispondenza provengono dalla regola del firewall.
• Nella regola NAT puoi modificare solo alcuni campi NAT.
• Una regola NAT più generale sopra può comunque corrispondere per prima.
• Molte regole NAT collegate creano rapidamente confusione nella tabella NAT.

Per configurazioni nuove e semplici, una regola NAT indipendente in Rules and policies > NAT rules è solitamente più comprensibile. Le regole NAT collegate sono particolarmente utili negli scenari di migrazione o in casi speciali molto mirati.

Bilanciamento del carico e Health Check su DNAT

DNAT può fare molto di più del semplice port forwarding. Se più server interni vengono archiviati come Translated destination, il firewall può distribuire il traffico.

Metodi possibili:

• Round robin: distribuzione semplice senza persistenza della sessione.
• Primo vivo: server primario con failover.
• Casuale: distribuzione casuale.
• Sticky IP: la stessa combinazione sorgente-destinazione rimane sullo stesso server.
• Uno-a-uno: assegnazione fissa tra la destinazione originale e quella tradotta. Se desideri che il firewall rilevi se un server di destinazione è disponibile, è necessario abilitare il controllo dello stato. Senza Health Check, il firewall considera i server disponibili anche se non rispondono.

NAT ordine

Sophos elabora le regole NAT dall’alto verso il basso. Vince la prima regola corrispondente. Successivamente non verranno più controllate ulteriori regole NAT.

Raccomandazione:

• Regole specifiche DNAT
• Regole SNAT specifiche sopra le regole generali MASQ
• Posiziona consapevolmente la regola SNAT predefinita
• Controlla regolarmente le regole NAT collegate
• Rimuovi o disattiva le vecchie regole di migrazione se non sono più necessarie

Un ordine collaudato in molti ambienti si presenta così:

1. Buco nero DNAT o regole di blocco per fonti indesiderate note, se tali regole vengono utilizzate.
2. Regole DNAT molto specifiche per i servizi pubblicati.
3. Regole speciali SNAT per singoli server, reti partner o casi speciali VPN.
4. Regole di loopback o riflessive quando sono consapevolmente necessarie.
5. Regole generali SNAT o MASQ per il normale accesso a Internet.

Questa non è una legge dura e veloce, ma è un buon quadro di prova. Il flusso di test specifico è sempre cruciale. Se una regola MASQ generale o una vecchia regola NAT collegata viene posizionata sopra una regola specifica, la nuova regola sembra corretta ma non viene mai raggiunta. Quando apporti modifiche, non dovresti controllare solo la regola stessa, ma anche le regole direttamente sopra e sotto di essa.

Per i servizi pubblici, una regola del buco nero DNAT prima della regola produttiva DNAT può essere utile se determinati elenchi o paesi IP cattivi devono essere intercettati in anticipo. Il processo è descritto in Sophos Firewall: Blocca paesi e IP dannosi.

NAT cambia e controlla in sicurezza

Le modifiche NAT alterano il flusso dei pacchetti. Ecco perché dovresti trattarlo come un cambiamento produttivo: prepara, testa, registra e ripristina in modo pulito se necessario.

Implementa le modifiche NAT in modo sicuro

I cambiamenti NAT spesso influiscono immediatamente sul traffico produttivo. Ciò è particolarmente critico per i server pubblicati, i casi speciali VPN, più indirizzi WAN-IP o le regole firewall utilizzate da partner esterni. Pertanto, NAT non dovrebbe essere trattato come una pura modifica dell’oggetto, ma piuttosto come una piccola modifica con un percorso di test e fallback.

Prima di apportare una modifica produttiva, dovresti notare brevemente:

• NAT Rule ID precedente e nome della regola: Nel Log Viewer è quindi possibile verificare se la nuova regola si applica realmente.
• Flusso di test previsto: Sorgente, Destinazione, Servizio e Direzione devono essere chiari prima del salvataggio.
• Regola firewall dipendente: NAT e la regola firewall devono corrispondere ma devono essere controllate separatamente.
• Percorso di fallback: In caso di problemi, la nuova regola può essere disattivata e la vecchia regola può essere nuovamente attivata.
• Finestra di test: I servizi esterni, i siti remoti VPN o l’accesso dei partner non devono essere interrotti inosservati.

Quando si apportano modifiche importanti, si consiglia prima di duplicare le regole NAT esistenti o di creare una nuova regola specifica sopra di esse invece di convertire direttamente l’unica regola funzionante. La vecchia regola inizialmente rimane disattivata o rimane qui sotto come riferimento. Dopo un test positivo, può essere rimosso o documentato chiaramente.

Anche la posizione della regola è importante: una nuova regola specifica SNAT o DNAT non è di alcuna utilità se una regola più generale sopra corrisponde già allo stesso traffico. Pertanto, la modifica include sempre un test del visualizzatore di log con Firewall Rule ID e NAT Rule ID previsti. Per i servizi accessibili dall’esterno, il test non dovrebbe essere eseguito solo dal proprio LAN. Un test interno per l’FQDN pubblico spesso verifica il loopback o il DNS diviso, ma non l’accesso reale da Internet. L’accettazione di DNAT richiede almeno un test esterno, ad esempio tramite comunicazioni mobili, una posizione esterna o un test su una porta controllata.

Controlla insieme NAT e la regola firewall

Un errore di pensiero comune è: “La regola NAT è corretta, quindi dovrebbe funzionare”. Questo è vero solo a metà.

Affinché il traffico funzioni è necessario:

1. Instradamento al firewall
2. regola NAT appropriata se è necessaria la traduzione
3. regola firewall appropriata
4. corretto percorso di ritorno
5. profili di sicurezza adeguati
6. nessun blocco a monte, ad esempio router del provider, gruppo di sicurezza cloud o firewall di destinazione Quanto segue si applica anche a DNAT: Le regole firewall per il traffico DNAT utilizzano la zona di destinazione dopo NAT, ma l’indirizzo di destinazione pubblico prima di NAT come rete di destinazione. È proprio questo punto ad essere cruciale nella risoluzione di molti problemi.

Leggi correttamente Firewall Rule ID e NAT Rule ID

In caso di errori NAT, non dovresti solo controllare se esiste qualche voce di registro. Ciò che è fondamentale è se la voce di registro corrisponde alla regola firewall prevista e alla regola NAT prevista. Per questo motivo, Firewall Rule ID e NAT Rule ID sono più utili del solo nome della regola, perché i nomi possono essere modificati, scelti in modo simile o tagliati negli screenshot.

Una breve interpretazione aiuta:

• Firewall Rule ID previsto e NAT Rule ID previsto visibili: La corrispondenza della regola è sostanzialmente corretta. Quindi controlla il percorso di ritorno, il sistema di destinazione, il profilo di sicurezza e l’applicazione.
• Firewall Rule ID previsto visibile, ma NAT Rule ID errato: La regola firewall corrisponde, ma l’ordine NAT o i criteri NAT non corrispondono. Controlla la posizione della regola NAT, i campi Original e le regole NAT più generali.
• Altro Firewall Rule ID visibile: Un’altra regola firewall vince. Controlla l’ordine delle regole del firewall, le zone, l’origine, la destinazione e il servizio.
• Nessun NAT Rule ID visibile, anche se è previsto NAT: Non è stata applicata alcuna regola NAT oppure è stato visualizzato il tipo di registro o flusso errato. Controlla i criteri NAT, la direzione e il flusso di test reale.
• Nessuna voce di registro visibile: La registrazione è mancante o il traffico non raggiunge il firewall. Controllare la registrazione delle regole, il router del provider, VLAN, Gateway e Packet Capture. Soprattutto con DNAT, un singolo test riuscito o fallito senza confronto degli ID non è sufficiente. Dovresti annotare quali ID sono previsti, eseguire il test esattamente una volta e quindi confrontare Log Viewer e Packet Capture. Se gli ID non corrispondono alle aspettative, vengono corretti prima la corrispondenza e l’ordinamento, non il server di destinazione.

Errori comuni NAT

Quando si affrontano i problemi NAT, è utile non ricostruire immediatamente le regole. Innanzitutto si dovrebbe classificare il difetto osservato.

• Nessuna voce di registro in Log Viewer: Il traffico non raggiunge il firewall, la registrazione è mancante o il filtro non è corretto. Controlla il router del provider, il gruppo di sicurezza cloud, il client Gateway, la registrazione delle regole del firewall e i filtri.
• Voce di registro senza NAT Rule ID previsto: La regola NAT non corrisponde oppure prevale una regola superiore. Original source, Original destination, controlla il servizio e l’ordine NAT.
• La regola DNAT corrisponde, la connessione continua a non funzionare: Regola firewall, server di destinazione, percorso di ritorno o firewall del server locale bloccati. Confronta Firewall Rule ID, Packet Capture e i registri del server.
• L’accesso interno al FQDN pubblico non funziona: DNS diviso o loopback NAT mancante. Controlla la risoluzione DNS interna e decidi se il DNS diviso o il loopback sono più puliti.
• Il client esterno vede l’origine errata-IP: SNAT o la regola riflessiva modifica l’origine in modo imprevisto. Controlla Translated source (SNAT) e le regole generate automaticamente.
• Il traffico VPN utilizza la sorgente imprevista IP: Il percorso SNAT, XFRM, SD-WAN o il percorso IPsec non corrispondono. Controlla la ricerca del percorso, il percorso SD-WAN, il percorso IPsec e la posizione delle regole NAT.
• Porta pubblica che punta al servizio interno errato: PAT o l’oggetto del servizio sono impostati in modo errato. Confronta Original service e Translated service (PAT). Questa panoramica non sostituisce l’analisi del flusso dei pacchetti, ma fa risparmiare tempo: separa i problemi davanti al firewall, nella logica NAT, nella regola del firewall e sul sistema di destinazione.

Test di accettazione dopo le modifiche NAT

Dopo una modifica NAT non dovreste solo verificare se un singolo ping o un sito web funzionano una volta. La prova deve corrispondere al tipo di traduzione.

Per SNAT o MASQ:

1. Definire il client di test e il servizio di destinazione.
2. Controllare la regola del firewall con Log firewall traffic.
3. Nel Log Viewer verificare quali Firewall Rule ID e NAT Rule ID sono in vigore.
4. Sul sistema di destinazione o sul servizio di test esterno, verificare quale origine IP è visibile.
5. Testare il percorso di ritorno e il comportamento della sessione su diversi collegamenti WAN.

Per DNAT o PAT:

1. Eseguire il test dall’esterno della propria rete, non solo dal LAN.
2. Confrontare il target pubblico IP, la porta esterna e il server di destinazione interno.
3. Controllare Log Viewer Firewall Rule ID e NAT Rule ID.
4. Utilizzare Packet Capture per verificare se i pacchetti arrivano e continuano verso il server interno.
5. Controllare sul server di destinazione se il firewall locale, il servizio e il percorso di ritorno sono corretti.

Per VPN-NAT:

1. Controllare lo stato del tunnel e le associazioni di sicurezza.
2. Definire un flusso di test concreto con origine, destinazione e servizio.
3. Controllare la posizione della regola NAT e la ricerca del percorso.
4. Utilizzare Packet Capture su entrambi i lati se il sito remoto consente l’accesso.
5. Includere i log dell’applicazione o del sistema di destinazione in modo che non venga valutato solo il lato firewall.

Soprattutto in località remote, è necessario modificare un solo caso di test per modifica. Se la regola del firewall NAT, il percorso SD-WAN e il sistema di destinazione vengono modificati contemporaneamente, difficilmente sarà possibile spiegare in seguito il successo del test.

Risoluzione dei problemi

Questo ordine aiuta con i problemi NAT:

1. Aprire Visualizzatore registro e filtrare per Sorgente IP, Destinazione IP e Servizio.
2. Controllare quali Firewall Rule ID e NAT Rule ID sono visualizzati.
3. Controllare la posizione del controllo NAT.
4. Controllare la posizione della regola del firewall.
5. Utilizzare Diagnostics > Acquisizione pacchetti per verificare se i pacchetti arrivano e continuano.
6. Per un’analisi più approfondita, controllare nat_rule.log, firewall_rule.log e fwlog.log.
7. Per il contesto VPN o XFRM, controllare anche charon.log, strongswan.log e xfrmi.log. Se la regola NAT continua a non funzionare, La regola del firewall non funziona: controlla ordine, corrispondenza e registri e Utilizza lo strumento Packet Capture in WebAdmin ti aiuteranno a restringere il campo. I nomi dei servizi e i file di registro rilevanti possono essere trovati in Risoluzione dei problemi Sophos Firewall: Services e registri. Per i casi di supporto, è possibile esportare i registri con Sophos Firewall Salva registri per supporto e analisi.

NAT Lista di controllo delle regole

• La regola NAT ha un nome e una descrizione univoci.
• Lo scopo, la persona responsabile e l’ultima revisione sono documentati.
• I campi Original e Translated sono stati testati rispetto a un flusso di test reale.
• La regola NAT è superiore alle regole NAT più generali.
• Sono presenti regole firewall appropriate e la registrazione è attiva.
• I valori Firewall Rule ID e NAT Rule ID previsti sono stati controllati in Log Viewer.
• Per DNAT, la zona di destinazione è impostata correttamente dopo NAT e la rete di destinazione prima di NAT.
• DNAT è stato testato esternamente, non solo internamente al LAN.
• Per i servizi pubblici, sono state verificate le restrizioni sulla fonte, l’IPS, l’alternativa WAF e il livello di patch.
• Per VPN-NAT, il routing, il percorso IPsec, SD-WAN e le reti sovrapposte sono documentati.
• Il loopback o il DNS diviso è una decisione consapevole.
• Le regole riflessive sono attive solo se è davvero necessario eseguire il mirroring del traffico del server in uscita.
• Le regole NAT vecchie o temporanee sono disabilitate o rimosse.

Domande frequenti