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

NAT ändrar adresser eller portar i ett paket. Det avgör däremot inte om anslutningen är tillåten och skapar inte heller någon rutt. För att dataflödet ska fungera måste NAT-regeln, brandväggsregeln, routningen och returvägen stämma överens.

Den bästa utgångspunkten är därför inte frågan ”Vilken typ av NAT behöver jag?”, utan: Vilken adress eller port ska ändras mellan in- och utgående trafik? Om det inte finns något tydligt svar ligger lösningen oftast i routningen eller brandväggsregeln, inte i NAT.

⚠️ En NAT-regel är inte en tillåtelseregel. Om brandväggsregeln tillåter trafiken men ingen NAT-regel matchar vidarebefordrar SFOS paketet utan översättning. Om motsvarande brandväggsregel saknas kasseras och loggas paketet.

När ska NAT användas?

• LAN-klienter ska nå internet: vanligtvis SNAT med MASQ.
• En intern tjänst ska vara nåbar via en offentlig adress: DNAT; kontrollera först om WAF bör användas för HTTP/HTTPS.
• Den externa och interna porten skiljer sig åt: tjänsteöversättning med Translated service (PAT).
• Interna klienter använder det offentliga namnet på en intern server: använd helst split DNS eller en särskilt avgränsad Loopback Rule.
• Icke-överlappande nät kommunicerar via ett plats-till-plats-VPN: normalt routning och brandväggsregler utan NAT.
• Näten överlappar: planera NAT utifrån VPN-typen; improvisera inte med en generell MASQ-regel.
• Åtkomst ska endast tillåtas eller blockeras: ändra brandväggsregeln; skapa ingen NAT-regel.

För den konkreta uppgiften att publicera en server beskriver Publicera en server med DNAT på Sophos Firewall assistenten, en manuell regel, härdning, driftsättning och återställning. Den här artikeln förklarar NAT-modellen så att du kan tolka sådana regler och felsöka problem.

Andra närliggande specialfall är NAT64 med Direct Web Proxy, Proxy ARP för ytterligare offentliga IPv4-adresser och NAT vid IPsec-problem.

Tolka Original och Translated korrekt

Under Rules and policies > NAT rules > Add NAT rule beskriver Original paketet som det ser ut när det anländer till brandväggen. Translated beskriver den ändring som SFOS tillämpar på paketet.

Regeln väljs utifrån följande fält:

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

Fälten Translated source (SNAT), Translated destination (DNAT) och Translated service (PAT) anger resultatet och är inga ytterligare matchningsvillkor. NAT-regler utvärderas uppifrån och ned; den första matchande regeln används.

NAT-regler finns för IPv4 och IPv6. Välj rätt adressfamilj under Rules and policies > NAT rules innan regeln skapas; IPv4-adresserna i exemplen hör inte hemma i en IPv6-regel. Add NAT rule > New NAT rule öppnar den manuella konfigurationen. Nya regler är aktiverade som standard. Rule position erbjuder Top och Bottom; senare kan ordningen ändras genom att dra reglerna. Kontrollera villkor och position före Save så att regeln inte oavsiktligt tar över produktionstrafik.

Två exempel på paketflöden

En klient med adressen 10.10.10.80 ansluter via Port2 till 198.51.100.20:443. En SNAT-regel kan ändra enbart källan till MASQ. Destinationen och tjänsten förblir Original.

När en tjänst publiceras ansluter en extern klient till 203.0.113.10:5555. DNAT ändrar destinationen till 172.16.16.10 och PAT ändrar tjänsten till 443. Regeln ser då ut så här:

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

PAT är alltså inte en egen typ av adress-NAT vid sidan av SNAT och DNAT, utan port- eller tjänsteöversättningen i en NAT-regel.

SNAT och MASQ för utgående trafik

SNAT ändrar källadressen. En typisk LAN-till-WAN-regel använder det interna nätet som Original source, WAN-gränssnittet som Outbound interface och MASQ som Translated source. Destinationen och tjänsten förblir Original eller begränsas till det omfång som faktiskt krävs.

MASQ använder som standard adressen för det utgående gränssnittet. Fabrikskonfigurationen innehåller Default SNAT IPv4 för detta ändamål. Om regeln inte behövs rekommenderar Sophos att den inaktiveras i stället för att tas bort, eftersom den kan skapas på nytt när ett WAN-gränssnitt skapas eller uppdateras.

Efter en migrering från SFOS 17.5 eller tidigare kan dessutom en inaktiverad standardregel för SNAT visas längst ned i tabellen. Den är avsedd att ersätta Linked MASQ-regler som rensats bort och får inte förväxlas med en aktiv fabriksregel.

Flera interna klienter eller servrar kan använda samma offentliga käll-IP: SFOS skiljer deras anslutningar åt med olika portnummer. Denna tilldelning av källportar är inte DNAT-vidarebefordran av en tjänst till en server.

Skapa en fristående SNAT-regel från LAN till WAN

En fristående SNAT-regel kan betjäna flera brandväggsregler. Kontrollera först befintliga NAT-regler, rutten, utgående gränssnitt och returvägen; spara det tidigare tillståndet med ID och positioner. Exemplet tillåter endast HTTPS från klientnätet till en bestämd testdestination. Ersätt alla adresser och gränssnitt med egna värden.

