Ubuntu iptables ve nftables farkı nedir?

Ubuntu üzerinde iptables ve nftables: sunucunuz hangisini kullanıyor?

Ubuntu 20.04 ve sonraki sürümlerde iptables komutu, nftables kurallarını yazan bir arayüzdür. Çekirdek içerisinde tek bir paket filtreleyici (nftables) çalışır ve iki kullanıcı alanı komutu bunu programlar. Bir iptables -A INPUT satırı, tıpkı eskiden olduğu gibi çalışmaya devam eder ve oluşturduğu kural, nft ile görüntülenebilen bir nftables kuralıdır.

Buna inanmadan önce kendi sunucunuzda doğrulayın.

iptables -V
sudo update-alternatives --display iptables
sudo nft list ruleset

Ubuntu 24.04 üzerinde (Ağustos 2026 itibarıyla iptables 1.8.10), iptables -V komutu iptables v1.8.10 (nf_tables) çıktısını verir. Köşeli parantez içindeki isim arka uç (back end) bilgisidir. (nf_tables), komutun nftables ile konuştuğu anlamına gelir. (legacy) ise Ubuntu'nun hala iptables-legacy olarak sunduğu ve çekirdeğin tamamen ayrı bir kural kümesi olarak tuttuğu eski x_tables arka ucunu ifade eder. update-alternatives, bu seçimin arkasındaki sembolik bağı görüntüler: link currently points to /usr/sbin/iptables-nft.

Henüz bir güvenlik duvarı yapılandırılmamış yeni bir VPS üzerinde sudo nft list ruleset hiçbir çıktı vermez. Bu boş çıktı sizin temel referans noktanızdır. Eski yöntemle bir kural ekleyin ve tekrar kontrol edin.

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo nft list ruleset

# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
  chain INPUT {
    type filter hook input priority filter; policy accept;
    tcp dport 22 counter packets 0 bytes 0 accept
  }
  chain FORWARD {
    type filter hook forward priority filter; policy accept;
  }
  chain OUTPUT {
    type filter hook output priority filter; policy accept;
  }
}

iptables kuralınız aslında bir nftables kuralıdır. iptables-nft, oluşturduğu tabloları işaretler ve nft, bu işareti gördüğünde uyarı verir; çünkü böyle bir tabloyu nft ile düzenlemek, aynı kurallar üzerinde iki farklı aracın yetkili olmasına neden olur. Tek bir komutun ne ürettiğine bakın: sizin isimlendirmediğiniz bir tablo ve talep etmediğiniz zincirler. Bu eski modeldir ve doğrudan nftables yazdığınızda değişen ilk şey budur.

iptables -L komutunun sizden gizledikleri

iptables -L yalnızca filter tablosunu gösterir. NAT (ağ adresi çevirisi) kuralları için iptables -t nat -L, mangle kuralları için ise -t mangle gereklidir. IPv6, her kuralın kendi kopyasını içeren ayrı bir komut olan ip6tables altında çalışır. Bu nedenle, bir sunucu tek bir listelemede temiz görünebilir; ancak kontrol etmediğiniz bir tablodan gelen kurallar paketlerinizi düşürüyor veya yeniden yazıyor olabilir.

sudo nft list ruleset komutu; her aileyi, her tabloyu, her zinciri ve her kuralı tek bir çıktıda yazdırır. Kendi kurmadığınız bir sunucuda, sistemde nelerin yüklü olduğunu görmenin en hızlı yolu bu komuttur. Bir zincirin tamamını silmek yerine tek bir kuralı silmek için ihtiyaç duyacağınız kural tanıtıcılarını (handles) yazdırmak için -a bayrağını ekleyin.

Buradayken iki alışkanlığı düzeltmekte fayda var. iptables -L, adresleri ve portları isimlere çözümlemeye çalışır; bu nedenle DNS çözümleyicisi bozuk bir sunucuda komut donmuş gibi görünebilir: bunun yerine iptables -nvL kullanın. Ayrıca, eski arka ucun (legacy back end) boş olduğunu sudo iptables-legacy -nvL ile doğrulayın. Eğer her iki arka uçta da kurallar mevcutsa, çekirdek her ikisini de değerlendirir ve hiçbir liste size resmin tamamını göstermez.

