nftables i 2026: Komplet Guide til Linux Firewall, iptables-migration og Serverhærdning

Introduktion: Hvorfor nftables er uundgåeligt i 2026

Okay, lad os være ærlige: Hvis du stadig skriver iptables-regler i 2026, arbejder du med et forældet værktøj. Det er den ubekvemme sandhed, som overraskende mange Linux-administratorer stadig ikke har taget stilling til. Siden Linux-kernen introducerede nftables som efterfølgeren til iptables helt tilbage i kerne 3.13 (2014!), har alle større distributioner — Ubuntu 22.04+, Debian 11+, RHEL 9+, AlmaLinux 9+, Fedora 35+ — gjort nftables til standard-firewall-frameworket. Den iptables-kommando, du kører på moderne systemer, er faktisk iptables-nft, et kompatibilitetslag der oversætter iptables-syntaks til nftables-regler bag kulisserne.

Det handler ikke om at følge med moden. nftables leverer reelle forbedringer: renere syntaks, bedre ydeevne med store regelsæt, atomare regelopdateringer der eliminerer risikoen for inkonsistens, og avancerede datastrukturer som sets, maps og verdict maps — ting der simpelthen ikke eksisterer i iptables. For serveradministratorer der tager sikkerhed alvorligt, er nftables det rigtige fundament.

I denne guide gennemgår vi alt fra grundlæggende nftables-koncepter, over en komplet hærdet serverkonfiguration, migration fra iptables, avancerede funktioner som rate limiting og dynamiske blocklister, Fail2Ban-integration, til geo-blocking. Målet er at give dig en handlingsorienteret forståelse — med fungerende kodeeksempler du kan bruge direkte på dine servere.

nftables vs. iptables: De vigtigste forskelle

Før vi dykker ned i konfigurationen, er det værd at forstå præcis hvad nftables gør anderledes. Det handler ikke bare om ny syntaks — det er en fundamental arkitektonisk forbedring.

Samlet framework for alle protokoller

Med iptables var man nødt til at vedligeholde separate regelsæt for IPv4 (iptables), IPv6 (ip6tables), ARP (arptables) og bridging (ebtables). Fire separate værktøjer med fire separate konfigurationer — det var, helt ærligt, et rod at holde styr på. nftables samler det hele i ét framework med kommandoen nft. Med inet-familien kan du håndtere både IPv4 og IPv6 i ét enkelt regelsæt.

Ingen foruddefinerede tabeller og kæder

I iptables havde du faste tabeller (filter, nat, mangle, raw) med faste kæder (INPUT, OUTPUT, FORWARD). I nftables er der ingen foruddefinerede strukturer. Du opretter dine egne tabeller og kæder og definerer hvilke Netfilter-hooks de skal tilknyttes. Det giver langt mere fleksibel konfiguration uden at belaste Netfilter med kæder, der aldrig bruges.

Atomare regelopdateringer

Når du opdaterer regler i iptables, erstatter du dem én ad gangen. Det skaber korte øjeblikke med inkonsistens — og på en produktionsserver er det ikke fedt. nftables understøtter transaktioner: enten anvendes alle ændringer, eller ingen. Risikoen for at en server kortvarigt er ubeskyttet under en regelopdatering? Væk.

Avancerede datastrukturer

nftables introducerer sets, maps, verdict maps og sammenkædninger (concatenations), der ikke har nogen pendant i iptables. I stedet for lineær regelbehandling med O(n) kompleksitet kan du opnå O(1) opslag med hash-baserede sets. Det gør en kæmpe forskel, når du arbejder med store IP-lister eller komplekse regelstrukturer.

Sammenligningstabel

Egenskab	iptables	nftables
Protokoller	Separate værktøjer per protokol	Samlet inet-familie
Tabeller/kæder	Foruddefinerede, faste	Brugerdefinerede, fleksible
Regelopdatering	Sekventiel, ikke-atomisk	Atomare transaktioner
Datastrukturer	Lineær regelbehandling	Sets, maps, verdicts — O(1) opslag
Syntaks	Procedural, verbose	Deklarativ, kompakt
IPv4/IPv6	Separate regelsæt	Ét samlet regelsæt
Status i 2026	Forældet (compatibility layer)	Standard på alle større distroer

Grundlæggende nftables-koncepter

