Ubuntu-তে iptables বনাম nftables: কোনটি চলছে?

Ubuntu-তে iptables বনাম nftables: আপনার box কোনটি চালাচ্ছে?

Ubuntu 20.04 এবং পরবর্তী সংস্করণে iptables কমান্ডটি এমন একটি front end, যা nftables rule লেখে। Kernel-এ একটি packet filter, nftables, চলে এবং দুটি user space command সেটিকে program করে। একটি iptables -A INPUT line আগের মতোই কাজ করে এবং এটি যে rule তৈরি করে, তা nft print করতে পারে।

এটি সত্য ধরে নেওয়ার আগে নিজের server-এ নিশ্চিত করুন।

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

Ubuntu 24.04-এ (August 2026 অনুযায়ী iptables 1.8.10), iptables -V, iptables v1.8.10 (nf_tables) print করে। বন্ধনীর ভেতরের নামটি backend। (nf_tables) মানে command-টি nftables-এর সঙ্গে কথা বলছে। (legacy) মানে পুরোনো x_tables backend, যেটি Ubuntu এখনও iptables-legacy হিসেবে release করে এবং kernel-এ সম্পূর্ণ আলাদা ruleset হিসেবে রাখে। update-alternatives এই পছন্দের পেছনের symlink print করে: link currently points to /usr/sbin/iptables-nft।

কোনো firewall configured না থাকা নতুন VPS-এ sudo nft list ruleset কিছুই print করে না। এই খালি output-ই আপনার baseline। পুরোনো পদ্ধতিতে একটি rule যোগ করে আবার দেখুন।

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 rule আসলে একটি nftables rule। iptables-nft এটি যে table তৈরি করে, তা চিহ্নিত করে। ওই চিহ্ন দেখলে nft warning print করে, কারণ nft দিয়ে এমন table edit করলে একই rule-এর দায়িত্ব দুটি tool-এর হাতে থাকে। একটি command কী তৈরি করেছে তা দেখুন: এমন একটি table, যার নাম আপনি দেননি, এবং এমন chains, যেগুলোর অনুরোধ আপনি করেননি। এটাই পুরোনো model। সরাসরি nftables লিখলে প্রথম যে বিষয়টি পরিবর্তিত হয়, সেটিও এটি।

আপনার কাছ থেকে iptables -L কী আড়াল করে

iptables -L কেবল filter table দেখায়। NAT (network address translation) rule দেখতে iptables -t nat -L প্রয়োজন, আর mangle rule দেখতে -t mangle প্রয়োজন। IPv6-এর জন্য আলাদা command, ip6tables, ব্যবহার করা হয় এবং সেখানে প্রতিটি rule-এর নিজস্ব অনুলিপি থাকে। তাই একটি listing-এ server পরিষ্কার দেখালেও, আপনি যে table পরীক্ষা করেননি সেখানকার কোনো rule আপনার packet drop বা rewrite করতে পারে।

sudo nft list ruleset একটি output-এ প্রতিটি family, প্রতিটি table, প্রতিটি chain এবং প্রতিটি rule দেখায়। আপনি নিজে তৈরি করেননি এমন server-এ বাস্তবে কী loaded আছে তা বোঝার দ্রুততম উপায় হলো এই একক command। Rule handle দেখাতে -a যোগ করুন। একটি সম্পূর্ণ chain মুছে না দিয়ে নির্দিষ্ট rule মুছতে এই handle প্রয়োজন।

এখানে থাকতেই দুটি অভ্যাস সংশোধন করা ভালো। iptables -L address ও port-কে name-এ রূপান্তর করে। তাই resolver নষ্ট থাকলে command-টি আটকে গেছে বলে মনে হতে পারে। এর পরিবর্তে iptables -nvL ব্যবহার করুন। এছাড়া sudo iptables-legacy -nvL দিয়ে নিশ্চিত করুন যে legacy backend ফাঁকা। কারণ দুই backend-এই rule থাকলে kernel উভয় backend-এর rule evaluate করে, আর কোনো একটি listing-ই সম্পূর্ণ চিত্র দেখায় না।

আপনি যে table ও chain তৈরি করেন, উত্তরাধিকারসূত্রে পান না