1. Öppna Rules and policies > NAT rules, välj IPv4 och Add NAT rule > New NAT rule. Ange Rule name, exempelvis LAN-Web-Standalone-MASQ. Välj Top eller Bottom under Rule position och placera sedan regeln medvetet ovanför mer generella matchande regler; lägg den inte överst utan kontroll.
2. Ange Original source som Clients_LAN (10.10.10.0/24), Original destination som ett värdobjekt för 198.51.100.20 och Original service som HTTPS. Dokumentationsadressen är ingen verklig testserver. För generell internetåtkomst kan destinationerna breddas medvetet; begränsa ändå tjänsterna till det som behövs.
3. Ange Translated source (SNAT) som MASQ, Translated destination (DNAT) och Translated service (PAT) som Original. Välj det verkliga LAN-gränssnittet under Inbound interface, här Port2, och WAN-gränssnittet under Outbound interface, här Port1. Välj Save och anteckna NAT Rule ID.
4. Välj IPv4 > Add firewall rule > New firewall rule under Rules and policies > Firewall rules om ingen lämplig tillåtelseregel finns. Ange namn och position, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks med samma destination och Services HTTPS. Konfigurera lämpligt skydd och Log firewall traffic, sedan Save. Skapa ingen ytterligare Linked NAT Rule.
5. Upprätta en ny HTTPS-anslutning till den egna testdestinationen och avsluta den normalt. Jämför båda Rule IDs i Log Viewer; Packet capture ska visa den förväntade WAN-källadressen på utgången. Vid fel NAT-matchning, kontrollera högre regler först; om svar saknas, kontrollera routning och returväg. Återställ genom att bara inaktivera tillagda regler och återställa ändrade positioner; ta inte bort en delad tillåtelseregel. Verifiera det tidigare tillståndet med en ny session.

Skapa en LAN-till-WAN-regel med länkad NAT

För att tillåta ett avgränsat IPv4-flöde kan du länka SNAT när du skapar brandväggsregeln. Kontrollera först om en befintlig SNAT-regel redan översätter flödet som avsett; i så fall behövs ingen ytterligare Linked NAT Rule. Rutten och returvägen måste vara korrekta oberoende av NAT.

1. Öppna Rules and policies > Firewall rules, välj IPv4 och skapa en regel via Add firewall rule > New firewall rule. Välj ett tydligt namn, exempelvis LAN-Web-Out, och en lämplig position; ställ in Action på Accept och aktivera Log firewall traffic.
2. Ställ in Source zones på LAN och begränsa Source networks and devices till det klientnät som behöver åtkomst. Använd exempelvis ett nätverksobjekt Clients_LAN för 10.10.10.0/24; anpassa namnet och subnätet till den egna miljön. Ställ in Destination zones på WAN. Välj de nödvändiga destinationerna under Destination networks och endast de tjänster som behövs under Services, exempelvis HTTPS för detta webbflöde. Any är inget generellt krav. Ta hänsyn till DNS och andra nödvändiga tjänster separat.
3. Välj Create linked NAT rule. Ge NAT-regeln ett eget namn, exempelvis LAN-Web-MASQ, och en lämplig position. Ställ in Translated source (SNAT) på MASQ: flödet ska använda adressen för det faktiska utgående gränssnittet, medan brandväggsregeln fortsätter att begränsa källor, destinationer och tjänster.
4. Välj först Save i konfigurationen för länkad NAT och därefter Save igen för brandväggsregeln. Att bara spara den inbäddade NAT-dialogen slutför inte proceduren.
5. Kontrollera brandväggsregeln under Firewall rules och den länkade SNAT-regeln under NAT rules; anteckna båda posterna och deras Rule IDs. Kontrollera ordningen i båda tabellerna separat. En matchande NAT-regel högre upp kan få företräde; länkningen garanterar ingen prioritet.
6. Upprätta en faktiskt ny anslutning från en tillåten klient till den tillåtna destinationen och tjänsten och avsluta sedan testanslutningen på normalt sätt, så att en sessionslogg kan skapas. Filtrera på flödet i Log Viewer och jämför Firewall Rule ID och NAT Rule ID med de antecknade ID-värdena. Om brandväggs-ID är fel, kontrollera först brandväggsvillkoren och regelordningen; om NAT-ID är fel, kontrollera först högre placerade NAT-regler. Att båda posterna finns bekräftar inte i sig att internetåtkomsten fungerar.

Viktiga begränsningar för SNAT

Utöver MASQ kan Translated source (SNAT) använda en enskild IP-adress eller ett IP-intervall. SFOS 22-beskrivningen tillåter uttryckligen varje IP-adress som tilldelats ett gränssnitt som källa och anger Add för att skapa IP-/intervallobjektet. Beskrivningen av NAT-typer i SFOS 23 inkluderar fortfarande enskilda IP-adresser och intervall; utelämnade meningar i Add-beskrivningen visar inte att stödet tagits bort. Den fasta adressen måste vara nåbar i den egna miljön och passa den förväntade returvägen.