Devralınmayan, sizin oluşturduğunuz tablolar ve zincirler

nftables hiçbir şey olmadan başlar. Siz bir tane oluşturana kadar filter tablosu mevcut değildir ve filter kelimesi sadece sizin seçtiğiniz bir isimdir. Bir zincir, ancak ona bir tür, bir kanca (hook) ve bir öncelik (priority) atadığınızda paketleri görür; bu da onu bir temel zincir (base chain) yapar. Bunlara sahip olmayan bir zincire yalnızca açık bir jump veya goto ile ulaşılır, bu nedenle başka bir zincirden atlama yapılmadığı sürece hiçbir maliyeti yoktur.

Diğer büyük değişiklik inet ailesidir. Tek bir inet tablosu, IPv4 ve IPv6 trafiğini aynı kurallar içinde yönetir; bu da bir portun iptables içinde kapalıyken ip6tables içinde tamamen açık kalması gibi bir hata sınıfını ortadan kaldırır. Bu uyumsuzluk, ufw yüklü sistemlerde kendi hata moduna sahip olacak kadar yaygındır.

Aşağıda eksiksiz bir sunucu kural seti bulunmaktadır. Bu dosya /etc/nftables.conf içine yerleştirilmelidir.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set admin_ips {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.5, 198.51.100.0/24 }
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif lo accept
    ip protocol icmp accept
    meta l4proto ipv6-icmp accept
    tcp dport 22 ip saddr @admin_ips counter accept
    tcp dport { 80, 443 } counter accept
  }

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

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

1. satırı iki kez okuyun. flush ruleset, ufw ve Docker'ın kendileri için oluşturduğu tablolar da dahil olmak üzere sunucudaki her tabloyu siler. Bunu canlı bir sunucuda çalıştırmadan önce okumaya devam edin.

input zincirindeki ilk kural işin büyük kısmını yapar. ct state established,related accept, başlattığınız bağlantılara gelen yanıtların içeri girmesine izin verir, böylece zincirin geri kalanı yalnızca yeni bağlantılar hakkında karar vermek zorunda kalır. ct state invalid drop, bilinen hiçbir bağlantıyla eşleşmeyen ve geçerli bir başlangıcı olmayan paketleri atar. Bundan sonraki her şey açık bir deliktir ve policy drop geri kalanını yönetir.

Dosyayı yüklemeden önce kontrol edin ve bu işlemi yaparken ikinci bir SSH oturumunu açık tutun. policy drop ve SSH kuralındaki tek bir yazım hatası, sizi kendi sunucunuzdan dışarıda bırakır.

sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

nft -c -f, dosyayı ayrıştırır ve hiçbir şeyi yüklemeden hataları bildirir. Sorunsuz bir ayrıştırma işlemi hiçbir çıktı üretmez.

Kümeler uzun kural listelerinin yerini alır

tcp dport { 80, 443 } anonim bir kümedir: her port için bir kural yerine tek bir kural ve tek bir arama işlemi gerçekleştirir. admin_ips gibi adlandırılmış bir küme ise daha ileri gider; çünkü güvenlik duvarı çalışırken bu kümeyi değiştirebilirsiniz.

sudo nft add element inet filter admin_ips { 203.0.113.9 }
sudo nft list set inet filter admin_ips
sudo nft delete element inet filter admin_ips { 203.0.113.9 }

Yeniden yükleme veya kural numaralandırma gerekmez; küme ister beş ister elli bin adres içersin, eşleşme tek bir arama olarak kalır. flags interval, bir kümenin 198.51.100.0/24 gibi aralıkları ve CIDR (sınıfsız etki alanları arası yönlendirme) öneklerini tutmasını sağlayan bayraktır. Bu bayrak olmadan küme yalnızca tekil adresleri kabul eder ve önek yükleme işlemi başarısız olur.

Kümeler kendi öğelerinin süresini de dolmaya bırakabilir.

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

ip saddr @banned drop kuralı ile her öğe, eklendikten bir saat sonra kendiliğinden silinir. Ubuntu 24.04 üzerinde fail2ban içindeki nftables eylemi bir adresi bu şekilde yasaklar: kural eklemek yerine kümeye bir öğe ekler. Portlar sizin için yeni bir konuysa, Linux'ta portun gerçekte ne olduğu ile başlayın.