nftables bruger en hierarkisk struktur: Familie → Tabel → Kæde → Regel. Lad os gennemgå hvert lag.

Familier

En familie bestemmer hvilke pakker der behandles. De vigtigste er:

• ip — Kun IPv4-trafik
• ip6 — Kun IPv6-trafik
• inet — Både IPv4 og IPv6 (den mest brugte til servere)
• arp — ARP-pakker
• bridge — Bridge-pakker
• netdev — Pakker direkte på netværksenheden (tidlig filtrering)

I næsten alle serverscenarier vil du bruge inet-familien. Den håndterer begge IP-versioner med ét regelsæt, og det er bare nemmere at vedligeholde.

Tabeller

En tabel er en beholder for kæder. Du navngiver den selv og vælger dens familie. Ingen faste tabeller — du opretter præcis det du har brug for.

# Opret en tabel i inet-familien
nft add table inet min_firewall

Kæder (Chains)

Kæder indeholder regler. Der er to typer: base chains (tilknyttet en Netfilter-hook) og regular chains (brugt som jump-mål). En base chain kræver tre parametre: type, hook og prioritet.

# Opret en base chain tilknyttet input-hooket
nft add chain inet min_firewall input \
  '{ type filter hook input priority filter \; policy drop \; }'

De vigtigste hooks er: prerouting, input, forward, output og postrouting. Prioriteten bestemmer rækkefølgen — lavere tal kører først. En drop-dom er altid endelig, mens en accept-dom lader pakken fortsætte til næste kæde med samme hook (hvis der er en).

Regler

Regler består af udtryk (expressions) der matcher pakker, efterfulgt af udsagn (statements) der bestemmer handlingen. Alle udtryk evalueres fra venstre mod højre — og samtlige skal matche før handlingen udføres.

# Tillad SSH-trafik
nft add rule inet min_firewall input tcp dport 22 accept

# Tillad etablerede/relaterede forbindelser
nft add rule inet min_firewall input ct state established,related accept

Komplet hærdet serverkonfiguration

Nu kommer vi til det sjove. Her er en produktionsklar nftables-konfiguration for en typisk Linux-server. Den implementerer default-deny-politik, tillader kun nødvendig trafik, og inkluderer rate limiting og logning. Gem den som /etc/nftables.conf.

#!/usr/sbin/nft -f

# Ryd alle eksisterende regler atomisk
flush ruleset

# Definer variabler for nemmere vedligeholdelse
define SSH_PORT = 22
define WEB_PORTS = { 80, 443 }
define TRUSTED_SSH = { 10.0.0.0/8, 192.168.0.0/16 }

table inet firewall {

    # Dynamisk set til SSH rate limiting
    set ssh_ratelimit {
        type ipv4_addr
        flags dynamic, timeout
        timeout 5m
    }

    # Set til blokerede IP-adresser
    set blocklist {
        type ipv4_addr
        flags dynamic, timeout
        timeout 1h
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # Tillad loopback — altid
        iifname "lo" accept

        # Drop trafik fra blokerede adresser tidligt
        ip saddr @blocklist counter drop

        # Tillad etablerede og relaterede forbindelser
        ct state established,related accept

        # Drop ugyldige forbindelser
        ct state invalid counter drop

        # ICMP: Tillad ping med rate limiting
        ip protocol icmp icmp type echo-request \
            limit rate 5/second burst 10 packets accept
        ip6 nexthdr icmpv6 icmpv6 type echo-request \
            limit rate 5/second burst 10 packets accept

        # ICMPv6: Tillad nødvendige typer for IPv6
        ip6 nexthdr icmpv6 icmpv6 type {
            nd-neighbor-solicit,
            nd-neighbor-advert,
            nd-router-solicit,
            nd-router-advert
        } accept

        # SSH: Rate limiting per kilde-IP
        tcp dport $SSH_PORT ct state new \
            update @ssh_ratelimit { ip saddr limit rate 4/minute } accept

        # SSH: Bloker overtrædere automatisk
        tcp dport $SSH_PORT ct state new \
            add @blocklist { ip saddr } \
            counter drop

        # Web: Tillad HTTP og HTTPS
        tcp dport $WEB_PORTS accept

        # Log alt der droppes (rate limited for at undgå log-flooding)
        limit rate 5/minute burst 10 packets \
            log prefix "[nftables-drop] " level info counter drop

        # Stille drop af alt andet
        counter drop
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;

        # Tillad loopback
        oifname "lo" accept

        # Tillad etablerede forbindelser
        ct state established,related accept
    }
}

