Hoppa till innehållet
Avanet

Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT

NAT är ett av ämnena på Sophos Firewall som snabbt blir förvirrande i praktiken. Termerna låter liknande, regelmasken fungerar med Original och Translated, och i Log Viewer ser du andra adresser än förväntat beroende på plats.

Den här artikeln förklarar de viktigaste NAT-typerna, visar typiska praktiska fall och beskriver ett DNAT-exempel med en lämplig brandväggsregel.

Den viktigaste praktiska punkten är: NAT måste beaktas tillsammans med brandväggsregel, routing, returväg och loggning. Många NAT-problem uppstår inte från själva översättningen, utan från felaktig regelordning, en missförstådd Original destination, saknad loggning eller tester från fel nätverk.

Orientering

Innan man bygger en NAT-regel bör det först vara klart vilket problem som verkligen löses. NAT översätter adresser eller portar, men ersätter inte brandväggsavstånd och ren routingdesign.

Vilken NAT artikel passar?

NAT överlappar snabbt med brandväggsregler, routing, WAF, VPN och Packet Capture. Beroende på uppgiften är den här grundläggande artikeln inte alltid det bästa sättet att börja:

Detta håller felsökningen stramare: klargör först om det handlar om översättning, release, routing, webbserverskydd eller paketflöde. Därefter bör endast det påverkade lagret ändras.

NAT är översättning, inte release

Nätverksadressöversättning ändrar adresser eller portar för ett paket när det passerar genom Sophos Firewall. NAT avgör dock inte ensam om trafik är tillåten.

⚠️ En NAT-regel tillåter inte trafik. Regeln översätter endast adresser eller portar. En lämplig brandväggsregel krävs också alltid för trafik genom brandväggen.

Typiska NAT fall:

  • Interna klienter får tillgång till Internet via den offentliga WAN-IP.
  • En intern server publiceras via en offentlig IP.
  • En offentlig hamn översätts till en annan intern hamn.
  • Överlappande nätverk översätts för VPN-anslutningar.
  • Interna klienter får åtkomst till en intern server via det offentliga DNS-namnet.

Snabbt beslut: NAT eller ingen NAT?

Många NAT-fel uppstår eftersom NAT används som standardlösning, även om routing eller en brandväggsregel skulle vara tillräcklig. Före varje ny NAT-regel bör du först bestämma dig för om en adress eller en port verkligen behöver ändras.

  • Kunden från LAN ska ha åtkomst till Internet normalt: En allmän SNAT- eller MASQ-regel är vanligtvis tillräcklig.
  • Intern server bör vara tillgänglig från Internet: Använd DNAT eller för HTTP/HTTPS kontrollera WAF först.
  • En annan port bör användas externt än internt: Planera DNAT med PAT och lägg till lämplig brandväggsregel.
  • Interna användare får åtkomst till samma offentliga FQDN: Kontrollera först delad DNS, använd endast loopback NAT om det behövs.
  • Lokala och fjärranslutna VPN-nätverk är tydliga: Använder vanligtvis inte NAT, utan bygg routing- och brandväggsregler rent.
  • VPN-nätverk överlappar varandra eller så kräver fjärrstationen en specifik källa: Använd riktade SNAT eller DNAT med dokumenterat ersättningsnätverk.
  • Endast en brandväggsregel bör tillåtas eller begränsas: Bygg inte NAT. Justera brandväggsregeln.

Om svaret på “Vad ska översättas?” är oklart, bör en NAT-regel inte skapas. Kontrollera sedan först paketflödet, destinationsadressen, returvägen och Log Viewer. Speciellt för interna VLAN, plats-till-plats VPN utan överlappande nätverk och routade servernätverk är ingen NAT ofta den renare lösningen.

Förstå NAT grunderna

Regelmasken blir mycket lättare om du först skiljer på originaltrafik och översatt trafik. Det blir då tydligare om källan, destinationen eller tjänsten behöver ändras.

Den huvudsakliga NAT-arten

  • SNAT: Översätter källan IP. Vanligtvis när interna klienter eller servrar ska ha åtkomst till Internet med en specifik offentlig IP.
  • MASQ: Översätter källan IP till IP för det utgående gränssnittet. Detta är standardväskan för LAN till WAN.
  • DNAT: Översätter destinationen IP. Detta gör en intern server tillgänglig via en offentlig IP.
  • PAT: Översätter port eller tjänst. Det betyder att en extern port pekar på en annan intern port.
  • Loopback NAT: Tillåter intern åtkomst via offentliga IP eller offentliga FQDN. Interna klienter använder samma DNS-namn som externa användare.
  • Reflexiv regel: Skapar en reflekterande källa NAT-regel. Detta gör att en publicerad server kan visas för utgående trafik med en lämplig offentlig identitet.