Geçiş sırasında kullanıcıların karşılaştığı bir fark mevcuttur. nftables, siz istemediğiniz sürece paketleri saymaz. iptables -nvL her kural için her zaman sayaçları gösterir. nftables içinde ise yalnızca counter anahtar kelimesini taşıyan kurallar sayısal değerlere sahiptir; bu nedenle daha sonra hata ayıklamayı düşündüğünüz her kurala counter ifadesini ekleyin.

Kancalar ve öncelikler sıralamayı nasıl belirler

Bir temel zincir (base chain), paketin yolculuğu sırasında çalıştığı noktayı belirten bir kanca (hook) tanımlar. prerouting, yönlendirme kararından önce çalışır. input, bu makineye gönderilen paketler için çalışır. forward, üzerinden yönlendirilen paketler için çalışır. output, yerel süreçlerden gelen paketler için çalışır. postrouting, paket çıkış yapmadan hemen önce, en son çalışır.

Öncelik (priority), aynı kanca içindeki zincirlerin sırasını belirler; en küçük sayıya sahip olan önce çalışır. nftables, klasik değerlere isimler atar: raw -300, mangle -150, dstnat -100, filter 0, srcnat ise 100 değerindedir. priority filter; yazmak, priority 0; yazmakla aynıdır.

Şimdi araçların bir arada çalışıp çalışmayacağını belirleyen kısma gelelim. Bir kanca üzerinde kayıtlı olan her temel zincir, öncelik sırasına göre çalışır. Zincirinizde kabul edilen (accept) bir paket henüz işlemden çıkmış sayılmaz: accept yalnızca o zinciri sonlandırır ve paket, aynı kanca üzerindeki bir sonraki temel zincire doğru ilerlemeye devam eder. drop ise her yerde nihaidir ve paketi anında durdurur. Dolayısıyla, tablonuzdaki izin verici bir kural, ufw tablosundaki bir engellemeyi (drop) geçersiz kılamaz; hangisinin önce çalıştığının bir önemi yoktur ve accept, daha sonra çalışan bir zincire karşı size herhangi bir koruma sağlamaz.

Aynı kanca üzerinde aynı önceliğe sahip iki temel zincir, kayıt sırasına göre çalışır; bu da hangi servisin önce başladığına bağlıdır. Bu sıra, yeniden başlatma sonrasında değişebilir. Kendi tablonuzu ufw ile yan yana çalıştırmanız gerekiyorsa, ona farklı bir öncelik değeri atayın; böylece sıra bir yarışa bırakılmak yerine net bir şekilde tanımlanmış olur.

Neden yazılacak bir ters NAT kuralı yoktur?

İnsanların en sık yanlış anladığı konu budur, bu yüzden doğrudan yanıtı aşağıdadır. Bağlantı takibi (connection tracking), ters çeviri işlemini sizin yerinize gerçekleştirir. Eklenmesi gereken ikinci bir kural yoktur.

Tipik bir VPS işinin her iki yarısını da yapan bir nat tablosu şu şekilde görünür:

table inet nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "enp1s0" tcp dport 8080 dnat ip to 10.0.0.5:80
  }

  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.0.0.0/24 oifname "enp1s0" masquerade
  }
}

Bir bağlantının yalnızca ilk paketi nat zincirine karşı değerlendirilir. Bir kural eşleştiğinde, çekirdek bu çeviri bilgisini bağlantı kaydıyla birlikte bağlantı takip tablosunda saklar. Sonraki her paket, her iki yönde de, saklanan bu kayıttan yeniden yazılır ve hiçbir kural tekrar okunmaz. conntrack aracını kurun ve canlı bir kaydı inceleyin.

sudo apt install -y conntrack
sudo conntrack -L -p tcp

tcp 6 431999 ESTABLISHED src=198.51.100.20 dst=203.0.113.10 sport=54321 dport=8080 src=10.0.0.5 dst=198.51.100.20 sport=80 dport=54321 [ASSURED] mark=0 use=1