• Ett intervall under Translated source skapar ingen fast ett-till-ett-mappning. SFOS använder nästa lediga adress i intervallet.
• Ett offentligt gränssnitt som ingår i en brygga kan inte användas som gränssnitt för käll-NAT. Om ett gränssnitt som används senare läggs till i en brygga tar SFOS bort de berörda SNAT-reglerna.
• Override source translation for specific outbound interfaces gör det möjligt att använda olika översatta källor för olika utgående gränssnitt i en och samma SNAT-regel. Lägg till fler mappningar med Expand.
• För route-based VPN med Any som lokala och fjärranslutna subnät, eller med en dual-IP-konfiguration, kan MASQ använda XFRM-adressen som inre källadress. WAN-adressen är fortfarande synlig i den yttre tunnelheadern.

Dokumentera därför de berörda reglerna innan ett gränssnitt läggs till i en brygga eller produktionspooler för SNAT ändras. Testa dem sedan med ett faktiskt nytt trafikflöde.

DNAT, PAT, Loopback och Reflexive Rules

DNAT ändrar destinationsadressen. PAT ändrar dessutom tjänsten eller porten som adresseras. Protokollet måste förbli detsamma: TCP kan översättas till en annan TCP-port och UDP till en annan UDP-port, men TCP kan inte översättas till UDP.

Om flera ursprungliga tjänster eller Any väljs måste Translated service (PAT) vara Original. Entydig portvidarebefordran använder en specifik ursprunglig tjänst och en specifik översatt tjänst. Translated destination (DNAT) kan vara en IP-adress eller FQDN. Tjänsteöversättning stöder en enda målport eller lika många ursprungliga och översatta portar: exempelvis flera portar inom en ursprunglig tjänst till en port (many-to-one), eller lika stora portuppsättningar (many-to-many). Many-to-many kräver lika antal portar; flera separat valda ursprungliga tjänster tillåter inte PAT-översättning. Protokollet måste alltid förbli detsamma.

Brandväggsregeln som hör till DNAT

För inkommande trafik fastställer SFOS först vilken DNAT-regel som matchar. Därefter utvärderas brandväggsregeln. Då gäller följande ovanliga men viktiga mappning:

• Destination zone: zonen för den interna destinationen efter DNAT, exempelvis DMZ.
• Destination networks: den offentliga destinationsadressen före DNAT.
• Services: utan PAT, tjänsten som anslutningen gäller. Med PAT innehåller brandväggsregeln i Sophos officiella exempel både den ursprungliga och den översatta tjänsten.

I motsatt riktning utvärderas brandväggsregeln först. Därefter tillämpar SFOS den matchande SNAT-regeln.

En NAT-regel ersätter inte denna brandväggsregel. För en fullständig DNAT-konfiguration med källbegränsning, IPS, loggning och externt acceptanstest, använd DNAT-runbooken.

Loopback Rule

En Loopback Rule kan ge interna klienter åtkomst via den offentliga IP-adressen eller det offentliga FQDN-namnet. Split DNS är ofta tydligare: internt matchas samma namn direkt mot serverns interna adress, så att hairpin-NAT inte behövs.

Server Access Assistant skapar endast en Loopback Rule om ett WAN-gränssnitt på brandväggen väljs som offentlig adress och External source networks and devices är inställt på Any. Om en offentlig IP-adress anges eller en mer begränsad extern källa väljs skapas inte denna automatiska Loopback Rule.

Vid manuell DNAT-konfiguration är Create loopback rule ett separat val. Den ursprungliga DNAT-regeln måste använda Original source Any, Translated source (SNAT) MASQ och Translated destination (DNAT) som inte är Original. Detta är inte assistentens fält. Ta inte bort en extern källbegränsning bara för att få loopback: överväg först split DNS eller en separat planerad intern regel. Testa intern åtkomst och externa begränsningar var för sig efter att du sparat.

Reflexive Rule

En Reflexive Rule skapar en omvänd SNAT-regel för en DNAT-regel. Den vänder på matchningsvillkoren och kan översätta utgående servertrafik med motsvarande offentliga identitet. Om den ursprungliga destinationen inte är en IP-adress eller om den översätts använder Reflexive Rule MASQ som översatt källa.

Vid manuell DNAT-skapande genererar Create reflexive rule denna spegelregel; Create loopback rule är ett separat val. Genererade regler använder den ursprungliga regelns ID och namn men förblir fristående. Identifiera och inaktivera varje genererad post separat vid återställning och verifiera med nya interna och externa anslutningar.

Loopback och Reflexive Rules förblir fristående regler. Om den ursprungliga DNAT-regeln ändras eller tas bort uppdateras eller tas de inte bort automatiskt. Kontrollera därför de härledda reglerna separat när den offentliga adressen, den interna destinationen eller tjänsten har ändrats.

Om en DNAT-regel fördelar trafik mellan flera interna destinationer betraktas de som tillgängliga om Health check inte är aktiverat. För First alive är hälsokontrollen obligatorisk. För övriga fördelningsmetoder måste den aktiveras uttryckligen och konfigureras med ICMP eller TCP efter tjänstens behov, så att SFOS inte skickar ny trafik till en server som inte fungerar.