Som en mental modell hjälper det: NAT svarar inte på frågan “Är denna trafik tillåten?”, utan snarare “Hur ska adressen eller porten se ut på vägen?”

Läs originalet och korrekt översatt

I NAT regler beskriver Original trafiken när den anländer till Sophos Firewall. Translated beskriver det efter översättning.

  • Original source: Källadress före NAT.
  • Translated source (SNAT): Källadress till NAT.
  • Original destination: Måladress före NAT.
  • Translated destination (DNAT): Måladress efter NAT.
  • Original service: Service eller port före NAT.
  • Gränssnitt och VPN: Any är ofta korrekt för inkommande och utgående gränssnitt i DNAT- eller VPN-scenarier, eftersom VPN-tunnlar inte alltid hanteras som vanliga fysiska gränssnitt.
  • Översatt tjänst (PAT): Tjänst eller port till NAT.

Om det finns fel bör du först notera hur paketet ser ut före NAT. Sedan definierar du vad brandväggen ska göra med den.

Schemalägg NAT före ändring

Innan du gör en NAT-ändring bör du inte bara titta på själva NAT-regeln. Hela paketflödet är avgörande: Var kommer paketet, vilken brandväggsregel tillåter trafiken, vilken NAT-regel översätter det, vart tar svaret vägen och hur kontrolleras resultatet?

Dessa punkter bör vara tydliga före ändringen:

  • Paket före NAT: Källa, destination och tjänst måste matcha Original-sidan av regeln NAT.
  • Paket enligt NAT: Translated source, Translated destination och Translated service måste ställas in medvetet.
  • Tillåtande brandväggsregel: NAT tillåter inte trafik. Utan en lämplig brandväggsregel förblir översättningen ineffektiv.
  • Mer allmänna NAT-regler: Den första matchande NAT-regeln vinner. En bred SNAT- eller MASQ-regel kan skymma mer specifika regler.
  • Returväg: Många NAT-problem är faktiskt problem med routing, returväg eller destinationssystem.
  • Testmetod: Log Viewer, regel-ID, NAT Rule ID och Packet Capture bör förberedas före testning.

Förstå och säkert konfigurera Sophos Firewall-regler hjälper dig att hitta rätt brandväggsregel. Om det är oklart om regeln över huvud taget gäller är Sophos Firewall Regeln inte gäller: Kontrollera orsaker den bästa felsökningsstarten.

Praktiska exempel: När använder du vad?

  • Kunder från LAN bör få tillgång till Internet: MASQ eller SNAT. Exempel: 10.10.10.80 går ut med brandväggen WAN-IP.
  • Intern webbserver bör vara tillgänglig från extern: DNAT. Exempel: Den offentliga WAN-IP pekar på 172.16.16.10.
  • En annan port används externt än internt: PAT. Exempel: Extern TCP 5555, intern TCP 443.
  • Interna användare använder samma FQDN som externa användare: Loopback NAT. Exempel: service.example.com pekar på samma tjänst internt och externt.
  • Publicerad server ska verka utgående med specifik offentlig IP: SNAT eller Reflexive Rule. Exempel: En e-postserver skickar med definierad publik IP.
  • VPN-nätverk överlappar: SNAT eller DNAT. Exempel: Plats A ser Plats B via ett översatt nätverk.
  • Intern trafik bör förbli oförändrad: Ingen NAT. Routing och brandväggsregler är tillräckliga.

All trafik behöver inte NAT. Mellan interna VLAN, över plats-till-plats VPN utan överlappande nätverk eller till direkt dirigerade nätverk är NAT ofta till och med skadligt eftersom loggar, fjärrstationer och målsystem förlorar den verkliga källan IP. Bra NAT-planering avgör därför först om översättning överhuvudtaget behöver göras.

NAT arter i praktiken

Följande NAT-typer löser olika uppgifter. I produktiva miljöer bör man medvetet välja vilken översättning som är nödvändig istället för att använda NAT som en allmän lösning för routingproblem.

SNAT: Källa NAT

SNAT ändrar källadressen. Det klassiska fallet är utgående internetåtkomst från LAN. Klienterna behåller internt sina interna IP-adresser, men brandväggens publika adress eller en definierad publik IP visas externt.

Typisk SNAT-regel för LAN till WAN:

  • Original source: internt LAN eller servernätverk.
  • Translated source (SNAT): MASQ eller fast offentlig IP.
  • Original destination: Any.
  • Translated destination (DNAT): Original.
  • Original service: Any eller definierad Services.
  • Översatt tjänst (PAT): Original.
  • Inbound interface: internt gränssnitt eller Any.
  • Utgående gränssnitt: WAN-gränssnitt. För enkla miljöer är en generisk SNAT-regel ofta tydligare än många individuella länkade NAT-regler.