Bunu iki demet (tuple) olarak okuyun. İlk dört alan, istemcinin gönderdiği haliyle, genel adresiniz olan 203.0.113.10:8080 adresine yönlendirilmiş bağlantıdır. İkinci dört alan ise çekirdeğin beklediği, halihazırda tersine çevrilmiş ve çevirisi yapılmış, gerçek arka uç olan 10.0.0.5:80 adresinden gelen yanıttır. Bu ikinci demet, doğrudan ters kuralın kendisidir. Çekirdek, ilk paket eşleştiğinde bunu yazmıştır.

Bu nedenle dönüş yönü için bir kural yazmayın. Bu kural eşleşemez; çünkü dönüş paketleri kurulmuş bir bağlantıya aittir ve asla bir nat zincirine ulaşmazlar. Eğer bir şekilde eşleşseydi, çekirdeğin zaten düzelttiği bir paketi tekrar çevirmiş olurdunuz.

Bir yeniden yazma işleminin nerede yer alması gerektiği aynı mekanizmadan kaynaklanır. Hedef çevirisi, yönlendirme kararından önce prerouting içinde çalışmalıdır; çünkü yönlendirme mekanizması yeni hedefi görmelidir, aksi takdirde paket yanlış yere gider. Sunucunun kendi oluşturduğu trafik de aynı nedenle output kancasında işlenir. Kaynak çevirisi (kaynak portunun yeniden yazılması dahil), yönlendirme çıkış arayüzünü seçtikten sonra postrouting içinde çalışmalıdır. masquerade adresini bu arayüzden alır ve yönlendirme çalışana kadar arayüz bilinmez.

İşte bu yüzden bunun gibi bir kural, yolun sonunda yer alır ve başka hiçbir yerde bulunmaz.

ip saddr 10.0.0.0/24 oifname "enp1s0" snat ip to 203.0.113.10:20000-30000

Port aralığı, kaynak adresiyle birlikte kaynak portunu da yeniden yazar; birçok iç istemci tek bir genel adresi paylaştığında ve kaynak portları çakıştığında istediğiniz durum budur. Bu aralıktaki bir porta yönlendirilmiş bir yanıt geldiğinde, conntrack bunu ilgili kayıtla eşleştirir ve paket teslim edilmeden önce orijinal kaynak portu geri yüklenir. Tekrar belirtmek gerekirse, ikinci bir kurala gerek yoktur.

Pratik bir sonuç olarak: Bir NAT kuralını değiştirmek, halihazırda var olan bağlantıları etkilemez; çünkü çeviri bilgileri çoktan saklanmıştır. Bağlantılar, kayıtlarının süresi dolana kadar eski davranışı sürdürürler. sudo conntrack -D -p tcp --dport 8080 eşleşen kayıtları siler, sudo conntrack -F ise hepsini siler. İkinci komutu bir NAT sunucusunda kullanırken dikkatli olun; çünkü saklanan bu çeviri bilgileri mevcut bağlantıları ayakta tutan şeydir, bu yüzden onları temizlemek sunucu üzerinden geçen tüm bağlantıları anında koparır.

ufw ve Docker kendi kurallarını ayrı ayrı yazar

ufw, Ubuntu üzerinde nftables için bir arayüz görevi gören iptables için bir ön uçtur. Bu nedenle bir ufw sunucusu, ufw-before-input, ufw-user-input gibi zincirlerle dolu bir ip filter tablosuna ve aynı yapının bir ip6 filter kopyasına sahiptir. sudo nft list ruleset | grep ufw ile bu tabloyu inceleyebilirsiniz. Söz konusu zincirler /etc/ufw içindeki dosyalardan oluşturulur ve ufw reload bunları her seferinde sıfırdan yeniden yazar; bu yüzden elle eklenen bir iptables kuralı, bir sonraki yeniden yüklemede silinir. VPS için ufw temelleri bu dosya yapısını açıklamaktadır.

Docker, güvenlik duvarını kendi programlar ve ufw'ye danışmaz. -p 80:80 ile bir portu dışarıya açmak, nat tablosuna bir DNAT kuralı ve yönlendirme yoluna bir kabul (accept) kuralı yazar; her ikisi de ufw'nin kullanıcı zincirlerinden önce çalışır. Sonuç herkesi bir kez şaşırtır: ufw deny 80 yüklü olsa bile container internetten erişilebilir durumdadır. Çözüm, Docker'ın sizin kurallarınız için bıraktığı DOCKER-USER zincirindedir ve Docker container'ları neden ufw'yi görmezden gelir başlıklı yazı bu konuyu detaylandırır. Sunucunuzda nelerin yüklü olduğunu sudo nft list ruleset | grep -i docker ile görebilirsiniz.