Välj fördelning mellan flera DNAT-destinationer

Välj Load balancing method efter önskat beteende, inte bara antalet servrar:

• Round robin: anslutningar går till destinationerna i turordning. Med 10.10.10.1 till 10.10.10.3 går den fjärde förfrågan tillbaka till .1. Det ger fördelning utan sessionsbindning.
• First alive: alla förfrågningar går till den första tillgängliga servern; övriga är reserver. Health Check avgör när växling sker.
• Random: slumpmässigt val utan fast klientkoppling.
• Sticky IP: en hash av källa och ursprunglig destination binder paret till en server. Med Health Check aktiverat tar en tillgänglig destination över vid fel. När ursprungsservern återkommer går bara nya anslutningar tillbaka till den; befintliga sessioner behålls.
• One-to-one: första ursprungliga destinationen till första översatta, andra till andra och så vidare. Båda listorna måste innehålla lika många IP-adresser. Det är en fast DNAT-mappning, inte tilldelning från en SNAT-pool.

Välj Probe method ICMP eller TCP under Health check och för TCP den verkliga porten som ska kontrolleras. Probe interval anger tiden mellan kontroller, Response time-out svarstiden och Deactivate host after antalet misslyckade försök. Ping bekräftar att värden kan nås, inte att webbtjänsten fungerar. Anpassa tiderna till tjänsten; alltför känsliga värden kan utesluta en långsam destination i onödan. Verifiera fördelningen med nya anslutningar och ett planerat avbrott och återställande före produktion. Spara tidigare metod och kontrollvärden för återställning.

Kontrollera portkonflikter före publicering

Anteckna de faktiskt konfigurerade portarna för WebAdmin, User Portal och VPN Portal under Administration > Admin and user settings innan HTTPS vidarebefordras. Utgå inte från en äldre NAT-guide för att avgöra vilken tjänst som använder 443. WebAdmin och User Portal behöver var sin unik port. Lös i första hand konflikter med en annan publicerad IP eller extern tjänsteport; ändra inte hanteringsportar utan förberedelse. Säkra vid behov en oberoende hanteringsväg och testa sedan portaler, VPN-klienter och extern DNAT-åtkomst separat. DNAT-guiden beskriver publiceringen.

Linked NAT Rules och Server Access Assistant

En Linked NAT Rule är alltid en SNAT-regel som är länkad till en brandväggsregel. Brandväggsregelns samtliga matchningsvillkor fortsätter att gälla, inklusive användare och scheman. I NAT-regeln kan endast översatta källor och gränssnittsspecifika översatta källor ändras.

Länkningen åsidosätter inte den normala regelordningen för NAT: en fristående NAT-regel som ligger högre upp kan matcha först. Om en generell SNAT-regel redan omfattar samma trafik rekommenderar Sophos att ingen ytterligare Linked NAT Rule läggs till. I MTA-läge skapar SFOS däremot automatiskt en sådan regel.

Server access assistant (DNAT) skapar en DNAT-regel, en Reflexive Rule och en brandväggsregel. En Loopback Rule läggs bara till för den tidigare beskrivna kombinationen av ett WAN-gränssnitt och den externa källan Any. Assistenten placerar reglerna överst i tabellerna och aktiverar dem. Kontrollera därefter källorna, regelpositionen, de extra regler som skapats och användningen av alias-IP. För en alias-IP anger assistenten först det fysiska gränssnittet som översatt källa i Reflexive respektive Loopback Rules. Om aliasadressen ska användas måste motsvarande IP Host väljas manuellt.

Rensa migrerade Linked MASQ-regler försiktigt

Efter migrering kan ett meddelande visas under filtret. Delete linked NAT rules (only MASQ; Destination: WAN) tar endast bort länkade regler med översatt källa MASQ vars brandväggsregel enbart använder destinationszonen WAN. Det är inte riskfri städning: användarvillkor, scheman och tidigare ordning kan ingå i det avsedda beteendet.

Spara först konfiguration, ID och berörda flöden. Den inaktiverade Default SNAT IPv4 eller Default SNAT IPv6, eller en medvetet planerad fristående SNAT-regel, måste ersätta den nödvändiga översättningen på rätt position. Kontrollera ersättningen och brandväggsbegränsningarna, aktivera den och jämför nya tillåtna och förbjudna testflöden innan gamla regler tas bort. Återställ sparade regler och ordning om resultaten skiljer sig. Understood. Don’t delete rules behåller reglerna och döljer meddelandet permanent; X döljer det tillfälligt. Dokumentera först vid osäkerhet, i stället för att ta bort.

Håll isär NAT, VPN och SD-WAN

NAT ändrar inte routingbeslutet. Även efter översättningen behöver SFOS en rutt till destinationen. För VPN-trafik beror rätt konfigurationsplats dessutom på tunneltypen:

