SSD Nodes Learn 🎉 VPS $5.50/నెల నుండి
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-16

Ubuntuలో iptables vs nftables: ఏది నడుస్తోంది?

Ubuntuలో iptables command నిజానికి nftables rules రాస్తుందో మీ serverలో నిర్ధారించండి. native ruleset చదవడం, ufw మరియు Docker మధ్య ఘర్షణలు ఎలా వస్తాయో తెలుసుకోండి.

Ubuntuలో iptables vs nftables: మీ box ఏది నడుపుతోంది?

Ubuntu 20.04 మరియు తదుపరి సంస్కరణల్లో, iptables command అనేది nftables rules రాసే front end. Kernelలో ఒకే packet filter, nftables, నడుస్తుంది. దాన్ని program చేయడానికి రెండు user space commands ఉన్నాయి. ఒక iptables -A INPUT line మునుపటిలాగే పనిచేస్తుంది. అది సృష్టించే rule nftables 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 చేస్తుంది. Bracketsలో ఉన్న పేరు back endను సూచిస్తుంది. (nf_tables) అంటే command nftablesతో మాట్లాడుతోందని అర్థం. (legacy) అంటే పాత x_tables back end. Ubuntu ఇప్పటికీ దాన్ని iptables-legacyగా ship చేస్తోంది. Kernel దాన్ని పూర్తిగా వేరు rulesetగా ఉంచుతుంది. ఆ ఎంపిక వెనుక ఉన్న symlinkను update-alternatives print చేస్తుంది: link currently points to /usr/sbin/iptables-nft.

Firewall configure చేయని fresh VPSలో, sudo nft list ruleset ఏమీ print చేయదు. ఆ ఖాళీ output మీ baseline. పాత పద్ధతిలో ఒక ruleను add చేసి మళ్లీ పరిశీలించండి.

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. అది సృష్టించే tablesను iptables-nft mark చేస్తుంది. ఆ mark కనిపించినప్పుడు nft ఈ warningను print చేస్తుంది. ఎందుకంటే అలాంటి tableను nftతో edit చేస్తే, ఒకే rulesను రెండు tools నియంత్రిస్తాయి. ఒక command ఏం సృష్టించిందో చూడండి: మీరు పేరు ఇవ్వని table, మీరు కోరని chains. ఇదే పాత model. మీరు నేరుగా nftables rules రాయడం ప్రారంభించినప్పుడు మొదట మారేది ఇదే.

మీ నుంచి iptables -L దాచేది

iptables -L filter పట్టికను మాత్రమే చూపిస్తుంది. NAT (network address translation) నియమాలకు iptables -t nat -L అవసరం, అలాగే mangle నియమాలకు -t mangle అవసరం. IPv6 కోసం ప్రత్యేక command ip6tables ఉంటుంది; అందులో ప్రతి నియమానికి స్వంత ప్రతిరూపం ఉంటుంది. అందువల్ల ఒక listing లో system శుభ్రంగా కనిపించినా, మీరు ఎప్పుడూ పరిశీలించని పట్టికలోని నియమం మీ packets ను drop చేయవచ్చు లేదా వాటిని మార్చవచ్చు.

sudo nft list ruleset ప్రతి address family, ప్రతి table, ప్రతి chain, ప్రతి rule ను ఒకే output లో ముద్రిస్తుంది. మీరు స్వయంగా నిర్మించని server లో నిజంగా ఏవి loaded అయ్యాయో తెలుసుకోవడానికి ఈ ఒక్క command అత్యంత వేగవంతమైన మార్గం. Rule handles ను ముద్రించడానికి -a ను జోడించండి. మొత్తం chain ను కాకుండా ఒకే rule ను తొలగించడానికి ఇవి అవసరం.

ఇక్కడ ఉన్నప్పుడే రెండు అలవాట్లను సరిచేయడం మంచిది. iptables -L addresses మరియు ports ను names గా resolve చేస్తుంది. Resolver పనిచేయని server లో అది hang అయినట్లు కనిపించవచ్చు. అందుకే iptables -nvL ఉపయోగించండి. అలాగే legacy back end ఖాళీగా ఉందని sudo iptables-legacy -nvL తో నిర్ధారించండి. రెండు back ends లోనూ rules ఉంటే kernel రెండింటినీ evaluate చేస్తుంది. ఏ listing కూడా పూర్తి పరిస్థితిని చూపించదు.