MASQ: Maskerad

MASQ är en bekväm SNAT-variant. Som standard översätter MASQ källadressen till IP-adressen för det utgående gränssnittet. För normal internetåtkomst är detta vanligtvis WAN-IP.

I den grundläggande konfigurationen har Sophos Firewall en standardregel för SNAT med MASQ. Om du inte vill använda den här regeln är avaktivering vanligtvis renare än att ta bort. Annars kan standardregeln dyka upp igen när du skapar eller uppdaterar ett WAN-gränssnitt.

Stötesten: Med ruttbaserade VPN:er kan MASQ se annorlunda ut än förväntat. Om lokala och fjärrundernät är inställda på Any eller dubbla IP-konfigurationer används, kan brandväggen använda XFRM-IP som den översatta källan. I Packet Capture eller tcpdump kan du sedan se WAN-IP i den yttre rubriken och XFRM-IP i det inre sammanhanget. Andra stötestenar gäller för policybaserade IPsec. Om översatt trafik måste tilldelas en specifik IPsec-tunnel, kan IPsec-rutter och inställningen Utgående gränssnitt i SNAT-reglerna vara kritiska. Processen är i IPsec Skapa rutt på Sophos Firewall.

NAT på VPN, SD-WAN och överlappande nätverk

NAT blir snabbt mer komplex i VPN och SD-WAN miljöer än enkel LAN till WAN trafik. Den viktigaste principen förblir densamma: För det första måste den förväntade vägen vara tydlig. Du bestämmer sedan om NAT är nödvändigt.

Typiska scenarier:

  • Site-to-site VPN med unika nätverk: För det mesta ingen NAT, men rena brandväggsregler och routing.
  • Site-to-site VPN med överlappande nätverk: Riktad SNAT- eller DNAT-regel med dokumenterat backup-nätverk.
  • Ruttbaserad VPN med XFRM och SD-WAN: Kontrollera XFRM-gränssnitt, rutt, SD-WAN-rutt och NAT tillsammans.
  • Policybaserad IPsec med översatt trafik: Kontrollera IPsec-rutten och SNAT-regeln med matchande Outbound interface.
  • Remote Access VPN till interna nätverk: Normalt ingen NAT, såvida inte ett målsystem förväntar sig en specifik källa.

För överlappande nätverk bör NAT inte improviseras. Båda sidor behöver veta vilket verkligt nätverk som ligger bakom vilket översatt nätverk. Annars fungerar individuella tester, men applikationer, DNS, loggning eller åtkomstregler blir svåra att förstå senare. Om en VPN-tunnel är grön men ingen nyttotrafik flödar är NAT bara en av flera möjliga orsaker. Kontrollera då IPsec-status, Route Lookup, brandväggsregel, SD-WAN-rutt och Packet Capture parallellt. För ett strukturerat flöde passar Sophos Firewall IPsec VPN-felsökning, SD-WAN Routing för Reply Packets och System Traffic och kontroll av MTU och MSS på Sophos Firewall vid VPN-problem.

DNAT: Destination NAT

DNAT ändrar destinationsadressen. Du kan till exempel publicera en intern server via en offentlig IP eller en offentlig port. Inkommande trafik till WAN-adressen översätts till den interna servern.

Typisk DNAT regel:

  • Original source: Any eller definierade IP-nätverk.
  • Original destination: WAN-IP eller WAN värdobjekt.
  • Original service: extern tjänst, till exempel HTTPS eller Synology_5555.
  • Translated destination (DNAT): intern server.
  • Översatt tjänst (PAT): Original eller intern destinationsport.
  • Translated source (SNAT): mestadels Original.
  • Inbound interface: Any eller WAN gränssnitt.
  • Utgående gränssnitt: mestadels Any vid DNAT.

För offentliga tjänster bör du inte bara bygga NAT, utan också omedelbart kontrollera loggning, IPS, källbegränsningar, geo-IP logik och patchnivå för målservern. Mer detaljerade steg-för-steg-instruktioner finns i artikeln Publicera server till Sophos Firewall via DNAT. För HTTP- och HTTPS-applikationer bör du också kontrollera om en Sophos Firewall WAF passar bättre än ren DNAT. DNAT är en portvidarebefordran. WAF kan inkludera värdnamn, certifikat, sökvägar, webbskyddsprofiler och eventuellt autentisering. För enkla icke-HTTP-tjänster förblir DNAT ofta korrekt; för allmänt tillgängliga webbapplikationer är WAF ofta en bättre utgångspunkt.