• Policy-based IPsec: använd NAT-inställningarna för IPsec-anslutningen när de lokala och fjärranslutna subnäten ska översättas, särskilt om de överlappar. Om en ytterligare SNAT-regel ska matcha policy-based trafik måste dess Outbound interface vara inställt på Any; regeln tillämpas inte om specifika WAN-gränssnitt väljs.
• Route-based IPsec med valda lokala och fjärranslutna subnät: använd NAT-inställningarna för IPsec-anslutningen för att översätta dessa subnät.
• Route-based IPsec med Any/Any: använd NAT-regler för den vidarebefordrade trafiken.

För VPN-trafik ska Inbound interface i NAT-regler vara Any. För VPN och DNAT från offentliga till privata IP-adresser måste även Outbound interface vara Any. Det är ett krav för gränssnittsmatchning, inte tillåtelse för godtyckliga källor eller tjänster; Original-villkor och brandväggsregler begränsar dem fortfarande.

Icke-överlappande nät behöver i regel inte NAT. För överlappande nät ska de verkliga och översatta näten på båda sidor dokumenteras. Annars blir DNS, regler och loggar senare tvetydiga.

För DNAT till en server bakom en route-based IPsec-tunnel dokumenterar Sophos en särskild SD-WAN-konfiguration: DNAT-regeln använder MASQ som Translated source så att svaren går tillbaka till brandväggen. SD-WAN-rutten matchar den ursprungliga WAN-adressen eller WAN-gränssnittet som destination och, när PAT används, den externa porten. Gateway-objektet pekar på XFRM-gränssnittet. Använd inte detta specialfall som generell DNAT-modell för lokala servrar.

Nå en fjärrserver med DNAT och en SD-WAN-rutt

Denna IPv4-procedur gäller endast en server bakom brandväggen på den andra platsen. Kontrollera först route-based IPsec-anslutningar på båda brandväggarna, tunnelstatus, fjärråtkomst, tillåtna källor, tjänst, returväg och befintlig NAT-/SD-WAN-ordning. Spara konfiguration och berörda positioner. Exemplet använder extern TCP 5555 och intern TCP 443, inte offentlig RDP; ersätt dokumentationsadresserna med egna värden. Separat brandväggstillåtelse och härdning krävs fortfarande.

1. Skapa Remote_Web under Hosts and services > IP host > Add: IP version IPv4, Type IP, IP address med fjärrserverns adress, exempelvis 172.16.16.10; välj Save.
2. Välj ett tydligt namn under Routing > Gateways, IPv4 gateway > Add. Ange Gateway IP som fjärrgatewayens adress, exempelvis 10.12.13.2, och Interface som motsvarande XFRM-gränssnitt, exempelvis xfrm1-10.12.13.1. Ange IP-adressen till en faktiskt nåbar värd bakom gatewayen under Monitoring condition; verifiera gateway- och tunnelstatus före publicering.
3. Skapa en namngiven IPv4-regel under Rules and policies > NAT rules > Add NAT rule > New NAT rule. Begränsa Original source till tillåtna externa källor. Ange Original destination som det publicerade WAN-gränssnittet, exempelvis #Port1, Translated source (SNAT) som MASQ, Translated destination (DNAT) som Remote_Web, Original service som ett TCP 5555-objekt och Translated service (PAT) som TCP 443. Ange båda gränssnittsfälten som Any i detta VPN-DNAT-fall. Kontrollera positionen och välj Save. I detta specialfall säkerställer MASQ returvägen till brandväggen.
4. Välj IPv4 > Add under Routing > SD-WAN routes och ange ett namn. Ta bort Any under Destination networks och välj samma ursprungliga WAN-gränssnitt #Port1, inte Remote_Web. Ta bort Any under Services och välj den externa tjänsten TCP 5555, inte TCP 443. Välj Primary and Backup gateways under Link selection settings och ange fjärrgatewayen som Primary gateway; välj bara en reservgateway om dess fjärrväg finns och har verifierats. Välj Save.
5. Skapa en ny anslutning från en tillåten extern källa. Kontrollera NAT-/brandväggs-ID, översatt destination och tjänst, XFRM-utgång och svar i paketinsamlingen. Vid fel utgång, kontrollera SD-WAN-villkor, ordning och gatewayövervakning; om svar saknas, kontrollera fjärrtjänsten och returvägen. För fler servrar via samma gateway, utöka samma SD-WAN-rutt med deras externa portar/WAN-adresser; använd separata rutter för olika gateways. Tillagda kombinationer måste fortsatt begränsas av NAT och brandvägg.

Om ändringen misslyckas, inaktivera den nya fjärr-DNAT-regeln, ta bort den nya SD-WAN-rutten eller återställ den tidigare konfigurationen och positionerna. Ta inte bort delade gateway-/värdobjekt. Återställ härledda NAT-regler separat och verifiera det tidigare flödet med en ny anslutning.

Översätta trafik från brandväggen med sys-traffic-nat

NAT-regler i WebAdmin översätter vidarebefordrad trafik. För trafik som genereras av brandväggen och för översättning av adresser på brandväggens gränssnitt används sys-traffic-nat i Device Console.

Vanliga användningsfall för källöversättning via CLI:

• Skicka brandväggsgenererade DHCP- och autentiseringsförfrågningar via plats-till-plats-IPsec; översättning kan även stödja förfrågningar till brandväggstjänster via VPN-tunnlar. Detta ersätter inte tjänste- och VPN-konfigurationen.
• Använda aliasadresser när det finns fler WAN-länkar än fysiska WAN-gränssnitt, med översättning från det fysiska gränssnittet till rätt alias.
• Skicka e-post med den alias-källadress som uppströmsreläet eller MX-posten kräver.
• Dölja interna adresser för WAN-destinationer, exempelvis DHCP-förfrågningar från ett LAN-gränssnitt; använda en specifik källidentitet för interna MPLS-destinationer eller utvalda webbservrar.

Anteckna först destination, nödvändig källidentitet, rutt och motpartens krav. Utlös sedan den konkreta tjänsten igen och kontrollera källadress och svar i paketinsamlingen. En CLI-post ensam visar inte att DHCP, autentisering eller e-post fungerar.

⚠️ Detta Device Console-kommando ändrar systemgenererad trafik. Spara först hela utdata från show advanced-firewall. CLI-poster för NAT bearbetas i den ordning som visas där.

Logga in i Command-line console och välj 4 – Device Console, inte Advanced Shell. Följande exempel översätter trafik till den enskilda destinationen 192.0.2.10 som går via Port1, så att aliasadressen 203.0.113.10 används:

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

Destinationen, nätmasken, gränssnittet och SNAT-adressen måste anpassas till den egna miljön. För en enskild värd krävs 255.255.255.255; en bredare mask omfattar hela det matchande destinationsnätet. Utan interface gäller posten för trafik till den angivna destinationen via samtliga brandväggsgränssnitt.

Återställ ändringen genom att använda samma fullständiga mappning med 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

Systemgenererad trafik använder som standard WAN Link Load Balancing. Med en alias-IP är huvudgränssnittet fortfarande avgörande för routingbeslutet; sys-traffic-nat ser endast till att den önskade aliasadressen visas som källa. En synlig post bekräftar därför konfigurationen, inte rutten, returvägen eller tjänsten.

Ändra och testa NAT-regler på ett säkert sätt

Använd tabellen och räknarna medvetet

Under Rules and policies > NAT rules väljer IPv4 eller IPv6 regelfamiljen. Disable filter döljer filtret, Enable filter visar det och Reset filter återställer det. Att dölja ett filter inaktiverar ingen NAT-regel. Kontrollera att rätt poster visas före ändringar.

Markerade regler kan inaktiveras tillsammans med Disable eller tas bort med Delete. Dra Rule handle för att flytta en regel; specifika regler ska ligga före generella. More options erbjuder aktivering/inaktivering, redigering, borttagning och tillägg av en intilliggande regel. Unlink rule tar bort länkningen till brandväggsregeln: dokumentera först beroendet och använd inte detta som en felsökningsgenväg.

Reset usage count under More options nollställer användningsräknaren. Anteckna först värdet och tidpunkten, skapa ett nytt testflöde och kontrollera ökningen tillsammans med Rule IDs; räknaren ensam identifierar inte testflödet. Det tidigare värdet återställs inte. Spara ID, villkor, status och ordning före regeländringar, välj helst inaktivering i stället för borttagning och ändra endast markerade poster. Återställ status och positioner vid problem och testa med en ny session; en borttagen regel måste återställas från den sparade konfigurationen.

SFOS utvärderar NAT endast för det första paketet i en anslutning. Befintliga sessioner behåller sin tidigare översättning när en regel ändras eller flyttas. Ett test efter ändringen måste därför skapa en ny anslutning. Annars riskerar du att utvärdera det gamla tillståndet.

Ett tillförlitligt test börjar med ett dokumenterat flöde: källa, destination, tjänst, inkommande och utgående gränssnitt samt förväntat Firewall Rule ID och NAT Rule ID. Gör sedan följande:

1. Skapa en ny anslutning och filtrera efter källa, destination och tjänst i Log Viewer.
2. Jämför förväntat Firewall Rule ID och NAT Rule ID.
3. Om NAT Rule ID är fel kontrollerar du reglerna ovanför samt samtliga Original-fält och gränssnitt.
4. Kontrollera under Diagnostics > Packet capture att paketet anländer och vidarebefordras med de förväntade adresserna.
5. Kontrollera rutten, returvägen, målsystemet och dess lokala brandvägg.

För DNAT måste minst ett test göras utifrån. Intern åtkomst till det offentliga namnet testar endast split DNS eller loopback, inte den faktiska publiceringen från internet.

Tolka resultaten korrekt

• Firewall Rule ID och NAT Rule ID stämmer: matchningen är korrekt; undersök därefter målsystemet, returvägen och Security Profiles.
• Firewall Rule ID stämmer, men NAT Rule ID är fel: en annan NAT-regel har företräde eller så matchar inte Original-villkoren.
• NAT Rule ID saknas trots att översättning förväntas: ingen NAT-regel matchar; om brandväggsregeln tillåter flödet fortsätter det utan översättning.
• Ett annat Firewall Rule ID visas: kontrollera zoner, nätverk, tjänst och brandväggsreglernas ordning.
• Ingen loggpost: loggning är inte aktiverad eller trafiken når inte brandväggen. Gör en paketinsamling på WAN-gränssnittet eller det inkommande gränssnittet och kontrollera överordnade routrar eller molnregler.
• DNAT matchar, men servern svarar inte: kontrollera servertjänsten, den lokala brandväggen, standardgatewayen och om returvägen är asymmetrisk.