మీరు సృష్టించే tables మరియు chains, వారసత్వంగా వచ్చేవి కాదు

nftables ఖాళీ స్థితి నుంచి ప్రారంభమవుతుంది. మీరు సృష్టించే వరకు filter table ఉండదు. filter అనే పదం మీరు ఎంచుకున్న పేరు మాత్రమే. ఒక chain కు type, hook మరియు priority ఇచ్చినప్పుడే అది packets ను చూస్తుంది; అప్పుడు అది base chain అవుతుంది. ఇవి లేకపోతే ఆ chain ను స్పష్టమైన jump లేదా goto ద్వారా మాత్రమే చేరుకోవచ్చు. మరేదైనా chain దానికి jump చేయనంత వరకు దానిపై ఎటువంటి వ్యయం ఉండదు.

మరో ముఖ్యమైన మార్పు inet family. ఒకే inet table లో IPv4 మరియు IPv6 కోసం ఒకే rules నిర్వహించవచ్చు. దీనివల్ల iptables లో port మూసి ఉండి, ip6tables లో పూర్తిగా తెరిచి ఉండే bug తరగతి మొత్తం తొలగుతుంది. ఈ mismatch చాలా సాధారణం. అందుకే ufw boxesలో దీనికి ప్రత్యేక 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;
  }
}

Line 2 ను రెండుసార్లు చదవండి. flush ruleset boxలోని ప్రతి table ను తొలగిస్తుంది. ఇందులో ufw మరియు Docker తమ కోసం సృష్టించిన tables కూడా ఉంటాయి. Live serverపై దీన్ని run చేసే ముందు మిగతా వివరాలను పూర్తిగా చదవండి.

Input chainలోని మొదటి rule ఎక్కువ పనిని చేస్తుంది. మీరు ప్రారంభించిన connectionsకు సంబంధించిన replies తిరిగి రావడానికి ct state established,related accept అనుమతిస్తుంది. అందువల్ల మిగిలిన chain కొత్త connections గురించి మాత్రమే నిర్ణయించాలి. తెలిసిన connectionకు సరిపోని, చెల్లుబాటు అయ్యే ప్రారంభం లేని packets ను ct state invalid drop విస్మరిస్తుంది. ఆ తర్వాత ఉన్న ప్రతి rule స్పష్టంగా అనుమతించిన మార్గం. మిగిలిన వాటిని policy drop నిర్వహిస్తుంది.

Fileను 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 fileను parse చేసి, ఏదీ load చేయకుండా errorsను నివేదిస్తుంది. Parse సరిగ్గా జరిగితే ఎటువంటి outputను ప్రింట్ చేయదు.

దీర్ఘమైన నియమాల జాబితాలకు బదులుగా sets

tcp dport { 80, 443 } అనేది anonymous set. ప్రతి port కు ఒక నియమం ఉండటానికి బదులుగా, ఇందులో ఒక నియమం మరియు ఒక 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 అవసరం లేదు. నియమాల సంఖ్యలను మళ్లీ కేటాయించాల్సిన అవసరం లేదు. Set లో ఐదు addresses ఉన్నా, యాభై వేల addresses ఉన్నా match ఒకే lookup గా ఉంటుంది. Set లో ranges మరియు 198.51.100.0/24 వంటి CIDR (classless inter-domain routing) prefixes ఉంచడానికి flags interval అనుమతిస్తుంది. ఆ flag లేకపోతే set single addresses ను మాత్రమే స్వీకరిస్తుంది. Prefix ను load చేయడం విఫలమవుతుంది.

Sets తమ elements కు expiry కూడా అమలు చేయగలవు.

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

ip saddr @banned drop నియమంతో, ప్రతి element add చేసిన ఒక గంట తర్వాత తానే తొలగిపోతుంది. Ubuntu 24.04లో fail2ban ఉపయోగించే nftables action address ను ban చేసే విధానం ఇదే. అది కొత్త rule ను add చేయదు. Set లో element ను add చేస్తుంది. Ports గురించి ఇంకా స్పష్టత లేకపోతే, Linuxలో port అంటే వాస్తవంగా ఏమిటి అనే వివరణతో ప్రారంభించండి.