Şimdi yukarıdaki yapılandırmada yer alan flush ruleset satırını tekrar okuyun. Bu satır, bu iki aracın yönettiği tablolar da dahil olmak üzere her tabloyu siler. Bir Docker sunucusunda, sudo systemctl restart docker zincirleri yeniden oluşturana kadar dışarıya açılan portlar çalışmayı durdurur. Bu tek satır, insanların güvenlik duvarını düzenlerken kendi servislerini çevrimdışı bırakmalarının en yaygın yoludur.

Yeniden başlatma sonrasında geçerliliğini koruyan kurallar

Her iki kural kümesi de kendi başına kalıcı değildir. Çekirdek, sistem kapatıldığında her şeyi unutur; bu durum her iki taraf için de ayrı bir paketle çözülür.

nftables için /etc/nftables.conf dosyası nftables.service tarafından okunur. Ubuntu bu servisi devre dışı bırakılmış şekilde sunar, bu nedenle güvenmeden önce kontrol edin.

systemctl is-enabled nftables
sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables

iptables için ilgili paket iptables-persistent paketidir; bu paket netfilter-persistent aracını kurar ve kuralları /etc/iptables/rules.v4 ile /etc/iptables/rules.v6 dosyalarına kaydeder.

sudo apt install -y iptables-persistent
sudo netfilter-persistent save

Her ikisini birden çalıştırmayın. Güvenlik duvarını tuttuğunu iddia eden iki dosya zamanla birbirinden farklılaşacaktır; son yüklenen dosya, içeriği okuyarak tahmin edilemeyecek bir şekilde baskın gelir.

Canlı bir kural kümesini dışa aktarırken (dump) dikkat edilmesi gereken bir tuzak vardır. sudo nft -s list ruleset > /etc/nftables.conf komutu, ufw tabloları ve Docker tabloları dahil olmak üzere o an yüklü olan her şeyi yakalar. Bunu sistem açılışında geri yüklerseniz, bu araçların kendilerinin oluşturmasını beklediği kuralların donmuş bir kopyasını elde edersiniz; ardından bu araçlar başladığında ikinci bir kopya daha oluşur. Yalnızca kendi tablonuzu sudo nft -s list table inet filter ile dışa aktarın. -s bayrağı, bir yapılandırma dosyasında yeri olmayan sayaçları çıktıdan çıkarır.

VPS üzerinde ufw kullanmalı mısınız?

İhtiyaçlarınızı karşılayamadığı durumlar haricinde ufw ayarlarını değiştirmeyin. ufw, standart bir VPS için gerekenleri karşılar: varsayılan olarak tüm trafiği reddeder ve sadece belirtilen portları açar. Bunu manuel olarak yazılmış bir kural setiyle değiştirmek, size aynı güvenlik duvarını sağlar ancak yönetmeniz gereken ek bir iş yükü getirir.

İhtiyaçlarınız ufw modelinin dışına çıktığında yerel araçlara geçiş yapın: NAT ve port yönlendirme, çalışma zamanında güncellediğiniz setler, her iki adres ailesini de kapsayan tek bir kural veya kendi belirlediğiniz zincir öncelikleri gibi. Bunlar geçerli teknik gerekçelerdir ve ufw ile bu yapılandırmaları gerçekleştirmek mümkün değildir.

Yerel araçlara geçiş yapacaksanız, bunu tamamen yapın. sudo ufw disable ve sudo systemctl disable --now ufw komutlarını çalıştırın, sudo nft list ruleset ile tabloların temizlendiğini doğrulayın ve ardından kendi dosyanızı yükleyin. Hem ufw hem de manuel yazılmış bir tablonun aynı anda çalıştığı bir sunucuda trafik akışı devam eder; ancak geçerli politika, servis başlatılma sırasına göre belirlenen iki farklı kural setinin birleşimidir. Bu durumda, yapılandırma dosyalarını inceleyen hiç kimse sunucunun gerçekte nasıl bir güvenlik politikası uyguladığını anlayamaz.