För en djupare analys, se Testa en brandväggsregel, Undersök regelmatchning, Klassificera kasserade paket och Packet Capture i WebAdmin.

Förstå NATRule i XML API

För automatiseringar representerar NATRule samma Original-/Translated-modell. Objektbeskrivningen Add NAT policy / Edit NAT policy är identisk i de jämförda referenserna för SFOS 22 och SFOS 23. Detta belägger dokumentationens innehåll, inte att körningen lyckas på en viss build. Före ett skrivjobb gäller de centrala säkerhetsreglerna för XML API: strikt begränsad hanteringsåtkomst, TLS-verifiering, separat tjänstekonto, skyddade hemligheter, säkerhetskopia, läsfråga och en explicit operation på Set som har bekräftats för objektet och den installerade builden. Objektbeskrivningen ensam är inte en fullständig körbar begäran.

Matchningsvillkor, översättning och regelidentitet

• OriginalSourceNetworks innehåller upprepningsbara Network-poster för de ursprungliga källorna; OriginalDestinationNetworks innehåller Network-poster för de ursprungliga destinationerna. OriginalServices innehåller upprepningsbara Service-poster. Dessa är objektreferenser för matchning före NAT, inte en brandväggstillåtelse. Referensen anger högst 60 tecken för vart och ett av dessa nätverks- och tjänstenamn.
• TranslatedSource, TranslatedDestination och TranslatedService är var sitt enskilt värde för översättningen. För ett oförändrat fält använder exemplet Original; för maskering av källan används MASQ. Uppgifter som IPAddress, IPRange, IPList, FQDN eller TCPUDP_Service beskriver lämplig objekttyp i exemplet, inte ett godtyckligt bokstavligt värde att skicka. Kontrollera de faktiskt befintliga värd-, intervall-, list-, FQDN- och tjänsteobjekten samt stödet för dem i builden. De tidigare beskrivna PAT-begränsningarna gäller fortfarande. För tjänsteobjektets värde respektive namn i TranslatedService anger parametertabellen uttryckligen högst 60 tecken; för TranslatedSource och TranslatedDestination anger denna tabell inget motsvarande maxvärde.
• InboundInterfaces och OutboundInterfaces innehåller var och en upprepningsbara Interface-poster. De begränsar gränssnittsmatchningen men skapar ingen rutt. VPN-/DNAT-villkoren som förklarats ovan gäller även automatiseringar: inkommande och utgående VPN-trafik använder Any; vid DNAT från offentliga till privata adresser är även utgången Any. Detta upphäver inte begränsningarna genom Original-villkor och brandväggsregler.
• Name direkt under NATRule är regelns obligatoriska namn: högst 60 tecken, UTF-8 tillåts, inget kommatecken. Description är valfritt och begränsat till 255 tecken. IPFamily tillåter IPv4 eller IPv6; referensen anger IPv4 som standardvärde. Status tillåter Enable eller Disable; det dokumenterade standardläget är aktiverat. Ange familj och status medvetet i den godkända skrivpayloaden i stället för att förlita dig på standardvärden utan kontroll.
• LinkedFirewallrule är i exemplet endast avsett för att skapa en Linked NAT Rule i en Set-begäran. Identifiera den befintliga brandväggsregeln exakt för detta. En länkning gör inte SNAT-regeln till en DNAT-regel och ger den ingen garanterad prioritet; begränsningarna för Linked NAT gäller fortfarande.

Planera position och gränssnittsåsidosättning separat

Position visar värdena top, bottom, after och before med denna stavning i XML-exemplet. För relativ placering innehåller After respektive Before ett eget Name med namnet på referensregeln. Detta namn är inte det obligatoriska namnet på den nya eller redigerade regeln. Exemplet anger uttryckligen att båda blocken endast är tillämpliga på Set-begäranden. Använd endast den referens som passar önskad placering; kopiera inte båda exempelblocken utan kontroll. Kontrollera först att ankaret finns och dess aktuella position, och kontrollera därefter den faktiskt sparade ordningen. En lyckad objektstatus bevisar inte att den planerade trafiken träffar denna regel först.

OverrideInterfaceNATPolicy är en separat omkopplare med Enable eller Disable, det dokumenterade standardvärdet Disable och koppling till gränssnittsspecifik SNAT-källöversättning. Endast när åsidosättningen är aktiverad hör motsvarande InterfaceNATPolicyList till det planerade fallet. Den innehåller upprepningsbara Override-block med specific_interface för det utgående gränssnittet och specific_translatedsourceid för den önskade översatta källan där. Det specifika gränssnitt som beskrivs som ett obligatoriskt fält är alltså ett krav inom detta villkorade åsidosättningsfall, inte ett krav för varje NAT-regel.