Migration సమయంలో ఒక తేడా చాలామందిని ఇబ్బంది పెడుతుంది. మీరు స్పష్టంగా అడిగితే తప్ప nftables packets ను count చేయదు. iptables -nvL ప్రతి rule కు counters ను ఎల్లప్పుడూ చూపిస్తుంది. nftablesలో counter keyword ఉన్న rules కు మాత్రమే numbers ఉంటాయి. అందువల్ల తరువాత debug చేయాలని భావించే ప్రతి rule లో counter ఉంచండి.

హుక్లు మరియు ప్రాధాన్యతలు క్రమాన్ని ఎలా నిర్ణయిస్తాయి

ఒక base chain ఒక hook పేరును సూచిస్తుంది. ప్యాకెట్ మార్గంలో ఆ chain ఎక్కడ అమలవుతుందో hook నిర్ణయిస్తుంది. prerouting routing నిర్ణయానికి ముందు అమలవుతుంది. input ఈ machine కు ఉద్దేశించిన packets కోసం అమలవుతుంది. forward ఈ machine ద్వారా route అయ్యే packets కోసం అమలవుతుంది. output local processes నుంచి వచ్చే packets కోసం అమలవుతుంది. postrouting చివరగా, packet బయటకు వెళ్లే ముందు అమలవుతుంది.

ఒకే hook లోని chains క్రమాన్ని priority నిర్ణయిస్తుంది. తక్కువ సంఖ్య ముందుగా అమలవుతుంది. nftables సాధారణ విలువలకు పేర్లు ఇస్తుంది: raw అంటే -300, mangle అంటే -150, dstnat అంటే -100, filter అంటే 0, srcnat అంటే 100. priority filter; అని రాయడం, priority 0; అని రాయడంతో సమానం.

Tools ను కలిపి ఉపయోగించడం పనిచేస్తుందా అనే విషయాన్ని నిర్ణయించే భాగం ఇప్పుడు చూద్దాం. ఒక hook పై నమోదైన ప్రతి base chain priority క్రమంలో అమలవుతుంది. మీ chain లో packet ను accept చేసినా ప్రక్రియ పూర్తికాదు: accept ఆ chain ను మాత్రమే ముగిస్తుంది. Packet అదే hook పై ఉన్న తదుపరి base chain కు కొనసాగుతుంది. drop ఎక్కడైనా తుది నిర్ణయంగా పనిచేస్తుంది మరియు packet ను వెంటనే ఆపుతుంది. అందువల్ల మీ table లోని permissive rule, ufw table లోని drop ను అది ముందుగా అమలైనా లేదా తరువాత అమలైనా రద్దు చేయలేరు. తరువాత అమలయ్యే chain నుంచి మీ accept కూడా రక్షణ ఇవ్వదు.

ఒకే hook పై ఒకే priority కలిగిన రెండు base chains registration order లో అమలవుతాయి. ఈ క్రమం ఏ service ముందుగా ప్రారంభమైందో దానిపై ఆధారపడి ఉంటుంది. Reboot ల మధ్య ఈ క్రమం మారవచ్చు. ufw పక్కన మీ స్వంత table ను తప్పనిసరిగా నడపాల్సి వస్తే, దానికి ప్రత్యేక priority ఇవ్వండి. అప్పుడు క్రమం ముందే నిర్ణయించబడుతుంది; registration race పై ఆధారపడదు.

వ్రాయాల్సిన 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 సరిపోతే, 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

దీనిని రెండు tuples గా చదవాలి. మొదటి నాలుగు fields client పంపిన connection ను సూచిస్తాయి. ఇది మీ public address అయిన `203.0.113.10:8080 కు ఉద్దేశించబడింది. రెండో నాలుగు fields kernel ఆశిస్తున్న reply ను సూచిస్తాయి. ఇది ఇప్పటికే reverse చేయబడి, translate చేయబడి, నిజమైన backend అయిన 10.0.0.5:80` నుంచి వస్తుంది. ఆ రెండో tuple reverse rule అవుతుంది. మొదటి packet rule కు సరిపోలినప్పుడు kernel దానిని నమోదు చేసింది.

కాబట్టి return direction కోసం rule రాయకండి. అది match కాలేదు, ఎందుకంటే return packets established connection కు చెందినవి మరియు nat chain కు మళ్లీ చేరవు. ఏదైనా విధంగా అక్కడికి చేరినా, kernel ఇప్పటికే సరిచేసిన packet ను మళ్లీ translate చేసినట్లవుతుంది.