Aktivering og vedligeholdelse

# Valider konfigurationen uden at anvende den
nft -c -f /etc/nftables.conf

# Indlæs konfigurationen
sudo nft -f /etc/nftables.conf

# Aktiver nftables ved opstart
sudo systemctl enable nftables.service
sudo systemctl start nftables.service

# Verificer det aktive regelsæt
nft list ruleset

# Se regelsæt med handles (nødvendigt for at tilføje/fjerne specifikke regler)
nft -a list ruleset

Vigtigt: Test altid firewall-ændringer med konsoladgang tilgængelig — f.eks. via IPMI, KVM eller cloud-konsol. Jeg har selv oplevet at låse mig ude af en server via SSH, og det er ikke sjovt. Hav altid en alternativ vej ind.

Migration fra iptables til nftables

Har du eksisterende iptables-regler? Så behøver du heldigvis ikke starte fra bunden. nftables inkluderer oversættelsesværktøjer der kan konvertere dine regler automatisk.

Trin 1: Gem eksisterende iptables-regler

# Gem nuværende iptables-regler
sudo iptables-save > /tmp/iptables-regler-backup.txt

# Gem også ip6tables hvis du bruger IPv6
sudo ip6tables-save > /tmp/ip6tables-regler-backup.txt

Trin 2: Oversæt til nftables-syntaks

# Oversæt hele regelsættet
sudo iptables-restore-translate -f /tmp/iptables-regler-backup.txt \
    > /tmp/nftables-oversat.nft

# Eller oversæt en enkelt regel
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Output: nft add rule ip filter INPUT tcp dport 22 counter accept

# Eksempler på typiske oversættelser:
# iptables: -A INPUT -s 10.0.0.0/8 -p tcp --dport 3306 -j ACCEPT
# nftables: ip saddr 10.0.0.0/8 tcp dport 3306 accept

# iptables: -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
# nftables: tcp dport 80 ct state new accept

Trin 3: Gennemgå og optimer

De automatisk oversatte regler virker, men de er sjældent optimale. Tag dig tid til at gennemgå dem og udnyt nftables' egne funktioner:

# iptables: Tre separate regler
# -A INPUT -p tcp --dport 22 -j ACCEPT
# -A INPUT -p tcp --dport 80 -j ACCEPT
# -A INPUT -p tcp --dport 443 -j ACCEPT

# nftables: Én regel med anonymous set
tcp dport { 22, 80, 443 } accept

# iptables: Separate regler for IPv4 og IPv6
# iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT
# ip6tables -A INPUT -s fd00::/8 -j ACCEPT

# nftables: Samlet med inet-familien
# Håndteres begge i samme tabel/kæde

Trin 4: Test og udrul

# Valider den oversatte konfiguration
nft -c -f /tmp/nftables-oversat.nft

# Anvend det nye regelsæt
sudo nft -f /tmp/nftables-oversat.nft

# Verificer at alt fungerer
nft list ruleset

# Når alt virker — deaktiver det gamle iptables
sudo systemctl disable iptables.service 2>/dev/null
sudo systemctl stop iptables.service 2>/dev/null

# Gem de nye regler permanent
sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables.service

Avancerede funktioner: Sets, maps og verdict maps

Her bliver nftables for alvor interessant — og det er også her, man virkelig kan mærke forskellen fra iptables. De avancerede datastrukturer åbner muligheder, som iptables simpelthen ikke kan matche.

Named sets

Named sets kan refereres af flere regler og opdateres dynamisk, helt uden at du behøver røre selve reglerne. Det er fantastisk til vedligeholdelse.

# Opret et named set til tilladte SSH-kilder
nft add set inet firewall allowed_ssh { type ipv4_addr \; }

# Tilføj elementer
nft add element inet firewall allowed_ssh { 10.0.0.5, 10.0.0.10, 192.168.1.0/24 }

# Brug settet i en regel
nft add rule inet firewall input ip saddr @allowed_ssh tcp dport 22 accept

# Opdater settet uden at ændre regler
nft add element inet firewall allowed_ssh { 172.16.0.50 }
nft delete element inet firewall allowed_ssh { 10.0.0.10 }