Exempelkommentarerna anger på ett ställe det avvikande namnet OverrideInterfaceDefaultNATPolicy, medan elementet och parametertabellen använder OverrideInterfaceNATPolicy. Hitta inte på någon ytterligare XML-tagg utifrån detta. Listan beskrivs i tabellen som valfri med standardvärdet NULL; detta är ingen instruktion att skicka texten NULL. Exemplet ger inte heller någon tydlig placering för det monitorindex som nämns där. Om en automatisering är beroende av sådana oklara detaljer ska de klarläggas före skrivning i API help för den installerade builden eller med supporten; gissa inte ytterligare syntax eller verkan.

Load Balancing och Health Checks är villkorade fält

NATMethod är relevant för DNAT-fördelning, inte som ett obligatoriskt val för en vanlig SNAT-regel. API-referensen beskriver dess tillämplighet med Hosted Server-källzonen WAN och en Protected Server av typen IP Range eller IP List. Använd inte dessa äldre benämningar som ytterligare XML-fält som saknas i exemplet. De dokumenterade värdena är Round-robin, First_alive, Random, StickyIP och OnetoOne; standardvärdet i referensen heter Sticky IP. Beslutsstödet för de fem metoderna och kravet på lika många adresser för One-to-one finns ovan.

HealthCheck tillåter Enable eller Disable och beskrivs i API-tabellen som valfritt med standardvärdet OFF samt endast tillämpligt vid Load Balancing. Detta innebär inte att varje NAT-begäran behöver fält för hälsokontroll. Det är dock inte heller ett löfte om att First_alive ska fungera utan kontroll: de konkreta NAT-anvisningarna gör Health Check obligatoriskt för First alive. Planera kontrollen och värdena medvetet för detta fall och verifiera dem i det sparade tillståndet i stället för att förlita dig på det generella standardvärdet OFF.

När Health Check är aktiverat finns kontrollvärdena i blocket LoadBalance:

• ProbeMethod: ICMP eller TCP. Markeringen som obligatoriskt gäller här för fallet med aktiv kontroll.
• Port: endast för TCP, intervall 1–65535; härled inget generellt portkrav för ICMP.
• ProbeInterval: kontrollintervall i sekunder, intervall 5–65535, dokumenterat standardvärde 60. Intervallet kommer från parametertabellen; det tomma exempelelementet anger inget eget numeriskt värde.
• ResponseTimeOut: tidsgräns för svar i sekunder, intervall 1–10, dokumenterat standardvärde 2.
• DeactivateHostAfter: antal misslyckade kontrollförsök före inaktivering, valfritt, intervall 1–10, dokumenterat standardvärde 3.

Lyft inte ut markeringarna som obligatoriska för metod, intervall och tidsgräns för svar ur deras sammanhang med aktiverad Health Check. Även dessa uppgifter bekräftar endast det beskrivna API-kontraktet. Om kontrollen, tjänsten och önskad failover fungerar måste verifieras med det nya dataflöde som beskrivits ovan och ett planerat test av avbrott och återkomst.

Utvärdera NATRule-svar objektspecifikt

Följande mappningar kommer från Status Message Information för detta objekt. De är XML-objektstatuskoder, inte HTTP-statuskoder. Värdena Message.* är oupplösta meddelandenycklar i referensen, inte verifierade meddelandetexter från en brandvägg. Bedöm därför operation, kod, faktiskt svar och sparat tillstånd tillsammans; härled inte ett gränsvärde eller ett säkert nytt försök från nyckelnamnet.

• Add NAT policy: 200 är kopplat till Message.NATPolicyAddSuccess, 500 till Message.NATPolicyAddFail och 502 till Message.NATPolicyRecordExists.
• Edit NAT policy: 200 är kopplat till Message.NATPolicyUpdateSuccess, 500 till Message.NATPolicyUpdateFail och 502 till Message.NATRuleUpdateRecordExist. Särskilt nyckeln för 502 skiljer sig från den vid skapande.

För båda operationerna Add NAT policy och Edit NAT policy dokumenteras dessutom samma mappningar:

Därför får särskilt 504 här inte tolkas enbart utifrån den allmänna API-tabellen som en misslyckad borttagning på grund av en referens: dessa NATRule-rader hör till Add/Edit och anger nyckeln för portkonflikt. Inte heller koderna 548 och 549 belägger något konkret maximalt antal servrar, trots att nyckeln är identisk.

Före varje nytt skrivförsök, även vid timeout eller förmodad framgång, ska den faktiskt sparade NAT-posten läsas och kontrolleras i Rules and policies > NAT rules: namn, familj, status, Original-/Translated-värden, gränssnitt, åsidosättningsmappningar, villkorade kontrollvärden och position. Jämför svaret och det tidigare sparade tillståndet; kringgå inte konflikter genom namnbyte, bredare villkor eller upprepning utan kontroll. Oklara skillnader ska stoppa jobbet. Kontrollera först efter tillståndskontrollen, med en ny session, båda Rule IDs och den faktiska översättningen. För återställning ska det sparade tillståndet och ordningen återställas och härledda regler hanteras separat; den praktiska serverpubliceringen beskrivs fortfarande i DNAT-runbooken.

Vanliga frågor