PAT: Portadressöversättning

PAT ändrar tjänsten eller porten. På Sophos Firewall ansvarar fältet Översatt tjänst (PAT) för detta.

Exempel:

  • Extern TCP 5555 till intern TCP 443.
  • Extern TCP 20120 till intern TCP 22.
  • Extern TCP 8443 till intern TCP 443.

Den externa klienten ansluter till en offentlig port, men internt adresseras en annan port. Viktigt: Protokollet måste vara korrekt. TCP kan översättas till TCP, UDP till UDP. En översättning från TCP till UDP är inte ren portvidarebefordran.

DNAT exempel med brandväggsregel

Exemplet visar den typiska publiceringen av en interntjänst. Vad som är avgörande är att regeln NAT och brandväggsregeln matchar.

Praktiskt exempel: Publicera Synology via DNAT

I exemplet ska en tjänst vara tillgänglig via en offentlig WAN-IP. Tjänsten Synology_5555 adresseras utifrån. Internt lyssnar servern på HTTPS. Så regeln NAT översätter den offentliga destinationsadressen till den interna servern och den offentliga tjänsten till den interna tjänsten.

Sophos Firewall Add NAT rule med DNAT och PAT Exempel på en Synology-tjänst
Sophos Firewall - DNAT Regel med public service och intern destinationsport
Sophos Firewall Add firewall rule matchar DNAT-regeln med WAN-källor och målnätverksSERVER
Sophos Firewall - Brandväggsregel som matchar regeln DNAT
Exemplet är medvetet tekniskt. Hanteringsgränssnitt som NAS, RDP, SSH eller WebAdmin ska bara publiceras direkt om det verkligen är nödvändigt. I många fall är VPN eller ZTNA den bättre lösningen.

DNAT regel fält för fält

  • Rule name: Namn tydligt, till exempel DNAT_SYNOLOGY_5555.
  • Beskrivning: Dokumentera varför regeln finns och vem som skapade den. Detta kommer att hjälpa enormt senare.
  • Rule position: Specifika regler bör placeras ovanför allmänna regler.
  • Original source: Kan begränsas i regeln NAT. I praktiken är det ofta renare att behålla källbegränsningen i brandväggsregeln så att samma begränsning inte behöver bibehållas två gånger.
  • Original destination: Den offentliga destinationsadressen före NAT. Det är bättre att använda ett värdobjekt för WAN-IP än WAN-gränssnittet direkt. Ett värdobjekt förblir vanligtvis mer stabilt under gränssnittsändringar eller justeringar.
  • Original service: Tjänsten eller porten som kan nås utifrån, till exempel Synology_5555.
  • Translated source (SNAT): För klassiska DNAT regler vanligtvis Original. Ändra bara om den interna servern ska se brandväggen som källa. Men då förlorar du den riktiga klienten IP.
  • Translated destination (DNAT): Den interna servern eller en lista över servrar att omdirigera till.
  • Översatt tjänst (PAT): Den interna tjänsten eller porten som ska skrivas om till, till exempel HTTPS. Om ingen portändring är nödvändig förblir tjänsten Original.
  • Inbound interface: Gränssnitt där trafik kommer in. För DNAT ofta Any eller WAN. För VPN-sammanhang krävs ofta Any eftersom VPN inte behandlas som vanliga gränssnitt.
  • Utgående gränssnitt: För DNAT vanligtvis Any, eftersom brandväggen beslutar om routing och målzon.

Skapa brandväggsregel för regeln DNAT

En DNAT-regel räcker inte. Dessutom krävs en brandväggsregel som tillåter trafik.

För DNAT är det viktigt: Brandväggsregeln hänvisar till trafiken i DNAT-kontexten. Detta verkar ovanligt i början, särskilt med målzoner och målnätverk.

  • Source zones: Mest WAN när åtkomst kommer från Internet.
  • Source networks and devices: Om möjligt, inte Any om det kan undvikas. Bättre att använda länder, individuella IP-adresser, nätverk, FQDN-värdar eller grupper.
  • Destination zones: Zonen för det interna målet, till exempel SERVER eller DMZ, inte bara WAN.
  • Destination networks: Den offentliga destinationsadressen eller WAN-värdobjektet från Original destination.
  • Services: Den externa tjänsten från Original service, det vill säga porten som klienter kommer åt utifrån.
  • Log firewall traffic: Aktivera för publicerade tjänster. Utan loggning är Log Viewer inte till hjälp med denna regel. Om globala användare behöver åtkomst och Source networks and devices inte kan begränsas på ett meningsfullt sätt, bör du fortfarande skärpa regeln: öppna endast nödvändiga portar, aktivera IPS, slå på loggning, håll målsystemet uppdaterat och använd MFA, VPN eller ZTNA om möjligt.