nftables শুরুতে কিছুই থাকে না। আপনি তৈরি না করা পর্যন্ত কোনো filter table থাকে না, এবং filter শুধু আপনার বেছে নেওয়া একটি নাম। কোনো chain-এ type, hook এবং priority নির্ধারণ করলেই সেটি packet দেখতে পায়; তখন সেটি একটি base chain হয়। এগুলো ছাড়া কোনো chain-এ শুধু explicit jump বা goto দিয়ে পৌঁছানো যায়। তাই কোনো কিছু সেখানে jump না করা পর্যন্ত এর কোনো খরচ হয় না।

আরেকটি বড় পরিবর্তন হলো inet family। একটি inet table একই rules-এ IPv4 এবং IPv6 পরিচালনা করে। এতে এমন এক ধরনের bug পুরোপুরি এড়ানো যায়, যেখানে iptables-এ কোনো port বন্ধ থাকে কিন্তু ip6tables-এ সেটি সবার জন্য খোলা থাকে। এই অসামঞ্জস্য এত সাধারণ যে ufw চালিত server-এ এর নিজস্ব failure mode আছে।

এখানে একটি সম্পূর্ণ server ruleset দেওয়া হলো। এটি /etc/nftables.conf-এ থাকবে।

#!/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;
  }
}

লাইন 2 দুবার পড়ুন। flush ruleset server-এর সব table মুছে দেয়, যার মধ্যে ufw এবং Docker নিজেদের জন্য তৈরি করা table-ও রয়েছে। Live server-এ এটি চালানোর আগে পরের অংশ পড়া শেষ করুন।

input chain-এর প্রথম rule-ই অধিকাংশ কাজ করে। ct state established,related accept আপনার শুরু করা connection-এর reply ফিরতে দেয়। তাই chain-এর বাকি অংশকে শুধু নতুন connection নিয়ে সিদ্ধান্ত নিতে হয়। ct state invalid drop এমন packet বাদ দেয়, যা কোনো পরিচিত connection বা বৈধ connection start-এর সঙ্গে মেলে না। এরপরের সবকিছু explicit hole, আর policy drop বাকি packet পরিচালনা করে।

ফাইলটি load করার আগে পরীক্ষা করুন। এই কাজের সময় একটি দ্বিতীয় SSH session খোলা রাখুন। policy drop এবং SSH rule-এ একটি typo থাকলেই আপনি নিজের server-এ প্রবেশাধিকার হারাতে পারেন।

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

nft -c -f কোনো কিছু load না করেই ফাইলটি parse করে এবং error জানায়। Parse সফল হলে কোনো output দেখায় না।

দীর্ঘ rule তালিকার পরিবর্তে set ব্যবহার করুন

tcp dport { 80, 443 } একটি anonymous set: প্রতিটি port-এর জন্য আলাদা rule না লিখে একটি rule এবং একটি lookup ব্যবহার করা হয়। admin_ips-এর মতো named set আরও সুবিধাজনক, কারণ firewall চালু থাকা অবস্থাতেও এটি পরিবর্তন করা যায়।

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 }

কোনো reload বা rule renumbering দরকার হয় না। Set-এ পাঁচটি address থাকুক বা পঞ্চাশ হাজার, match সব সময় একটি lookup হিসেবেই থাকে। flags interval flag-এর কারণে set-এ 198.51.100.0/24-এর মতো range এবং CIDR (classless inter-domain routing) prefix রাখা যায়। এই flag না থাকলে set শুধু single address গ্রহণ করে, এবং prefix load করতে ব্যর্থ হয়।

Set-এর element-গুলোর জন্যও স্বয়ংক্রিয় মেয়াদ শেষ হওয়ার সময় নির্ধারণ করা যায়।

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

ip saddr @banned drop rule ব্যবহার করলে প্রতিটি element যোগ করার এক ঘণ্টা পরে নিজে থেকেই সরিয়ে যায়। Ubuntu 24.04-এ fail2ban-এর nftables action এভাবেই একটি address ban করে: এটি set-এ একটি element যোগ করে, নতুন rule যোগ করে না। Port সম্পর্কে ধারণা নতুন হলে Linux-এ port আসলে কী দিয়ে শুরু করুন।

Migration-এর সময় একটি পার্থক্য অনেকের নজরে আসে। আপনি না চাইলে nftables packet গণনা করে না। iptables -nvL সব সময় প্রতিটি rule-এর counter দেখায়। nftables-এ শুধু counter keyword থাকা rule-এর number থাকে। তাই পরে debug করার সম্ভাবনা আছে এমন যেকোনো rule-এ counter যোগ করুন।