Dynamiske sets med timeout

Dynamiske sets kan automatisk tilføje og fjerne elementer baseret på trafikmønstre. Det er fundamentet for automatisk brute force-beskyttelse — og det hele sker direkte i kernen, uden eksterne værktøjer.

table inet firewall {
    # Dynamisk blockliste — elementer udløber efter 30 minutter
    set auto_blocklist {
        type ipv4_addr
        flags dynamic, timeout
        timeout 30m
    }

    # Rate limiting set
    set ssh_meter {
        type ipv4_addr
        flags dynamic, timeout
        timeout 2m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # Drop blokerede IP-adresser først
        ip saddr @auto_blocklist drop

        # SSH: Tillad max 3 nye forbindelser per minut per IP
        tcp dport 22 ct state new \
            update @ssh_meter { ip saddr limit rate 3/minute } accept

        # Overtrædere tilføjes automatisk til blocklisten
        tcp dport 22 ct state new \
            add @auto_blocklist { ip saddr } \
            log prefix "[SSH-BLOCKED] " drop
    }
}

Verdict maps (vmaps)

Verdict maps kortlægger nøgler direkte til handlinger — accept, drop eller jump til en specifik kæde. Tænk på det som en switch-statement for netværkstrafik.

# Opret en verdict map der router trafik baseret på destination port
nft add map inet firewall port_policy \
    { type inet_service : verdict \; }

# Definer politikker per port
nft add element inet firewall port_policy {
    22 : jump ssh_chain,
    80 : accept,
    443 : accept,
    3306 : drop
}

# Brug mappen i en regel
nft add rule inet firewall input tcp dport vmap @port_policy

# Verdict map baseret på kilde-IP
nft add map inet firewall ip_policy \
    { type ipv4_addr : verdict \; }

nft add element inet firewall ip_policy {
    10.0.0.1 : accept,
    192.168.1.100 : drop,
    172.16.0.0/12 : jump internal_chain
}

Sammenkædninger (Concatenations)

Sammenkædninger gør det muligt at matche flere felter samtidig i ét opslag. Du kan f.eks. bruge kilde-IP og destinationsport som en samlet nøgle — det er både elegant og hurtigt.

# Set med sammenkædet nøgle: IP + port
nft add set inet firewall service_access {
    type ipv4_addr . inet_service
    elements = {
        10.0.0.5 . 3306,
        10.0.0.10 . 5432,
        192.168.1.0/24 . 22
    }
}

# Brug i en regel
nft add rule inet firewall input \
    ip saddr . tcp dport @service_access accept

Fail2Ban-integration med nftables

Selvom nftables selv kan håndtere rate limiting og dynamiske blocklister, er Fail2Ban stadig relevant i 2026. Fail2Ban overvåger logfiler og reagerer på specifikke mønstre — mislykkede login-forsøg, web-applikationsangreb og meget mere. Det komplementerer nftables ved at tilføje et forsvar på applikationsniveau, som nftables alene ikke kan dække.

Trin 1: Opret en nftables-tabel til Fail2Ban

Opret filen /etc/nftables/fail2ban.conf:

#!/usr/sbin/nft -f
table ip fail2ban {
    chain input {
        type filter hook input priority filter - 1; policy accept;
    }
}

Prioriteten filter - 1 sikrer at Fail2Ban-reglerne evalueres før de almindelige firewall-regler. Det er vigtigt — ellers risikerer du at blokeringerne aldrig træder i kraft. Inkluder filen i din hoved-konfiguration:

# I /etc/nftables.conf — tilføj efter flush ruleset:
include "/etc/nftables/fail2ban.conf"

Trin 2: Konfigurer Fail2Ban til nftables

Opret eller rediger /etc/fail2ban/jail.local:

[DEFAULT]
# Brug nftables som ban-mekanisme
banaction = nftables-multiport
banaction_allports = nftables-allports
chain = input

# Generelle indstillinger
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = systemd
maxretry = 3
bantime = 2h

# Recidive: Straf gentagelsesforbrydere hårdere
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = nftables-allports
bantime = 1w
findtime = 1d
maxretry = 3

Trin 3: Konfigurer nftables-action

Opret /etc/fail2ban/action.d/nftables-common.local:

[Init]
nftables_family = ip
nftables_table  = fail2ban
blocktype       = drop
nftables_set_prefix =