💡 Allmänt tillgängliga tjänster skannas ofta väldigt snabbt av bots. Sophos Firewall Threat Feeds hjälper till att blockera kända skadliga IP-adresser, domäner eller webbadresser tidigt. Detta ersätter inte en ren regel, men det minskar avsevärt onödig bottrafik.

Loopback-regel: Åtkomst internt via det offentliga DNS-namnet

En Loopback-regel krävs om interna klienter ska nå en intern server via dess offentliga IP eller offentliga FQDN.

Exempel:

  • Externt pekar service.example.com på den offentliga WAN-IP.
  • Internt använder klienter samma namn service.example.com.
  • Utan loopback går trafiken från LAN till brandväggens publika IP och måste gå tillbaka till den interna servern.

I enkla miljöer är delad DNS ofta renare: Internt pekar service.example.com direkt på den interna servern IP. Då finns det inget behov av Hairpin-NAT. Om delad DNS inte är möjlig kan en loopback-regel vara vettig.

Med Server Access Assistant kan Sophos Firewall automatiskt skapa loopback-regler. Detta fungerar dock bara under vissa förhållanden, till exempel om WAN-gränssnittet används som Public IP och externa källor är lämpligt definierade i allmänhet. Med manuella regler bör loopback planeras medvetet och sedan testas.

Reflexiv regel: Spegla utgående trafik från servern

En Reflexiv regel är en automatiskt genererad SNAT-regel för DNAT-regeln. Den här regeln kan vara användbar om du vill att den publicerade servern ska visas med början med en specifik offentlig IP. Viktigt: Normala svar på en inkommande DNAT-anslutning kräver vanligtvis inte en separat reflexiv regel. Stateful brandvägg säkerställer att svarspaketen tillhör den befintliga anslutningen.

Du bör bara aktivera reflexiva regler om du förstår syftet. I miljöer med flera WAN IP-adresser, flera DNAT-regler eller flera servrar, kan en ytterligare SNAT-regel annars resultera i beteende som är svårt att förstå.

⚠️ Automatiskt skapade Loopback- eller Reflexive Rules förblir självständiga regler. Om den ursprungliga DNAT-regeln senare ändras eller tas bort uppdateras dessa härledda regler inte automatiskt logiskt. Efter varje ändring av originalregeln måste tillhörande Loopback och Reflexive Rules kontrolleras manuellt.

Avancerade NAT-funktioner

Dessa alternativ behövs inte i alla miljöer. De blir viktiga när interna klienter använder samma offentliga namn, flera målservrar är inblandade eller NAT-regler skapas från brandväggsregler.

Server Access Assistant eller manuell NAT regel?

Server Access Assistant kan automatiskt skapa DNAT, loopback, reflexiv och brandväggsregler. Detta är användbart om du snabbt vill publicera en tjänst.

För produktiva miljöer är manuella regler ofta lättare att förstå:

  • Man kan se exakt vilken regel som gör vad.
  • Källrestriktioner bibehålls medvetet i brandväggsreglerna.
  • Regeln NAT är fortfarande smalare.
  • Regelposition och loggning är inställda rent.
  • Senare förändringar är mindre överraskande.

Assistenten är till hjälp, men ersätter inte förståelsen av de individuella reglerna.

Länkade NAT-regler

En Länkad NAT-regel skapas från en brandväggsregel. Det är en källregel NAT i regeltabellen för NAT.

Det låter praktiskt, men det har begränsningar:

  • De flesta av matchningskriterierna kommer från brandväggsregeln.
  • I regeln NAT kan du bara justera vissa NAT-fält.
  • En mer allmän NAT-regel ovan kan fortfarande matcha först.
  • Många länkade NAT-regler gör snabbt NAT-tabellen förvirrande.

För nya, enkla konfigurationer är en oberoende NAT-regel i Rules and policies > NAT rules vanligtvis mer förståelig. Länkade NAT-regler är särskilt användbara i migreringsscenarier eller mycket riktade specialfall.

Lastbalansering och Health Check på DNAT

DNAT kan göra mer än enkel portvidarebefordran. Om flera interna servrar lagras som Translated destination kan brandväggen distribuera trafik.

Möjliga metoder:

  • Round robin: enkel distribution utan sessionsbeständighet.
  • First alive: primär server med failover.
  • Slumpmässig: slumpmässig fördelning.
  • Sticky IP: Samma käll-destinationskombination stannar på samma server.
  • En-till-en: fast tilldelning mellan original och översatt destination. Om du vill att brandväggen ska upptäcka om en målserver är tillgänglig måste Hälsokontroll vara aktiverat. Utan Health Check anser brandväggen att servrar är tillgängliga även om de inte svarar.