হুক ও priority কীভাবে নিয়মের ক্রম নির্ধারণ করে

একটি base chain-এ একটি hook-এর নাম থাকে। প্যাকেটের path-এর যে পর্যায়ে chain-টি চালানো হয়, hook সেই স্থান নির্ধারণ করে। prerouting routing decision-এর আগে চলে। input এই মেশিনের উদ্দেশে পাঠানো packet-এর ক্ষেত্রে চলে। forward এই মেশিনের মধ্য দিয়ে routed packet-এর ক্ষেত্রে চলে। output local process থেকে আসা packet-এর ক্ষেত্রে চলে। postrouting সবশেষে চলে, packet বের হওয়ার ঠিক আগে।

একটি hook-এর ভেতরে chain-এর ক্রম priority নির্ধারণ করে। কম সংখ্যার priority আগে চলে। nftables প্রচলিত value-গুলোর জন্য নাম ব্যবহার করে: raw হলো -300, mangle হলো -150, dstnat হলো -100, filter হলো 0, এবং srcnat হলো 100। priority filter; লেখা এবং priority 0; লেখা একই।

এখন কোন পরিস্থিতিতে tool মিশিয়ে ব্যবহার করা যায়, তা নির্ধারণকারী অংশটি দেখুন। একটি hook-এ নিবন্ধিত প্রতিটি base chain priority-এর ক্রমে চলে। আপনার chain-এ কোনো packet accept হলেও processing শেষ হয় না: accept শুধু সেই chain শেষ করে, এবং packet একই hook-এর পরবর্তী base chain-এ এগিয়ে যায়। drop সব ক্ষেত্রেই চূড়ান্ত এবং সঙ্গে সঙ্গে packet থামিয়ে দেয়। তাই আপনার table-এ permissive rule থাকলেও ufw-এর table-এ থাকা drop rule বাতিল করতে পারে না, কোনটি আগে চলেছে তা নির্বিশেষে। পরে চলা কোনো chain থেকে আপনার accept আপনাকে সুরক্ষা দেয় না।

একই hook-এ একই priority-সহ দুটি base chain registration order অনুযায়ী চলে। কোন service আগে start হয়েছে, তার ওপর এই order নির্ভর করে। reboot-এর পর এই order বদলে যেতে পারে। ufw-এর পাশাপাশি নিজের table চালাতেই হলে আলাদা priority দিন। এতে order আগে থেকেই নির্ধারিত থাকবে এবং race condition-এর ওপর নির্ভর করতে হবে না।

কেন লেখার মতো কোনো reverse NAT rule নেই?

এই প্রশ্নটিই মানুষ সবচেয়ে বেশি ভুল করে। তাই সরাসরি উত্তর হলো: connection tracking আপনার হয়ে reverse translation লিখে দেয়। দ্বিতীয় কোনো rule যোগ করার দরকার নেই।

সাধারণ VPS-এর উভয় কাজ করা একটি nat table দেখতে এমন হয়।

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
  }
}

একটি connection-এর শুধু প্রথম packet-ই কোনো nat chain-এর বিরুদ্ধে পরীক্ষা করা হয়। কোনো rule match করলে kernel সেই translation-টি connection tracking table-এ connection-এর entry-এর সঙ্গে সংরক্ষণ করে। এরপর উভয় দিকের প্রতিটি packet সংরক্ষিত entry অনুযায়ী rewrite হয়। কোনো rule আর পড়া হয় না। `conntrack` tool install করে একটি live entry দেখুন।

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

এটিকে দুটি tuple হিসেবে পড়ুন। প্রথম চারটি field হলো client যে connection পাঠিয়েছে, যার গন্তব্য `203.0.113.10:8080, অর্থাৎ আপনার public address। পরের চারটি field হলো kernel যে reply আশা করছে; এটি আগে থেকেই উল্টো করা এবং translated, এবং 10.0.0.5:80`, অর্থাৎ প্রকৃত backend থেকে আসছে। ওই দ্বিতীয় tuple-টিই reverse rule। প্রথম packet match করার সময় kernel এটি লিখেছে।

তাই return direction-এর জন্য rule লিখবেন না। এটি match করতে পারবে না, কারণ return packet-গুলো established connection-এর অন্তর্ভুক্ত এবং কোনো nat chain-এ পৌঁছায় না। আর কোনোভাবে match করলেও kernel যে packet ইতিমধ্যে ঠিক করে দিয়েছে, আপনি সেটিকেই আবার translate করতেন।