Mevcut bir iptables kural kümesini taşıma

iptables-translate, tek bir kuralı dönüştürür ve nftables biçiminde yazdırır. Sunucu üzerinde hiçbir şeyi değiştirmez.

iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT

nft add rule ip filter INPUT tcp dport 22 counter accept

iptables-restore-translate -f /etc/iptables/rules.v4, kaydedilmiş tüm bir kural kümesi için aynı işlemi yapar. Çıktısını bir taslak olarak değerlendirin. Dönüştürme işlemi mekanik ve kural bazlıdır; bu nedenle eski tablo ve zincir isimlerini, IPv4 ve IPv6 için iki ayrı kural kümesini geri alırsınız. Geçişi anlamlı kılan setlerin hiçbiri bu işlemle oluşturulmaz. Çıktıyı elle tek bir inet tablosu olarak yeniden yazın ve canlı bir sunucuya uygulamadan önce nft -c -f ile doğrulayın.

Bu örneklerdeki adresler 203.0.113.0/24 ve 198.51.100.0/24 dokümantasyon aralıklarından alınmıştır ve enp1s0 bir arayüz ismidir. Güncel Ubuntu imajları nadiren eth0 ismini kullandığından, kendi değerlerinizi ip route show default ve ip -br addr üzerinden alın; örnekleri doğrudan kopyalamayın.

FAQ

Ubuntu üzerinde iptables kullanımdan kaldırıldı mı?

Komut kaldırılmıyor ve Ubuntu 24.04 üzerinde çalışmaya devam ediyor. Değişen şey arka planda gerçekleşen süreçtir: iptables, iptables-nft arka ucunu kullanarak nftables kuralları yazan bir arayüzdür. 24.04 üzerinde iptables v1.8.10 (nf_tables) çıktısını veren iptables -V komutu ile kendi yapılandırmanızı kontrol edebilirsiniz. Eski x_tables arka ucu, iptables-legacy olarak sunulmaya devam etmektedir ve tamamen ayrı bir kural kümesi tutar; bu nedenle kuralları her iki arka uçta değil, yalnızca birinde tanımlayın.

Geri dönüş yolunda NAT işlemini geri almak için ikinci bir kurala ihtiyacım var mı?

Hayır. Bağlantı takibi (connection tracking), bir bağlantının ilk paketi bir nat kuralıyla eşleştiğinde çeviri bilgisini saklar ve sonraki tüm paketler her iki yönde de bu kayıt üzerinden yeniden yazılır. sudo conntrack -L, bunu bağlantı başına iki demet (tuple) olarak gösterir: orijinal yön ve ardından halihazırda tersine çevrilmiş yanıt. Geri dönüş yönü için yazılan bir kural işe yaramaz, çünkü geri dönen paketler hiçbir zaman bir nat zincirine ulaşmaz.

ufw ile kendi nftables kurallarımı aynı anda çalıştırabilir miyim?

Çalışır ancak bu durum sorunlara davetiye çıkarır. Bir kanca (hook) üzerindeki her temel zincir çalıştırıldığından, aktif politika her iki kural kümesinin birleşimidir; öncelik sırasına göre veya öncelikler eşitse hangi servis önce başladıysa ona göre uygulanır. Her iki taraftaki bir drop kesindir ve sizinkindeki bir accept, diğerinin aynı paketi düşürmesini engellemez. Tek bir araç seçin. Eğer nftables kullanacaksanız, önce ufw servisini devre dışı bırakın ve sudo nft list ruleset üzerinden tablolarının temizlendiğini doğrulayın.

Ubuntu üzerinde nftables kurallarının yeniden başlatma sonrasında kalıcı olmasını nasıl sağlarım?

Kural kümesini /etc/nftables.conf içine yerleştirin, sudo nft -c -f /etc/nftables.conf ile kontrol edin ve ardından sudo systemctl enable --now nftables komutunu çalıştırın. Servis varsayılan olarak etkinleştirilmediğinden, systemctl is-enabled nftables komutunu bir kez çalıştırmak faydalıdır. Bu dosyayı oluştururken yalnızca kendi tablonuzu sudo nft -s list table inet filter ile dışa aktarın; çünkü tam bir list ruleset dökümü, ufw ve Docker'ın kendi yönettiği tabloları da içerir.