NAT beställning

Sophos bearbetar NAT regler från topp till botten. Den första matchningsregeln vinner. Därefter kommer ytterligare NAT-regler inte längre att kontrolleras.

Rekommendation:

  • Specifika DNAT reglerar upp
  • Specifika SNAT-regler ovanför allmänna MASQ-regler
  • Placera standard SNAT regel medvetet
  • Kontrollera länkade NAT-regler regelbundet
  • Ta bort eller inaktivera gamla migreringsregler om de inte längre behövs

En beprövad beställning i många miljöer ser ut så här:

  1. Svart hål DNAT eller blockregler för kända oönskade källor, om sådana regler används.
  2. Mycket specifika DNAT regler för publicerade tjänster.
  3. Särskilda SNAT regler för enskilda servrar, partnernätverk eller VPN specialfall.
  4. Loopback eller reflexiva regler när de medvetet behövs.
  5. Allmänna SNAT eller MASQ regler för normal Internetåtkomst.

Detta är inte en hård och snabb lag, men det är ett bra testramverk. Det specifika testflödet är alltid avgörande. Om en bred MASQ-regel eller en gammal länkad NAT-regel placeras ovanför en specifik regel, ser den nya regeln korrekt ut men nås aldrig. När du gör ändringar bör du inte bara kontrollera själva regeln, utan även reglerna direkt ovanför och under den.

För offentliga tjänster kan en regel för svart hål DNAT före den produktiva DNAT-regeln vara användbar om vissa dåliga IP-listor eller länder ska fångas upp tidigt. Processen beskrivs i Sophos Firewall: Blockera länder och skadliga IP-adresser.

NAT byt och kontrollera säkert

NAT ändrar paketflödet. Det är därför du bör behandla det som en produktiv förändring: förbered, testa, logga och rulla tillbaka rent vid behov.

Rulla ut NAT ändringar på ett säkert sätt

NAT ändringar påverkar ofta produktiv trafik omedelbart. Detta är särskilt viktigt för publicerade servrar, VPN specialfall, flera WAN-IP adresser eller brandväggsregler som används av externa partners. Därför bör NAT inte behandlas som en ren objektbyte, utan snarare som en liten förändring med en test- och reservväg.

Innan du gör en produktiv förändring bör du kort notera:

  • Föregående NAT Rule ID och regelnamn: I Log Viewer kan du sedan kontrollera om den nya regeln verkligen gäller.
  • Förväntat testflöde: Källa, Destination, Service och Riktning måste vara tydliga innan du sparar.
  • Beroende brandväggsregel: NAT och brandväggsregeln måste matcha men kontrolleras separat.
  • Reservväg: Om det finns problem kan den nya regeln avaktiveras och den gamla regeln kan aktiveras igen.
  • Testfönster: Externa tjänster, VPN fjärrplatser eller partneråtkomst bör inte avbrytas obemärkt.

När du gör större ändringar rekommenderar vi att du först duplicerar befintliga NAT-regler eller skapar en ny specifik regel ovanför dem istället för att direkt konvertera den enda fungerande regeln. Den gamla regeln förblir initialt inaktiverad eller ligger under som referens. Efter ett lyckat test kan det tas bort eller tydligt dokumenteras.

Regelpositionen är också viktig: En ny specifik SNAT- eller DNAT-regel är till ingen nytta om en mer allmän regel ovan redan matchar samma trafik. Därför inkluderar ändringen alltid ett loggvisartest med förväntade Firewall Rule ID och NAT Rule ID. För externt tillgängliga tjänster bör testet inte bara utföras från din egen LAN. Ett internt test för den offentliga FQDN kontrollerar ofta loopback eller delad DNS, men inte verklig åtkomst från Internet. DNAT-acceptans kräver minst ett externt test, till exempel via mobilkommunikation, en extern plats eller ett kontrollerat porttest.

Kontrollera NAT och brandväggsregeln tillsammans

Ett vanligt tankefel är: “NAT-regeln är korrekt, så den borde fungera.” Det är bara hälften sant.

För trafik till jobbet behöver du:

  1. Routing till brandväggen
  2. lämplig NAT regel om översättning är nödvändig
  3. lämplig brandväggsregel
  4. rätt returväg
  5. lämpliga säkerhetsprofiler
  6. ingen uppströms blockering, till exempel leverantörsrouter, molnsäkerhetsgrupp eller målbrandvägg Följande gäller även för DNAT: Brandväggsregler för DNAT-trafik använder målzonen efter NAT, men den offentliga måladressen före NAT som målnätverk. Det är just denna punkt som är avgörande vid många felsökningar.

