Definition og formål

En NAT-firewall kombinerer netværksadresseoversættelse (NAT) med en firewall-funktion. NAT gør det muligt at forbinde et internt net (ofte med private IP-adresser) til et eksternt net (typisk med offentlige IP-adresser) ved at oversætte adresser, og i mange tilfælde også porte.

I praksis bruges NAT til at:

  • håndtere mange interne enheder bag én eller få eksterne IP-adresser,
  • udstille specifikke tjenester fra en intern vært mod omverdenen,
  • reducere behovet for offentlige IP-adresser til hver intern enhed.

Det centrale er, at NAT ikke alene “åbner” adgang: den fungerer sammen med firewallregler. Hvis regler og portmapping ikke passer sammen, virker forbindelsen ikke.

Et enkelt modelbillede: hvad der oversættes hvornår

Du kan tænke NAT-firewallens logik som to faser:

  1. Oversættelse af adresser (og ofte porte) når trafikken sendes ud eller sendes ind.
  2. Firewallkontrol, der afgør om trafikken må passere på de relevante retninger og datatyper.

To hyppige NAT-retninger er:

  • Ude→ude-oversættelse (typisk SNAT): Når intern trafik går ud mod internettets destinationer, oversættes kildens adresse (og evt. port) til den/de eksterne adresse(r) der må bruges.
  • Ind→interne (typisk DNAT/port forwarding): Når omverdenen skal nå en intern tjeneste, oversættes destinationens adresse (og ofte port) til den interne vært.

Begrænsningen/undtagelsen du bør have i baghovedet: NAT-opførsel kan ændre sig afhængigt af systemets implementering, og “NAT-regler” kan også være kombineret med stateful firewalllogik. Derfor skal du altid verificere effekten i den konkrete enhed eller software.

Komponenter du skal få på plads

Når du konfigurerer en NAT-firewall, vil du typisk arbejde med følgende elementer:

1) Interne og eksterne interfaces

Definér hvilken side der er “intern” og hvilken side der er “ekstern” (ofte WAN/LAN). NAT-regler kobles normalt til disse retninger, så forkert interfacevalg er en hyppig årsag til fejl.

2) NAT-regeltype og omfang

Vælg hvilken NAT-type der passer til opgaven:

  • SNAT til udgående forbindelser fra interne noder.
  • DNAT/port forwarding til indgående forbindelser til en intern tjeneste.
  • I nogle opsætninger bruges flere regler, afhængigt af hvilke interne subnets eller værter der skal oversættes på hvilken måde.

3) Portmapping (hvis du udstiller tjenester)

Hvis du vil nå en intern service udefra (fx en webserver), skal du definere portmapping fra en ekstern port til en intern port på den interne vært.

Vigtigt punkt: portmapping og firewallregler skal være konsistente. Det er ikke nok at lave NAT alene; indgående firewallregler skal tillade den trafik, NAT sender videre.

4) Firewallregler før/efter NAT (afhængig af system)

Mange implementeringer evaluerer firewallregler i en bestemt rækkefølge, og NAT kan påvirke hvilke match der rammer. Derfor er det afgørende at:

  • sikre at indgående regler matcher den “destination”, som systemet ser på tidspunktet for beslutningen,
  • sikre at udgående regler tillader trafik tilbage og frem.

Som praktisk tommelfinger: hvis indgående trafik ikke når frem, undersøges typisk både NAT-mapping og firewalltilladelser.

Forskelle og grænser: hvad kan ændre udfaldet

Der er flere steder hvor “det samme ord” kan betyde forskellige konkrete handlinger:

  • Address scope: Om NAT gælder for hele subnet, for enkelte værter, eller kun for bestemte protokoller/porte.
  • Portbevaring og session-state: Nogle opsætninger forsøger at bevare portnumre, andre kan allokere anderledes afhængigt af konflikt og politik.
  • Returntrafik: Hvis du udstiller en intern tjeneste, skal både indgående og den relaterede returtrafik kunne etableres gennem korrekt oversættelse.

Begrænsning: Hvis du har komplekse routingscenarier eller flere NAT-lag, kan asymmetri i forbindelsesretninger give problemer. I så fald skal du især kontrollere, om samme logik/rute bruges for både for- og returtrafik.

Praktisk brug: sådan kan du selv kontrollere om det virker

Du kan bruge en enkel kontrolproces, uden at gætte:

  1. Afklar målet

    • Er det mest relevant SNAT (intern trafik ud), eller DNAT/port forwarding (indgående til en intern tjeneste)?

  2. Dokumentér mappingen

    • Hvilken ekstern adresse (eller interface) modtager trafikken?
    • Hvilken intern vært og port skal trafikken ende ved?

  3. Kontrollér firewalltilladelserne

    • Tillad indgående trafik på den relevante protokol/port fra de kilder, du ønsker.
    • Tillad relateret/etableret trafik tilbage (hvis systemet understøtter stateful logik).

  4. Validér i begge retninger

    • Test en udgående forbindelse fra intern vært til en ekstern destination (for SNAT).
    • Test en indgående forbindelse udefra til den eksterne port og observer om den ender hos den interne vært (for DNAT).