একই mechanism থেকে বোঝা যায়, কোনো rewrite কোথায় বসাতে হবে। Destination translation `prerouting-এ চলতে হবে, অর্থাৎ routing decision-এর আগে। কারণ routing-কে নতুন destination দেখতে হবে, নইলে packet ভুল জায়গায় যাবে। Box নিজে তৈরি করা traffic একই কারণে output hook-এ পরিচালিত হয়। Source translation, source port rewrite-সহ, postrouting-এ চলতে হবে, অর্থাৎ routing outgoing interface নির্ধারণ করার পরে। masquerade` ওই interface থেকে address নেয়। Routing চলা পর্যন্ত interface জানা যায় না।

এই কারণেই এমন একটি rule path-এর শেষে এবং অন্য কোথাও নয়, বসবে।

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

Port range source address-এর সঙ্গে source port-ও rewrite করে। অনেক internal client একটি public address ভাগ করে ব্যবহার করলে এবং তাদের source port একই হয়ে গেলে এটাই প্রয়োজন। Reply ওই range-এর কোনো port-এ পাঠানো হলে conntrack সেটিকে entry-এর সঙ্গে মিলিয়ে নেয়। Packet deliver হওয়ার আগে original source port ফিরিয়ে দেওয়া হয়। আবারও বলছি, দ্বিতীয় কোনো rule দরকার নেই।

এর একটি গুরুত্বপূর্ণ বাস্তব ফল আছে: NAT rule পরিবর্তন করলে ইতিমধ্যে থাকা connection-গুলোর translation পরিবর্তিত হয় না, কারণ তাদের translation আগেই সংরক্ষিত হয়েছে। Entry expire না হওয়া পর্যন্ত তারা পুরোনো আচরণ বজায় রাখে। `sudo conntrack -D -p tcp --dport 8080 matching entry-গুলো মুছে দেয় এবং sudo conntrack -F` সব entry মুছে দেয়। NAT box-এ দ্বিতীয় command-টি সতর্কতার সঙ্গে ব্যবহার করুন। কারণ সংরক্ষিত translation-ই বর্তমান connection-গুলো সচল রাখে। এগুলো flush করলে box-এর মধ্য দিয়ে চলা প্রতিটি connection একসঙ্গে বিচ্ছিন্ন হবে।

ufw এবং Docker উভয়ই নিজেদের firewall rule তৈরি করে

ufw হলো iptables-এর একটি front end। Ubuntu-তে iptables আবার nftables-এর একটি front end। তাই একটি ufw-চালিত সিস্টেমে ip filter table-এর মধ্যে ufw-before-input, ufw-user-input ইত্যাদি নামে একাধিক chain থাকে। একই কাঠামোর একটি ip6 filter copy-ও থাকে। sudo nft list ruleset | grep ufw দিয়ে এগুলো দেখুন। এই chain-গুলো /etc/ufw-এর file থেকে তৈরি হয়। ufw reload প্রতিবার এগুলো শূন্য থেকে আবার লেখে। তাই হাতে লেখা কোনো iptables rule যোগ করলে পরবর্তী reload-এর সময় সেটি হারিয়ে যায়। VPS-এর জন্য ufw-এর প্রাথমিক বিষয়গুলো-তে এই file layout ব্যাখ্যা করা হয়েছে।

Docker নিজেই firewall configure করে এবং ufw-এর rule অনুসরণ করে না। -p 80:80 দিয়ে কোনো port publish করলে nat table-এ একটি DNAT rule এবং forward path-এ একটি accept rule লেখা হয়। উভয় rule-ই ufw-এর user chain-এর আগে কার্যকর হয়। ফলে একবার হলেও সবাই অবাক হন: ufw deny 80 load করা আছে, কিন্তু container এখনও Internet থেকে reachable। এর সমাধান রয়েছে DOCKER-USER chain-এ, যেটি Docker আপনার rule রাখার জন্য তৈরি করে। Docker container কেন ufw উপেক্ষা করে বিষয়টি ধাপে ধাপে ব্যাখ্যা করে। আপনার সিস্টেমে বর্তমানে কী আছে, তা sudo nft list ruleset | grep -i docker দিয়ে দেখুন।