Läs Firewall Rule ID och NAT Rule ID korrekt

Vid NAT-fel bör du inte bara kontrollera om det finns någon loggpost. Vad som är avgörande är om loggposten matchar den förväntade brandväggsregeln och den förväntade NAT-regeln. Av denna anledning är Firewall Rule ID och NAT Rule ID mer användbara än regelnamnet enbart, eftersom namn kan ändras, väljas på liknande sätt eller skäras av i skärmdumpar.

En kort tolkning hjälper:

  • Förväntad Firewall Rule ID och förväntad NAT Rule ID synlig: Regelmatchningen är i princip korrekt. Kontrollera sedan returväg, målsystem, säkerhetsprofil och applikation.
  • Förväntad Firewall Rule ID synlig, men felaktig NAT Rule ID: Brandväggsregeln matchar, men kriterierna för NAT eller NAT matchar inte. Kontrollera NAT regelposition, Original fält och mer allmänna NAT regler.
  • Andra Firewall Rule ID synliga: En annan brandväggsregel vinner. Kontrollera brandväggsregelordning, zoner, källa, destination och tjänst.
  • Ingen NAT Rule ID synlig, även om NAT förväntas: Ingen NAT-regel tillämpades eller så visas fel loggtyp eller flöde. Kontrollera NAT kriterier, riktning och verkligt testflöde.
  • Ingen loggpost synlig: Loggning saknas eller trafik når inte brandväggen. Kontrollera regelloggning, leverantörsrouter, VLAN, Gateway och Packet Capture. Speciellt med DNAT räcker det inte med ett enda lyckat eller misslyckat test utan en ID-jämförelse. Du bör notera vilka ID:n som förväntas, köra testet exakt en gång och sedan jämföra Log Viewer och Packet Capture. Om ID:n inte stämmer överens med förväntningarna, korrigeras matchningen och beställningen först, inte målservern.

Vanliga NAT-fel

När du hanterar NAT-problem är det bra att inte bygga om regler omedelbart. Först bör man klassificera den observerade defekten.

  • Inga loggposter i Log Viewer: Trafiken når inte brandväggen, loggning saknas eller filtret är felaktigt. Kontrollera leverantörsrouter, molnsäkerhetsgrupp, klient Gateway, brandväggsregelloggning och filter.
  • Logginmatning utan förväntad NAT Rule ID: Regeln NAT matchar inte eller en regel ovanför vinner. Original source, Original destination, checkservice och NAT beställning.
  • DNAT-regeln matchar, anslutningen fungerar fortfarande inte: Brandväggsregel, destinationsserver, returväg eller lokal serverbrandvägg blockerad. Jämför Firewall Rule ID, Packet Capture och serverloggar.
  • Intern åtkomst till offentliga FQDN fungerar inte: Delad DNS eller loopback NAT saknas. Kontrollera intern DNS-upplösning och avgör om delad DNS eller loopback är renare.
  • Extern klient ser felaktig källa-IP: SNAT eller Reflexive Rule ändrar källa oväntat. Kontrollera Translated source (SNAT) och automatiskt genererade regler.
  • VPN trafik använder oväntad källa IP: SNAT, XFRM, SD-WAN rutt eller IPsec rutt matchar inte. Kontrollera ruttsökning, SD-WAN-rutt, IPsec-rutt och NAT-regelposition.
  • Offentlig port som pekar på fel intern tjänst: PAT eller serviceobjekt är felaktigt inställt. Jämför Original service och Translated service (PAT). Denna översikt ersätter inte paketflödesanalys, men den sparar tid: Den separerar problem framför brandväggen, i NAT-logiken, i brandväggsregeln och på målsystemet.

Acceptanstest efter NAT ändringar

Efter en NAT-ändring ska du inte bara kontrollera om en enstaka ping eller en webbplats fungerar en gång. Testet måste matcha typen av översättning.

För SNAT eller MASQ:

  1. Definiera testklient och måltjänst.
  2. Kontrollera brandväggsregeln med Log firewall traffic.
  3. Kontrollera i Log Viewer vilka Firewall Rule ID och NAT Rule ID som gäller.
  4. På målsystemet eller extern testtjänst, kontrollera vilken källa IP som är synlig.
  5. Testa returvägen och sessionsbeteendet på flera WAN-länkar.