Rewrite ఎక్కడ ఉండాలో ఇదే mechanism నిర్ణయిస్తుంది. Destination translation `prerouting లో అమలుకావాలి. Routing decision కు ముందు ఇది జరగాలి, ఎందుకంటే routing కొత్త destination ను చూడాలి. లేకపోతే packet తప్పు స్థానానికి వెళ్తుంది. ఈ box స్వయంగా సృష్టించే traffic ను అదే కారణంతో output hook లో నిర్వహిస్తారు. Source translation, source port rewrite సహా, postrouting లో అమలుకావాలి. Routing outgoing interface ను ఎంచుకున్న తర్వాత ఇది జరగాలి. masquerade` తన address ను ఆ interface నుంచి తీసుకుంటుంది. 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 clients ఒకే public address ను పంచుకున్నప్పుడు, వారి source ports ఒకదానితో ఒకటి ఢీకొంటే ఇదే అవసరం. Reply ఆ range లోని port కు address చేయబడి వస్తుంది. conntrack దానిని entry తో సరిపోల్చుతుంది. Packet deliver కావడానికి ముందు original source port ను తిరిగి ఉంచుతుంది. మళ్లీ రెండో rule అవసరం లేదు.

దీని ఒక ముఖ్యమైన ప్రాయోగిక ప్రభావం ఉంది: NAT rule ను మార్చడం వల్ల ఇప్పటికే ఉన్న connections కొత్త rule కు మారవు. వాటి translation ఇప్పటికే నిల్వ చేయబడి ఉంటుంది. వాటి entries expire అయ్యే వరకు పాత ప్రవర్తనే కొనసాగుతుంది. సరిపోలే entries ను `sudo conntrack -D -p tcp --dport 8080 తొలగిస్తుంది. sudo conntrack -F` అన్ని entries ను తొలగిస్తుంది. NAT box పై రెండో command ను జాగ్రత్తగా ఉపయోగించాలి. ప్రస్తుత connections కొనసాగడానికి ఆ stored translations అవసరం. వాటిని flush చేస్తే box ద్వారా ఉన్న ప్రతి connection ఒకేసారి తెగిపోతుంది.

ufw మరియు Docker రెండూ తమ సొంత rules ను రాస్తాయి

ufw అనేది iptables కు front end. Ubuntuలో ఇది nftables కు front end. అందువల్ల ufw ఉన్న సిస్టమ్‌లో ip filter tableలో ufw-before-input, ufw-user-input వంటి పేర్లతో chains ఉంటాయి. అదే నిర్మాణానికి సంబంధించిన ip6 filter కాపీ కూడా ఉంటుంది. sudo nft list ruleset | grep ufw తో పరిశీలించండి. ఈ chains /etc/ufw లోని files ఆధారంగా రూపొందుతాయి. ufw reload వాటిని మొదటి నుంచి మళ్లీ రాస్తుంది. అందుకే చేతితో చేర్చిన iptables rule తదుపరి reload సమయంలో కనిపించకుండా పోతుంది. VPS కోసం ufw ప్రాథమికాలు ఆ file నిర్మాణాన్ని వివరిస్తాయి.

Docker firewall rules ను తానే అమలు చేస్తుంది. ఇది ufw ను సంప్రదించదు. -p 80:80 తో port publish చేస్తే nat tableలో DNAT rule రాస్తుంది. Forward pathలో accept rule కూడా రాస్తుంది. ఈ రెండూ ufw user chains కంటే ముందుగా అమలవుతాయి. దీని ఫలితం మొదటిసారి అందరినీ ఆశ్చర్యపరుస్తుంది: ufw deny 80 load చేసినా container internet నుంచి ఇంకా చేరుకోగలిగే స్థితిలో ఉంటుంది. ఇందుకు పరిష్కారం Docker మీ rules కోసం వదిలే DOCKER-USER chainలో ఉంటుంది. Docker containers ufw ను ఎందుకు పట్టించుకోవు అనే వివరణలో ఇది వివరంగా ఉంది. మీ సిస్టమ్‌లో ఏమి ఉన్నదో sudo nft list ruleset | grep -i docker తో చూడండి.