এখন উপরের configuration-এর সেই flush ruleset line-টি আবার পড়ুন। এটি সব table মুছে দেয়, যার মধ্যে ওই দুই tool পরিচালিত table-ও রয়েছে। Docker host-এ published port-গুলো sudo systemctl restart docker chain পুনর্গঠন না করা পর্যন্ত কাজ বন্ধ রাখে। Firewall পরিষ্কার করতে গিয়ে নিজের service-গুলো offline করে ফেলার সবচেয়ে সাধারণ কারণ এই একটি line।

রিবুটের পরও কার্যকর থাকা নিয়ম

কোনো ruleset-ই নিজে থেকে persistent নয়। shutdown-এর সময় kernel সবকিছু ভুলে যায়, এবং প্রতিটি পদ্ধতি আলাদা package ব্যবহার করে এই সমস্যা সমাধান করে।

nftables-এর ক্ষেত্রে /etc/nftables.conf ফাইলটি nftables.service পড়ে। Ubuntu-তে ওই service disabled অবস্থায় থাকে, তাই এটিকে নির্ভরযোগ্য ধরে নেওয়ার আগে status পরীক্ষা করুন।

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

iptables-এর জন্য package হলো iptables-persistent। এটি netfilter-persistent ইনস্টল করে এবং /etc/iptables/rules.v4 ও /etc/iptables/rules.v6-এ সংরক্ষণ করে।

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

দুটো একসঙ্গে চালাবেন না। Firewall সংরক্ষণের দায়িত্ব নেওয়া দুটি ফাইলের নিয়ম সময়ের সঙ্গে আলাদা হয়ে যাবে। কোনটি পরে load হবে, তা নির্ধারণ করা যায় না; শেষবার load হওয়া ruleset কার্যকর হবে।

Live ruleset dump করার ক্ষেত্রেও একটি সম্পর্কিত সমস্যা আছে। sudo nft -s list ruleset > /etc/nftables.conf ওই মুহূর্তে load থাকা সবকিছু সংরক্ষণ করে, যার মধ্যে ufw-এর tables এবং Docker-এর tables-ও থাকে। Boot-এর সময় সেটি restore করলে আপনি এমন rules-এর একটি স্থির কপি পাবেন, যেগুলো ওই tools নিজেদের মতো করে তৈরি করার কথা। এগুলো start হওয়ার পর একই rules-এর দ্বিতীয় কপিও তৈরি হবে। শুধু নিজের table dump করতে sudo nft -s list table inet filter ব্যবহার করুন। -s flag counters বাদ দেয়, কারণ config file-এ counters থাকা উচিত নয়।

VPS-এ কি native firewall চালু করবেন?

ufw-কে অপরিবর্তিত রাখুন, যদি না এমন কোনো নিয়ম প্রয়োজন হয় যা ufw প্রকাশ করতে পারে না। সাধারণ VPS ব্যবহারের জন্য ufw যথেষ্ট: default deny এবং কয়েকটি উন্মুক্ত port। শুধু আলাদা নিয়ম লেখার উদ্দেশ্যে ufw-এর বদলে hand-written ruleset ব্যবহার করলে একই firewall-এর সঙ্গে রক্ষণাবেক্ষণের জন্য আরও একটি বিষয় যোগ হয়।

আপনার প্রয়োজন যদি ufw-এর model-এর বাইরে হয়, তখন native firewall ব্যবহার করুন: NAT ও port forwarding, runtime-এ update করা sets, উভয় address family-এর জন্য প্রযোজ্য একটি rule, অথবা নিজে নির্ধারণ করা chain priority। এগুলো বাস্তব কারণ। ufw দিয়ে এগুলোর কোনোটি নির্দিষ্ট করা যায় না।

native firewall ব্যবহার করলে সম্পূর্ণভাবে native পদ্ধতিতেই যান। sudo ufw disable এবং sudo systemctl disable --now ufw চালান। এরপর sudo nft list ruleset দিয়ে নিশ্চিত করুন যে ufw-এর tables সরানো হয়েছে। তারপর নিজের file load করুন। ufw এবং hand-written table একসঙ্গে চালু থাকা server এখনও network traffic pass করবে। তবে live policy এখন দুটি ruleset-এর union। এগুলো service startup নির্ধারিত ক্রমে evaluate হয়। ফলে কোনো file পড়ে কেউই নিশ্চিতভাবে বলতে পারবে না যে serverটি আসলে কী করছে।

বিদ্যমান iptables ruleset স্থানান্তর