Trin 4: Bind Fail2Ban til nftables via systemd

Opret /etc/systemd/system/fail2ban.service.d/override.conf for at sikre at Fail2Ban starter (og genstarter) sammen med nftables:

[Unit]
Requires=nftables.service
PartOf=nftables.service

[Install]
WantedBy=multi-user.target nftables.service

# Genindlæs systemd og genstart tjenesterne
sudo systemctl daemon-reload
sudo systemctl restart nftables.service
sudo systemctl restart fail2ban.service

# Verificer at Fail2Ban bruger nftables
sudo fail2ban-client status sshd
sudo nft list table ip fail2ban

Geo-blocking med nftables

Geo-blocking gør det muligt at blokere eller tillade trafik baseret på geografisk oprindelse. Hvis din server kun skal betjene trafik fra bestemte regioner (f.eks. kun Norden eller EU), kan det reducere angrebsfladen markant.

Brug af nft-geo-filter

Værktøjet nft-geo-filter downloader landespecifikke IP-blokke og opretter nftables-sets automatisk. Det er den nemmeste måde at komme i gang med geo-blocking.

# Installer nft-geo-filter
git clone https://github.com/rpthms/nft-geo-filter.git
cd nft-geo-filter

# Bloker trafik fra specifikke lande (brug ISO 3166-1 alpha-2 koder)
# Eksempel: Bloker trafik fra CN og RU på interface eth0
sudo ./nft-geo-filter \
    --table-family netdev \
    --interface eth0 \
    CN RU

# Tillad undtagelser for specifikke IP-adresser
sudo ./nft-geo-filter \
    --table-family netdev \
    --interface eth0 \
    --exceptions "203.0.113.50,198.51.100.100" \
    CN RU

Manuel geo-blocking med named sets

Vil du have fuld kontrol? Så kan du oprette dine egne geo-sets manuelt:

# Definer et set med IP-ranges fra en specifik region
table inet firewall {
    set geo_blocked {
        type ipv4_addr
        flags interval
        # Tilføj IP-ranges hentet fra en geo-IP-database
        elements = {
            1.0.1.0/24,
            1.0.2.0/23,
            # ... flere ranges
        }
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # Drop geo-blokerede adresser tidligt i kæden
        ip saddr @geo_blocked counter drop

        # ... resten af dine regler
    }
}

# Opdater geo-sets med et script (kør via cron)
# Download fresh IP-lister fra f.eks. ipdeny.com eller db-ip.com
# og opdater settet med:
# nft flush set inet firewall geo_blocked
# nft add element inet firewall geo_blocked { ... }

Da nft-geo-filter opretter en separat nftables-tabel, vil det ikke forstyrre din eksisterende firewall-konfiguration. En ret elegant løsning til at tilføje geo-baseret filtrering uden at rode i dine hovedregler.

Logning og overvågning

En firewall uden logning er som et alarm-system uden sirene. Du skal vide hvad der foregår for at kunne reagere.

Struktureret logning

chain input {
    type filter hook input priority filter; policy drop;

    # ... accept-regler ...

    # Log droppede TCP-pakker med specifikt præfiks
    ip protocol tcp counter log prefix "[TCP-DROP] " level info
    ip protocol udp counter log prefix "[UDP-DROP] " level info

    # Rate limit logningen for at undgå disk-flooding
    # (bedre version)
    limit rate 10/minute burst 20 packets \
        log prefix "[FW-DROP] " level info counter

    counter drop
}

Overvågning med nft-kommandoer

# Se alle regler med tællere (live-data)
nft list ruleset

# Overvåg specifik tabel
nft list table inet firewall

# Se indhold af dynamiske sets (blokerede IP-er)
nft list set inet firewall auto_blocklist

# Nulstil tællere
nft reset counters table inet firewall

# Realtidsovervågning med nft monitor
nft monitor

# Se nftables trace for debugging
nft add rule inet firewall input meta nftrace set 1
nft monitor trace

Integration med journald og rsyslog

nftables-logmeddelelser sendes til kernens log-facilitet og dukker op i /var/log/kern.log eller via journalctl. Vil du have dem i en separat logfil (og det vil du nok), gør sådan her:

# Opret /etc/rsyslog.d/nftables.conf:
:msg, contains, "[nftables-" /var/log/nftables.log
& stop