ఇప్పుడు పై configలోని ఆ flush ruleset lineను మళ్లీ చదవండి. ఇది రెండు tools నిర్వహించే tables సహా ప్రతి tableను తొలగిస్తుంది. Docker hostలో sudo systemctl restart docker chainsను మళ్లీ నిర్మించే వరకు publish చేసిన ports పనిచేయవు. Firewallను శుభ్రం చేస్తూ తమ సొంత servicesను offline చేయడానికి ప్రజలు చేసే అత్యంత సాధారణ తప్పు ఇదే.

రీబూట్ తర్వాత కూడా కొనసాగించే నియమాలు

ఏ ruleset కూడా తనంతట తానే persistent గా ఉండదు. Shutdown సమయంలో kernel మొత్తం నియమాలను మర్చిపోతుంది. ప్రతి పద్ధతి దీనిని వేర్వేరు package ద్వారా పరిష్కరిస్తుంది.

nftables కోసం, /etc/nftables.conf ను nftables.service చదువుతుంది. Ubuntu ఆ service ను disabled స్థితిలో అందిస్తుంది. కాబట్టి దానిపై ఆధారపడే ముందు దాని స్థితిని తనిఖీ చేయండి.

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

iptables కోసం package iptables-persistent. ఇది netfilter-persistent ను install చేసి, /etc/iptables/rules.v4 మరియు /etc/iptables/rules.v6 లో save చేస్తుంది.

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

రెండింటినీ ఒకేసారి అమలు చేయవద్దు. Firewall ను నిల్వ చేయడానికి రెండు files ఉన్నప్పుడు వాటి నియమాలు వేర్వేరు కావచ్చు. ఏ file చివరగా load అవుతుందో దాని నియమాలే అమలవుతాయి. మరో file ను చదివి ఆ ఫలితాన్ని ముందుగా ఊహించడం సాధ్యం కాదు.

Live ruleset ను dump చేయడంలో కూడా ఒక సంబంధిత సమస్య ఉంది. sudo nft -s list ruleset > /etc/nftables.conf ఆ సమయంలో load అయి ఉన్న ప్రతిదాన్ని capture చేస్తుంది. ఇందులో ufw tables మరియు Docker tables కూడా ఉంటాయి. Boot సమయంలో దాన్ని restore చేస్తే, ఆ tools స్వయంగా నిర్మించాల్సిన rules కు ఒక స్థిరమైన copy ముందుగా వస్తుంది. అవి ప్రారంభమైన తర్వాత అదే rules కు మరో copy ఏర్పడుతుంది. మీ స్వంత table ను మాత్రమే sudo nft -s list table inet filter తో dump చేయండి. -s flag counters ను మినహాయిస్తుంది. Counters config file లో ఉండకూడదు.

VPS లో firewall ను స్వయంగా ప్రారంభించాలా?

ufw వ్యక్తపరచలేని అవసరం ఉన్నప్పుడు మాత్రమే దాన్ని పక్కన పెట్టండి. సాధారణ VPS అవసరాలను ufw తీరుస్తుంది: డిఫాల్ట్‌గా అన్నింటినీ నిరాకరించి, కొద్దిపాటి ports మాత్రమే తెరవడం. ప్రత్యేక కారణం లేకుండా దీని స్థానంలో చేతితో రాసిన ruleset ఉపయోగిస్తే, అదే firewall తో పాటు నిర్వహించాల్సిన మరో అంశం మాత్రమే పెరుగుతుంది.

మీ అవసరం ufw model పరిధికి వెలుపల ఉన్నప్పుడు native విధానాన్ని ఉపయోగించండి: NAT మరియు port forwarding, runtime లో update చేసే sets, రెండు address families కు వర్తించే ఒకే rule, లేదా మీరు స్వయంగా నిర్ణయించే chain priorities. ఇవి సముచితమైన కారణాలు. వీటిని ufw లో వ్యక్తపరచడానికి మార్గం లేదు.

native విధానాన్ని ఎంచుకుంటే, పూర్తిగా native విధానానికే మారండి. sudo ufw disable మరియు sudo systemctl disable --now ufw అమలు చేసి, దాని tables తొలగించబడ్డాయని sudo nft list ruleset తో నిర్ధారించండి. తరువాత మీ స్వంత file ను load చేయండి. ufw మరియు చేతితో రాసిన table రెండూ కలసి నడుస్తున్న యంత్రం traffic ను ఇప్పటికీ అనుమతిస్తుంది. కానీ live policy ఇప్పుడు రెండు rulesets యొక్క సమ్మేళనంగా ఉంటుంది. అవి service startup నిర్ణయించే క్రమంలో evaluate అవుతాయి. రెండు files లో ఏదైనా చదివిన వ్యక్తి ఆ యంత్రం వాస్తవంగా ఏమి చేస్తుందో ఖచ్చితంగా చెప్పలేడు.