För DNAT eller PAT:

  1. Utför testet utanför ditt eget nätverk, inte bara från LAN.
  2. Jämför offentligt mål IP, extern port och intern målserver.
  3. Kontrollera Log Viewer Firewall Rule ID och NAT Rule ID.
  4. Använd Packet Capture för att kontrollera om paket anländer och fortsätter till den interna servern.
  5. Kontrollera på målservern om den lokala brandväggen, servicen och returvägen är korrekta.

För VPN-NAT:

  1. Kontrollera tunnelstatus och säkerhetsassociationer.
  2. Definiera ett konkret testflöde med källa, destination och tjänst.
  3. Kontrollera NAT regelposition och ruttsökning.
  4. Använd Packet Capture på båda sidor om fjärrplatsen tillåter åtkomst.
  5. Inkludera loggar från applikationen eller målsystemet så att inte bara brandväggssidan utvärderas.

Särskilt på avlägsna platser bör endast ett testfall ändras per ändring. Om brandväggsregeln, NAT, rutt, SD-WAN och målsystem justeras samtidigt, kan ett lyckat test knappast förklaras senare.

Felsökning

Den här beställningen hjälper till med NAT-problem:

  1. Öppna Loggvisare och filtrera efter källa IP, destination IP och tjänst.
  2. Kontrollera vilka Firewall Rule ID och NAT Rule ID som visas.
  3. Kontrollera NAT kontrollposition.
  4. Kontrollera brandväggsregelns position.
  5. Använd Diagnostics > Packet capture för att kontrollera om paket anländer och fortsätter.
  6. För djupare analys, kontrollera nat_rule.log, firewall_rule.log och fwlog.log.
  7. För VPN eller XFRM sammanhang, kontrollera även charon.log, strongswan.log och xfrmi.log. Om NAT-regeln fortfarande inte fungerar, hjälper Brandväggsregeln inte: kontrollera ordning, matchning och loggar och Använd verktyget Packet Capture i WebAdmin dig att begränsa det. Vilka tjänstnamn och loggfiler som är relevanta finns i Sophos Firewall Felsökning: Services och loggar. För supportärenden kan du exportera loggarna med Sophos Firewall Spara loggar för support och analys.

NAT Regelchecklista

  • Regeln NAT har ett unikt namn och en beskrivning.
  • Syfte, ansvarig person och senaste granskning dokumenteras.
  • Fälten Original och Translated testades mot ett verkligt testflöde.
  • NAT-regeln är över mer allmänna NAT-regler.
  • Lämpliga brandväggsregler finns på plats och loggning är aktiv.
  • Förväntade Firewall Rule ID och NAT Rule ID kontrollerades i Log Viewer.
  • För DNAT är målzonen korrekt inställd efter NAT och målnätverket före NAT.
  • DNAT testades externt, inte bara intern LAN.
  • För offentliga tjänster kontrollerades källrestriktioner, IPS, WAF alternativ och patchnivå.
  • För VPN-NAT dokumenteras routing, IPsec-rutt, SD-WAN och överlappande nätverk.
  • Loopback eller delad DNS är ett medvetet beslut.
  • Reflexiva regler är bara aktiva om den utgående servertrafiken verkligen behöver speglas.
  • Gamla eller tillfälliga NAT-regler inaktiveras eller tas bort.

Vanliga frågor

Tillåter en NAT-regel automatiskt trafik?

Nej. NAT översätter endast adress eller port. En lämplig brandväggsregel avgör också om trafik tillåts.

Varför fungerar inte DNAT även om regeln NAT ser korrekt ut?

Ofta saknas lämplig brandväggsregel, regeln använder fel destinationsnätverk för DNAT, en mer allmän NAT-regel finns ovanför den eller så svarar den interna servern inte korrekt.

När ska du använda MASQ istället för en fast SNAT-IP?

MASQ passar bra för normal Internetåtkomst via det utgående gränssnittet. En fast SNAT-IP är vettig om en server eller plats alltid måste visas för externa system med en specifik publik adress.

Behöver du NAT för VPN-anslutningar?

Inte i grunden. För unika nätverk är routing utan NAT vanligtvis renare. NAT är särskilt relevant för överlappande nätverk, speciella fjärrstationskrav eller vissa policybaserade IPsec specialfall.

Är Split DNS bättre än Loopback NAT?

Ofta ja. Om interna klienter kan lösa samma FQDN direkt till den interna servern IP, är delad DNS vanligtvis enklare och mer transparent. Loopback NAT är vettigt om delad DNS inte är möjlig eller inte är operativt önskvärd.

Ska du publicera offentliga webbapplikationer via DNAT?

Inte automatiskt. För HTTP- och HTTPS-applikationer bör WAF kontrolleras först. DNAT är mer lämplig för enkel portvidarebefordran, speciella protokoll eller fall där brandväggen inte ska ge webbserverskydd.