# Genstart rsyslog
sudo systemctl restart rsyslog

# Overvåg logfilen
tail -f /var/log/nftables.log

Bedste praksis og sikkerhedstjekliste

Uanset om du migrerer fra iptables eller starter fra bunden — principperne er de samme. Her er de vigtigste ting at huske:

• Default deny altid: Start med policy drop på input og forward. Tillad kun eksplicit det, der er nødvendigt. Ingen undtagelser.
• Tillad etablerede forbindelser tidligt: Reglen ct state established,related accept bør være en af de første i din input-kæde. Det sikrer at svar på udgående forbindelser altid kommer igennem, og reducerer belastningen da de fleste pakker matcher netop denne regel.
• Drop invalid state: Pakker med ct state invalid bør altid droppes. De er ofte tegn på scanning eller angrebsforsøg.
• Rate limit alt der kan udnyttes: SSH, ICMP og alle tjenester der modtager direkte brugerinput bør have rate limiting. Det koster næsten ingenting i ydeevne, men gør en stor forskel for sikkerheden.
• Brug sets til dynamisk indhold: IP-lister, port-grupper og blocklister bør være i sets, ikke hardcodet i regler. Det gør vedligeholdelse og automatisering langt nemmere.
• Test med nft -c: Valider altid konfigurationen med nft -c -f /etc/nftables.conf før du anvender den. Det fanger syntaksfejl uden at ændre det aktive regelsæt.
• Behold konsoladgang: Hav altid en alternativ adgangsvej (IPMI, cloud-konsol, seriel konsol) når du arbejder med firewall-regler. Én fejl kan låse dig ude — og så hjælper det ikke at have den perfekte konfiguration klar på din lokale maskine.
• Versionskontrol: Gem din /etc/nftables.conf i git. Det giver historik over ændringer og mulighed for at rulle tilbage.
• Regelmæssig gennemgang: Gennemgå dine firewall-regler mindst én gang i kvartalet. Fjern regler der ikke længere er nødvendige, og verificer at alt stadig matcher dine aktuelle behov.

Ofte stillede spørgsmål

Kan jeg køre iptables og nftables samtidig?

Teknisk set ja, men lad være. På moderne distributioner er iptables-kommandoen faktisk iptables-nft, der oversætter til nftables bag kulisserne. At blande direkte nftables-regler med iptables-nft-regler kan skabe uforudsigelige interaktioner. Den anbefalede tilgang er at migrere fuldt til nftables og bruge oversættelsesværktøjerne til at konvertere eksisterende regler.

Erstatter nftables Fail2Ban?

Ikke helt. nftables kan håndtere rate limiting og dynamiske blocklister direkte, hvilket dækker en del af Fail2Bans funktionalitet. Men Fail2Ban tilbyder mere: det analyserer applikationslogfiler (SSH, Apache, Nginx, Postfix osv.) og reagerer på specifikke mønstre — ikke bare forbindelseshastigheder. Den bedste strategi er at bruge begge: nftables som det primære forsvar og Fail2Ban som supplerende applikationsniveau-forsvar.

Hvordan nulstiller jeg nftables til en ren tilstand?

Brug kommandoen nft flush ruleset for at fjerne alle tabeller, kæder og regler. Men vær opmærksom på at dette også fjerner eventuelle Fail2Ban-tabeller (og Docker-tabeller, hvis du bruger Docker). Efter en flush bør du genindlæse din konfiguration med nft -f /etc/nftables.conf og genstarte Fail2Ban.

Påvirker nftables serverens ydeevne?

Kort svar: nej, ikke mærkbart. Med hash-baserede sets og verdict maps opnår du O(1) opslag, selv med tusindvis af IP-adresser. For langt de fleste servere er firewall-overhead umåleligt sammenlignet med den samlede netværksprocessering. nftables performer faktisk bedre end iptables, især med store regelsæt, takket være de optimerede datastrukturer.

Hvordan håndterer jeg Docker og nftables?

Docker opretter sine egne nftables-regler til container-netværk og NAT. Det vigtige at vide er, at nft flush ruleset også fjerner Dockers regler — og det kan give uventede problemer. Den sikreste tilgang er at definere dine egne regler i separate tabeller, og aldrig bruge flush ruleset i produktion med Docker. Brug i stedet nft flush table inet min_firewall for kun at rydde dine egne regler.