ఇప్పటికే ఉన్న 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 లు వస్తాయి. ఈ మార్పు చేయడం ఉపయోగకరంగా చేసిన sets ఏవీ అందులో ఉండవు. దాన్ని చేతితో ఒకే inet table గా తిరిగి రాయండి. Live server పై అమలు చేయడానికి ముందు nft -c -f తో తనిఖీ చేయండి.

ఈ ఉదాహరణల్లోని addresses documentation ranges 203.0.113.0/24 మరియు 198.51.100.0/24 నుంచి తీసుకున్నవి. enp1s0 ఒక interface పేరు. నా విలువలను కాపీ చేయకుండా, మీ విలువలను ip route show default మరియు ip -br addr నుంచి తీసుకోండి. ప్రస్తుత Ubuntu images లో interface పేరు సాధారణంగా eth0 ఉండదు.

FAQ

Ubuntuలో iptables deprecated అయిందా?

ఈ command తొలగించబడలేదు. Ubuntu 24.04లో ఇది ఇంకా పనిచేస్తుంది. మారింది అంతర్గతంగా జరిగేది: iptables అనేది iptables-nft back end ద్వారా nftables rules రాసే front end. మీ వ్యవస్థలో ఏది ఉందో iptables -V తో తనిఖీ చేయండి. ఇది 24.04లో iptables v1.8.10 (nf_tables) ను చూపిస్తుంది. పాత x_tables back end ఇప్పటికీ iptables-legacy గా అందుబాటులో ఉంది. అది పూర్తిగా వేరు ruleset ను నిర్వహిస్తుంది. కాబట్టి rules ను ఒకే back end లో ఉంచండి. రెండింటిలోనూ ఉంచవద్దు.

తిరుగు మార్గంలో NAT ను రద్దు చేయడానికి రెండో rule అవసరమా?

అవసరం లేదు. Connection trackingలో connection యొక్క మొదటి packet nat rule కు సరిపోలినప్పుడు translation భద్రపరచబడుతుంది. తరువాత వచ్చే ప్రతి packet, రెండు దిశల్లోనూ, భద్రపరచిన entry ఆధారంగా తిరిగి రాయబడుతుంది. sudo conntrack -L ప్రతి connection కోసం రెండు tuples గా దీన్ని చూపిస్తుంది: మొదట original direction, తరువాత ఇప్పటికే reverse చేయబడిన reply. Return direction కోసం రాసిన rule ఉపయోగపడదు. ఎందుకంటే return packets nat chain వరకు ఎప్పుడూ చేరవు.

నేను ufw మరియు నా స్వంత nftables rules ను ఒకేసారి అమలు చేయవచ్చా?

అమలు చేయవచ్చు. కానీ దాంతో సమస్యను సృష్టించుకుంటారు. Hook పై ఉన్న ప్రతి base chain అమలవుతుంది. అందువల్ల live policy అనేది రెండు rulesets కలయికగా ఉంటుంది. వాటి క్రమం priority ఆధారంగా నిర్ణయించబడుతుంది. Priority సమానంగా ఉంటే ముందుగా ప్రారంభమైన service ఆధారంగా క్రమం నిర్ణయించబడుతుంది. వాటిలో ఏదో ఒకదానిలోని drop తుది నిర్ణయం అవుతుంది. మీ ruleset లోని accept ఉన్నా, మరొక ruleset అదే packet ను drop చేయకుండా ఆపదు. ఒకే tool ను ఎంచుకోండి. nftables ను ఎంచుకుంటే ముందుగా ufw ను disable చేయండి. తరువాత దాని tables sudo nft list ruleset నుంచి తొలగించబడ్డాయని నిర్ధారించండి.

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 ను మాత్రమే sudo nft -s list table inet filter తో dump చేయండి. పూర్తి list ruleset dump చేస్తే ufw మరియు Docker తమ కోసం నిర్వహించే tables కూడా అందులో చేరతాయి.

#nftables#iptables#firewall#nat#conntrack