Kurumsal Linux altyapılarında firewall katmanı çoğu zaman “dokunma patlar” sınıfına girer. iptables yıllarca iş gördü; ama nftables modern Linux kernel ile daha tutarlı bir model sunuyor: set’ler, counter’lar, daha okunur kural örgüsü ve daha iyi performans/izlenebilirlik.
Sorun şu: iptables → nftables geçişi “komut değişimi” değil; operasyonel risk değişimidir. Bu runbook, geçişi tek seferde değil dalga + kanıt + rollback disiplininde yapmanız için pratik bir yol verir.
0) Hedef net olsun: “nftables kullanmak” ne demek?
Linux dünyasında iki farklı gerçeklik var:
- iptables-nft (compat):
iptableskomutu çalışır ama arka uç nftables’dır. - native nft: kurallar
nftile yönetilir,nft list rulesetkaynak gerçek olur.
Birçok kurum için en gerçekçi geçiş: önce iptables-nft ile arka ucu standardize etmek, sonra native nft’ye geçmek.
1) Envanter: “ne çalışıyor?” sorusuna kanıt üret
Geçişin başarısı, mevcut kuralların “dokümanı” ile değil gerçek trafik kanıtı ile ölçülür.
A) Mevcut kural setini çıkar
sudo iptables-save > /var/tmp/iptables-save.txt
sudo ip6tables-save > /var/tmp/ip6tables-save.txt
B) Kritik zincirleri sınıflandır
- north-south (internet/edge)
- east-west (DC içi)
- yönetim düzlemi (SSH, API, monitoring)
- NAT/masquerade (conntrack maliyeti)
Bu sınıflandırma, dalga rollout sırasında “hangi akışlar riskli?” sorusunu cevaplar.
2) Geçiş ön koşulları (prod checklist)
- Rollback yolu net: “iptables’e geri dönüş” tek komutla mümkün mü?
- Out-of-band erişim var: konsol/iDRAC/iLO/bmc yolu çalışıyor mu?
- DNS/NTP gibi bağımlılıklar doğrulandı mı?
- Monitoring hazır: drop, conntrack, CPU softirq, packet loss
3) Aşama 1 — iptables-nft arka ucuna geçiş (düşük sürtünme)
Dağıtıma göre paket isimleri değişir; ama prensip aynı:
- Alternatifler
iptables-legacyveiptables-nftolarak gelir. - Hedef: “iptables komutları nft backend’e yazsın”.
Kontrol:
sudo iptables -V
sudo update-alternatives --display iptables 2>/dev/null || true
sudo alternatives --display iptables 2>/dev/null || true
Bu aşamada kazanım: farklı sunucularda farklı backend (legacy vs nft) karmaşasını bitirmek.
4) Aşama 2 — native nft’ye geçiş (asıl operasyonel kazanç)
A) nft “iskeletini” kur (table/chain modeli)
Minimal bir iskelet:
inet filtertablosuinput,forward,outputchain’leripolicy drop+ allow list
B) Shadow counter yaklaşımı
Prod’da en yüksek değer: counter. nft, kural seviyesinde byte/packet counter’larını net verir.
sudo nft list ruleset
sudo nft list ruleset -a
Kritik kurallarınızın gerçekten “hit” aldığını görmeden silmeyin/taşımayın.
5) Dalga rollout: blast radius’i yönet
Benim pratik sıram:
- test/lab sunucuları
- düşük kritik batch/worker
- edge’e en uzak internal servisler
- kritik API’ler
- edge/NAT/gateway sınıfı (en son)
Her dalga için “başarı kriteri” koy:
- 30–60 dk içinde drop/latency yok
- conntrack trendi normal
- CPU/softirq normal
- uygulama error rate normal
6) Hızlı rollback (runbook’un kalbi)
Rollback’ı “akılda” tutma; yazılı hale getir.
Örnek rollback yaklaşımı:
- nft ruleset’i boşalt
- iptables-save’den restore et
- servisi/host’u yeniden doğrula
sudo nft flush ruleset
sudo iptables-restore < /var/tmp/iptables-save.txt
sudo ip6tables-restore < /var/tmp/ip6tables-save.txt
Not: Bu komutlar örnek. Kendi dağıtımınızda kalıcı kuralların (systemd unit, netfilter-persistent vb.) nasıl yüklendiğini runbook’a ekleyin.
7) Sık görülen tuzaklar
- NAT/conntrack timeouts: davranış değişince “sessiz” sorun çıkar
- IPv6 unutulur: prod’da kesinti değil, güvenlik açığı üretir
- Servis bazlı istisnalar dağınık kalır: “bir yerlerde bir script” ile yönetilen kurallar zamanla drift üretir
Sonuç
iptables’tan nftables’a geçiş; modernleşme projesi değil, operasyonel güven projesidir. Başarı; çeviri araçlarında değil, envanterin kanıtla kurulmasında, dalga rollout disiplininde ve rollback’in gerçekten çalışmasında ortaya çıkar. nftables’a geçtiğiniz gün kazandığınız şey yeni komutlar değil; daha okunur, daha ölçülebilir ve daha yönetilebilir bir firewall düzlemidir.