iptables-translate একটি rule রূপান্তর করে এবং nftables রূপটি দেখায়। এটি সার্ভারে কোনো পরিবর্তন করে না।

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 একটি সম্পূর্ণ সংরক্ষিত ruleset-এর ক্ষেত্রেও একই কাজ করে। এর output-কে প্রথম খসড়া হিসেবে বিবেচনা করুন। রূপান্তরটি যান্ত্রিক এবং প্রতিটি rule আলাদাভাবে রূপান্তর করে। তাই পুরোনো table ও chain-এর নাম ফিরে পাবেন, IPv4 এবং IPv6-এর জন্য দুটি আলাদা ruleset পাবেন, কিন্তু migration-এর মূল সুবিধা তৈরি করা কোনো set পাবেন না। এটি হাতে সম্পাদনা করে একটি inet table-এ একত্র করুন। Live server-এ প্রয়োগ করার আগে nft -c -f দিয়ে তা যাচাই করুন।

এই উদাহরণগুলোর address documentation range 203.0.113.0/24 এবং 198.51.100.0/24 থেকে নেওয়া হয়েছে, আর enp1s0 একটি interface name। আমার মান copy না করে ip route show default এবং ip -br addr থেকে আপনার মান নিন, কারণ বর্তমান Ubuntu image-গুলোতে কোনো কিছুর নাম সাধারণত eth0 থাকে না।

FAQ

Ubuntu-এ iptables কি deprecated?

এই command বন্ধ হয়ে যাচ্ছে না, এবং Ubuntu 24.04-এ এখনও কাজ করে। পরিবর্তনটি হয়েছে ভিতরের বাস্তবায়নে: iptables হলো এমন একটি front end, যা iptables-nft back end-এর মাধ্যমে nftables rules লিখে। iptables -V চালিয়ে আপনার configuration পরীক্ষা করুন; এটি 24.04-এ iptables v1.8.10 (nf_tables) দেখায়। পুরোনো x_tables back end এখনও iptables-legacy হিসেবে ship করে, এবং এটি সম্পূর্ণ আলাদা ruleset ধরে রাখে। তাই rules একটি back end-এ লিখুন, উভয়টিতে নয়।

ফেরার পথে NAT বাতিল করতে কি দ্বিতীয় rule দরকার?

না। কোনো connection-এর প্রথম packet একটি nat rule-এর সঙ্গে match করলে connection tracking সেই translation সংরক্ষণ করে। এরপর উভয় দিকের প্রতিটি packet ওই সংরক্ষিত entry অনুযায়ী rewrite হয়। sudo conntrack -L এটিকে প্রতিটি connection-এর জন্য দুটি tuple হিসেবে দেখায়: প্রথমটি original direction, দ্বিতীয়টি ইতিমধ্যে reversed reply। Return direction-এর জন্য লেখা rule কাজে আসবে না, কারণ return packet কখনও nat chain-এ পৌঁছায় না।

একই সময়ে কি ufw এবং নিজের nftables rules চালাতে পারি?

চালানো যায়, তবে এতে সমস্যা তৈরি হবে। কোনো hook-এর প্রতিটি base chain চালু হয়। তাই live policy হলো উভয় ruleset-এর সমন্বয়। এগুলো priority অনুযায়ী কার্যকর হয় এবং priority সমান হলে যে service আগে start হয়েছে, তার ক্রম অনুযায়ী চলে। যেকোনো একটিতে থাকা drop চূড়ান্ত সিদ্ধান্ত দেয়। আপনার ruleset-এ থাকা accept অন্য ruleset-কে একই packet drop করা থেকে আটকায় না। একটি tool বেছে নিন। nftables ব্যবহার করলে আগে ufw disable করুন এবং sudo nft list ruleset থেকে নিশ্চিত করুন যে এর tables আর নেই।

Ubuntu-এ reboot-এর পর nftables rules কীভাবে সক্রিয় রাখব?

Ruleset /etc/nftables.conf-এ রাখুন, sudo nft -c -f /etc/nftables.conf দিয়ে পরীক্ষা করুন, তারপর sudo systemctl enable --now nftables চালান। এই service defaultভাবে enabled থাকে না, তাই একবার systemctl is-enabled nftables চালানো ভালো। ওই file তৈরি করার সময় শুধু নিজের table dump করতে sudo nft -s list table inet filter ব্যবহার করুন। কারণ সম্পূর্ণ list ruleset dump করলে ufw এবং Docker নিজেদের জন্য পরিচালনা করা tables-ও এতে অন্তর্ভুক্ত হয়।