SSD Nodes Learn
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-07-25

Docker UFW ని ఎందుకు దాటిపోతుంది మరియు ఎలా పరిష్కరించాలి

Docker iptables లో DNAT నియమాలు వ్రాసేటప్పుడు UFW నియమాలను దాటిపోతుంది, కాబట్టి deny చేసిన పోర్టు కూడా ఇంటర్నెట్‌కు స్పందిస్తుంది. యంత్రాంగం మరియు పనిచేసే పరిష్కారాలు ఇక్కడ ఉన్నాయి.

Docker UFW ని ఎందుకు దాటిపోతుంది

Docker UFW ని దాటిపోతుంది ఎందుకంటే ప్రచురించబడిన కంటైనర్ పోర్టులు UFW నిర్వహించే ఫైర్‌వాల్ నియమాల గుండా ఎప్పుడూ వెళ్ళవు. మీరు docker run -p 8080:80 ని అమలు చేసినప్పుడు, Docker కర్నల్ యొక్క nat పట్టికలోని PREROUTING చైన్‌లోకి ఒక DNAT (గమ్యస్థాన నెట్‌వర్క్ చిరునామా అనువాదం) నియమాన్ని వ్రాస్తుంది. కర్నల్ ప్యాకెట్ ఎక్కడికి వెళ్తుందో నిర్ణయించడానికి ముందు, ఆ నియమం ప్రతి ప్యాకెట్ యొక్క గమ్యస్థానాన్ని కంటైనర్ యొక్క ప్రైవేట్ చిరునామాకు మారుస్తుంది. మార్చబడిన ప్యాకెట్ తరువాత FORWARD చైన్ ద్వారా కంటైనర్‌లోకి ఫార్వార్డ్ చేయబడుతుంది, దీనిని Docker నియంత్రిస్తుంది. UFW యొక్క నియమాలు INPUT చైన్‌లో ఉంటాయి, మరియు ప్యాకెట్ అందులోకి ఎప్పుడూ ప్రవేశించదు. కాబట్టి ufw status డిఫాల్ట్ డినైని చూపుతుంది, sudo ufw deny 8080 విజయాన్ని నివేదిస్తుంది, మరియు పోర్ట్ 8080 ఇంకా మొత్తం ఇంటర్నెట్‌కు స్పందిస్తుంది.

ఇది Docker బగ్ కాదు, మరియు UFW పాడైపోలేదు. రెండు సాధనాలు ఒకే కర్నల్ ఫైర్‌వాల్‌ను ప్రోగ్రామ్ చేస్తాయి. Docker యొక్క నియమాలు ప్యాకెట్ మార్గంలో ముందుగా పనిచేస్తాయి, కాబట్టి UFW ను ఎప్పుడూ అడగబడదు. ఈ గైడ్ ఆ దాటిపోవడాన్ని ప్రదర్శిస్తుంది, యంత్రాంగాన్ని వివరిస్తుంది, మరియు పని చేసే రెండు పరిష్కారాలను కవర్ చేస్తుంది: 127.0.0.1 పై పోర్టులను ప్రచురించడం, మరియు DOCKER-USER చైన్‌లో ఫిల్టరింగ్ చేయడం. UFW మీకు కొత్తగా ఉంటే, దాన్ని ముందుగా UFW ఫైర్‌వాల్ ప్రాథమిక గైడ్ తో సెటప్ చేసుకోండి, ఎందుకంటే డిఫాల్ట్-డినై ఫైర్‌వాల్ సర్వర్‌లోని మిగతా ప్రతిదానికీ సరైన పునాదిగా ఉంటుంది.

మీ స్వంత సర్వర్‌లో బైపాస్‌ను చూడండి

ఇన్‌కమింగ్ ట్రాఫిక్ కోసం డిఫాల్ట్ డినై పాలసీతో UFW యాక్టివ్‌గా ఉన్న VPS నుండి ప్రారంభించండి. పబ్లిష్ చేసిన పోర్ట్‌తో ఒక వెబ్ కంటైనర్‌ను అమలు చేయండి:

sudo ufw status verbose
docker run -d --name web -p 8080:80 nginx:1.29-alpine

ufw status verbose అనేది Default: deny (incoming), allow (outgoing) ను చూపిస్తుంది, పోర్ట్ 8080 కోసం ఎలాంటి రూల్ ఉండదు. ఫైర్‌వాల్ నివేదిక ప్రకారం, ఆ పోర్ట్ మూసివేయబడింది. ఇప్పుడు సర్వర్ నుండి కాకుండా, వేరే మెషీన్ నుండి పరీక్షించండి:

curl -I http://your-vps-ip:8080/
HTTP/1.1 200 OK

కంటైనర్ స్పందిస్తుంది. స్పష్టమైన డినై రూల్‌ను జోడించి మళ్లీ పరీక్షించండి:

sudo ufw deny 8080/tcp

పోర్ట్ ఇప్పటికీ స్పందిస్తుంది, ఎందుకంటే డినై రూల్ అనేది ప్యాకెట్ ఎప్పటికీ సందర్శించని చైన్‌లో ఉంటుంది. UFW విఫలం కాలేదు. దాన్ని ఎప్పుడూ సంప్రదించలేదు. సమస్య ఇంత బాగా దాగి ఉండటానికి కారణం కూడా ఇదే: ఎక్కడా ఎలాంటి ఎర్రర్ ప్రింట్ కాదు, డిప్లాయ్ పనిచేస్తుంది, ఫైర్‌వాల్ స్టేటస్ అవుట్‌పుట్ కూడా ఆరోగ్యకరమైన లాక్‌డౌన్ సర్వర్ లాగానే కనిపిస్తుంది.

యంత్రాంగం: PREROUTING, INPUT కంటే ముందు నడుస్తుంది

కర్నల్ ఒక లోపలికి వచ్చే ప్యాకెట్‌ను ఒక నిర్దిష్ట క్రమంలో ప్రాసెస్ చేస్తుంది. మొత్తం సమస్య ఆ క్రమంలోనే ఉంది.

  1. PREROUTING ముందుగా నడుస్తుంది. ఇందులోని నియమాలు ప్యాకెట్ గమ్యస్థానాన్ని మార్చగలవు. ప్రచురించిన పోర్ట్ కోసం Docker నియమం సరిగ్గా అదే చేస్తుంది.
  2. తరువాత రూటింగ్ నిర్ణయం వస్తుంది. హోస్ట్‌కు పంపబడిన ప్యాకెట్ INPUT చైన్‌కు వెళ్తుంది. మరొక మెషీన్‌కు పంపబడిన ప్యాకెట్ FORWARD చైన్‌కు వెళ్తుంది.
  3. UFW నియమాలు INPUTలో ఉంటాయి. Docker నియమాలు FORWARDలో ఉంటాయి.

మీరు ఇప్పుడే ప్రారంభించిన కంటైనర్ కోసం Docker నియమాన్ని చూడండి:

sudo iptables -t nat -L DOCKER -n
Chain DOCKER (2 references)
target   prot opt source       destination
RETURN   0    --  0.0.0.0/0    0.0.0.0/0
DNAT     6    --  0.0.0.0/0    0.0.0.0/0    tcp dpt:8080 to:172.17.0.2:80

DNAT వరుస మొత్తం కథ. పోర్ట్ 8080 కోసం వచ్చే ఏ ప్యాకెట్ అయినా దాని గమ్యస్థానం 172.17.0.2:80కి మారుతుంది. అది Docker ప్రైవేట్ బ్రిడ్జ్ నెట్‌వర్క్‌లో కంటైనర్ చిరునామా. మార్పు తరువాత ప్యాకెట్ ఇక హోస్ట్‌కు పంపబడదు. కాబట్టి రూటింగ్ నిర్ణయం దానిని FORWARD మార్గంలో పంపుతుంది. అక్కడ Docker తన స్వంత నెట్‌వర్క్‌లలోకి ట్రాఫిక్‌ను అంగీకరించే నియమాలను ఇప్పటికే జోడించింది. మీ deny 8080/tcp నియమం INPUTలో ఎప్పటికీ రాని ప్యాకెట్ కోసం వేచి ఉంటుంది.

Ubuntu 24.04లో iptables కమాండ్ nftables పై ఒక ఫ్రంట్ ఎండ్. కానీ చైన్ క్రమం మరియు ఫలితం ఒకేలా ఉంటాయి. UFW మరియు Docker రెండూ ఒకే కర్నల్ ప్యాకెట్ పైప్‌లైన్‌లో రాస్తాయి. Docker ఎంట్రీ పాయింట్ ముందుగా ఉంటుంది.

రోజువారీ పరిష్కారం: పోర్టులను 127.0.0.1 పై ప్రచురించండి

చాలా కంటైనర్‌లకు ఎప్పుడూ పబ్లిక్‌గా ఉండాల్సిన అవసరం లేదు. డేటాబేస్, రివర్స్ ప్రాక్సీ వెనుక ఉన్న యాప్ సర్వర్, అడ్మిన్ ప్యానెల్, మెట్రిక్స్ ఎండ్‌పాయింట్: ఇవేవీ నేరుగా ఇంటర్నెట్‌కు స్పందించకూడదు. వాటిని లూప్‌బ్యాక్ చిరునామాపై ప్రచురించండి:

docker run -d --name web -p 127.0.0.1:8080:80 nginx:1.29-alpine

లేదా కంపోజ్ ఫైల్‌లో:

services:
  web:
    image: nginx:1.29-alpine
    ports:
      - "127.0.0.1:8080:80"

ఇది పనిచేస్తుంది ఎందుకంటే Docker యొక్క DNAT నియమం ఇప్పుడు 127.0.0.1కి పంపబడిన ప్యాకెట్‌లను మాత్రమే సరిపోలుస్తుంది. ఇంటర్నెట్ నుండి వచ్చే ప్యాకెట్ ఆ గమ్యస్థానాన్ని ఎప్పుడూ ధృవీకరించబడినట్లు కలిగి ఉండదు, కాబట్టి కర్నల్ ఏ ఫైర్‌వాల్ నియమం నడిచేక ముందే దాన్ని డ్రాప్ చేస్తుంది. ఆ పోర్టు హోస్ట్ నుండి చేరుకోవచ్చు, మరేదేని నుండి కాదు. బైండింగ్‌ను ధృవీకరించండి:

sudo ss -tlnp | grep 8080

అవుట్‌పుట్‌లో మీకు 127.0.0.1:8080 కావాలి, 0.0.0.0:8080 లేదా [::]:8080 కాదు. తర్వాత మరొక మెషీన్ నుండి curl http://your-vps-ip:8080/ తిరస్కరించబడిందని నిర్ధారించుకోండి.

ఇంటర్నెట్‌ను ఎదుర్కోవాల్సిన సర్వీసుల కోసం, పోర్టులు 80 మరియు 443ను కలిగి ఉండి హోస్ట్‌నేమ్ ద్వారా రూట్ చేసే ఒక రివర్స్ ప్రాక్సీని నడపండి, మరేవేటినీ ప్రచురించకండి. అదే Traefik రివర్స్ ప్రాక్సీ గైడ్ రూపొందించే ప్యాటర్న్, మరియు అదే విధంగా VPSలో Nextcloud వంటి సెల్ఫ్-హోస్టెడ్ యాప్ దాని ప్రాక్సీ ద్వారా మాత్రమే చేరుకోగలిగేలా ఉంటుంది. ports: ఎంట్రీలు ఎలా ప్రకటించబడతాయో, మరియు కంపోజ్ వర్క్‌ఫ్లో మిగిలిన భాగం Docker Compose ప్రాథమిక గైడ్లో వివరించబడింది.

ప్రతి అంతర్గత కంటైనర్ లూప్‌బ్యాక్‌లో ఉండటంతో, UFW దాని సాధారణ పనిని మళ్లీ చేస్తుంది: హోస్ట్ స్వయంగా సర్వ్ చేసే పోర్టులను కాపాడటం. ఆ నియమ సమితిని ఇక్కడ రూపొందించండి, తర్వాత ఆదేశాలను క్రమంలో నడపండి:

ToolUFW rule generator

నిజమైన ఫిల్టరింగ్: DOCKER-USER చైన్

కొన్నిసార్లు ఒక కంటైనర్ పోర్ట్ నెట్‌వర్క్‌కు ప్రచురితంగానే ఉండాలి, కానీ అదనపు నియంత్రణ అవసరం. ఉదాహరణకు, ఒక డేటాబేస్ రెప్లికా పోర్ట్‌ను ఒకే ఒక ఆఫీసు చిరునామా చేరుకోగలగాలి. దీని కోసం Docker DOCKER-USER చైన్‌ను అందిస్తుంది. ఏ కంటైనర్‌వైపు వెళ్లే ప్రతి ప్యాకెట్ Docker స్వంత అనుమతి నియమాల కంటే ముందు DOCKER-USER గుండా వెళుతుంది. Docker ఈ చైన్‌లోకి ఎప్పుడూ నియమాలు రాదు. ఈ చైన్ మీ వినియోగానికి మాత్రమే ఉంటుంది. డెమాన్ రీస్టార్ట్‌ల సమయంలో Docker దాని విషయాలను మార్చదు.

ఆదేశానికి ముందు ఒక చిక్కు ఉంది. ఒక ప్యాకెట్ DOCKER-USER చేరుకునే సమయానికి, DNAT రాత ఇప్పటికే జరిగి ఉంటుంది. ప్యాకెట్ గమ్యపు పోర్ట్ కంటైనర్ పోర్ట్ (మా ఉదాహరణలో 80) అవుతుంది, ప్రచురిత పోర్ట్ (8080) కాదు. కాబట్టి --dport 8080 పోలికతో కూడిన నియమం ఏదీ పని చేయదు. విశ్వసనీయమైన మార్గం క్లయింట్ మొదట డయల్ చేసిన పోర్ట్‌తో పోల్చడం. దీన్ని కెర్నల్ కనెక్షన్ ట్రాకర్ గుర్తుంచుకుంటుంది:

sudo iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 8080 --ctdir ORIGINAL ! -s 10.0.0.10 -j DROP

దీన్ని ఇలా చదవండి: eth0 ద్వారా ప్రవేశించిన మరియు వాటి అసలు గమ్యపు పోర్ట్ 8080 అయిన కనెక్షన్‌కు చెందిన ప్యాకెట్‌ల కోసం, 10.0.0.10 నుండి పంపని ప్రతిదాన్ని కొట్టివేయండి. --ctdir ORIGINAL పోలిక ఈ నియమాన్ని క్లయింట్-నుండి-కంటైనర్ దిశకు పరిమితం చేస్తుంది. దీనివల్ల ప్రత్యుత్తర ప్యాకెట్‌లు పొరపాటున కొట్టివేయబడవు. eth0 స్థానంలో మీ పబ్లిక్ ఇంటర్‌ఫేస్‌ను ఉంచండి; ip route | grep default దానిని పేర్కొంటుంది. ఇంతకుముందు వలె దీన్ని పరీక్షించండి: అనుమతి ఉన్న చిరునామా నుండి curl విజయవంతం అవుతుంది, మరియు వేరే ఎక్కడి నుండి అయితే కనెక్షన్ సమయం ముగుస్తుంది.

iptables ఆదేశంతో జోడించిన నియమాలు రీబూట్ సమయంలో కనుమరుగవుతాయి. UFW ఇప్పటికే ఈ ఫైర్‌వాల్‌ను నిర్వహిస్తున్నందున, వాటిని నిలుపుదలతో ఉంచడానికి సరైన స్థలం /etc/ufw/after.rules. ఫైల్ చివరలో ఒక బ్లాక్‌ను జోడించండి:

*filter
:DOCKER-USER - [0:0]
-A DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 8080 --ctdir ORIGINAL ! -s 10.0.0.10 -j DROP
COMMIT

తర్వాత sudo ufw reload అమలు చేయండి. UFW ప్రతి రీలోడ్ మరియు ప్రతి బూట్‌పై ఆ ఫైల్‌ను మళ్లీ ప్లే చేస్తుంది. కాబట్టి మీ కంటైనర్ ఫిల్టరింగ్ ఇప్పుడు మీ ఫైర్‌వాల్‌లోని మిగతా నియమాలతో పాటు అదే స్థలంలో ఉంటుంది. ఇది రీబూట్ మరియు Docker అప్‌గ్రేడ్ రెండింటినీ తట్టుకుని నిలుస్తుంది.

Docker యొక్క iptables ఇంటిగ్రేషన్‌ను మీరు ఎందుకు డిసేబు చేయకూడదు

ఈ సమస్యకు పాత సమాధానాలు /etc/docker/daemon.json లో { "iptables": false } ను సెట్ చేయమని సూచిస్తాయి. అలా చేయవద్దు. Docker యొక్క ఫైర్‌వాల్ నియమాలు పోర్టులను పబ్లిష్ చేయడం కంటే చాలా ఎక్కువ చేస్తాయి. మాస్క్వెరేడ్ నియమం హోస్ట్ చిరునామా ద్వారా కంటైనర్‌లకు అవుట్‌బౌండ్ ఇంటర్నెట్ యాక్సెస్‌ను అందిస్తుంది. కాబట్టి ఇంటిగ్రేషన్ ఆఫ్ చేసినట్లయితే, కంటైనర్‌లు ఇమేజ్‌లను పుల్ చేయలేవు, ప్యాకేజ్ మిర్రర్‌లను చేరుకోలేవు లేదా ఏదైనా బాహ్య API (అప్లికేషన్ ప్రోగ్రామింగ్ ఇంటర్‌ఫేస్) ని కాల్ చేయలేవు. DNAT నియమాలు -p ను అసలు పని చేయడానికి కారణం. కాబట్టి పబ్లిష్ చేసిన పోర్టులు పూర్తిగా పని చేయడం మానేస్తాయి. వేర్వేరు Compose నెట్‌వర్క్‌లను వేరుగా ఉంచే ఐసోలేషన్ నియమాలు కూడా పోతాయి. మీరు కంటైనర్ నెట్‌వర్కింగ్‌ను విచ్ఛిన్నం చేయడం ద్వారా బైపాస్‌ను పరిష్కరిస్తారు. ఆ ప్రతి నియమాన్ని మీరు మీరే స్వయంగా రాసి నిర్వహించాల్సి వస్తుంది. Docker యొక్క స్వంత డాక్యుమెంటేషన్ ఈ సెట్టింగ్‌ను అలా చేయాలనుకునే వ్యక్తుల కోసం అని వివరిస్తుంది. ఎవరికీ ఈ స్విచ్ అవసరం లేదని నిర్ధారించడానికే DOCKER-USER చైన్ ఉంది.

అదే సమస్య యొక్క IPv6 వైపు

ముందుగా ప్రచురించిన పోర్ట్ IPv6లో ఎలా కనిపిస్తుందో తనిఖీ చేయండి:

sudo ss -tlnp | grep 8080

Docker Engine 27 నుండి, Docker అప్రమేయంగా ip6tablesను నిర్వహిస్తుంది. IPv6 ప్రారంభించబడిన Docker నెట్‌వర్క్‌లో, ప్రచురించిన పోర్ట్ IPv6 పట్టికలలో కూడా అదే DNAT ప్రక్రియను పొందుతుంది. కాబట్టి అక్కడ కూడా అదే బైపాస్ ఉంటుంది మరియు అదే పరిష్కారం వర్తిస్తుంది: DOCKER-USER చైన్ ip6tablesలో కూడా ఉంటుంది. కాబట్టి మీ నియమాన్ని sudo ip6tables -I DOCKER-USER ...తో ప్రతిబింబింపజేయండి మరియు మీ సర్వర్ యొక్క పబ్లిక్ IPv6 చిరునామాకు వెలుపల నుండి curlతో పరీక్షించండి, ఉదాహరణకు curl -6 http://[2001:db8:2a::1]:8080/.

IPv6 లేని నెట్‌వర్క్‌లో, IPv6 క్లయింట్‌లను బదులుగా docker-proxy నిర్వహిస్తుంది. ఇది ఒక సాధారణ యూజర్-స్పేస్ ప్రక్రియ. అది [::]:8080లో వింటుంది మరియు ట్రాఫిక్‌ను IPv4 ద్వారా కంటైనర్‌లోకి ఫార్వర్డ్ చేస్తుంది. హోస్ట్ ప్రక్రియకు వెళ్ళే ట్రాఫిక్ INPUT ద్వారా వెళుతుంది. కాబట్టి UFW ఆ మార్గాన్ని ఫిల్టర్ చేయగలదు, కానీ UFW పూర్తిగా IPv6ను నిర్వహిస్తున్నప్పుడు మాత్రమే. అది నిర్వహిస్తుందా, మరియు VPSలో IPv6 అంతరం తెరుచుకునే ఇతర మార్గాలు, UFW మరియు IPv6 గైడ్ యొక్క విషయం.

లూప్‌బ్యాక్‌పై ప్రచురించడం మొత్తం ప్రశ్నను నివారిస్తుంది: -p 127.0.0.1:8080:80 IPv4 లూప్‌బ్యాక్‌ను మాత్రమే బంధిస్తుంది. కాబట్టి అక్కడ IPv6 లిసనర్ లేదు మరియు రెండు స్టాక్‌లలో ఎదుటి నుండి చేరుకోవడానికి ఏమీ లేదు.

నిలబడే నమూనా

  • ప్రతి అంతర్గత పోర్టును 127.0.0.1 పై ప్రచురించండి, తద్వారా అది మొదటి స్థలంలోనే బహిర్గతం కాదు.
  • పోర్టులు 80 మరియు 443 ను కలిగి ఉన్న ఒక రివర్స్ ప్రాక్సీకి పబ్లిక్ వైపును అప్పగించండి.
  • హోస్ట్ కోసం UFW డిఫాల్ట్ డినైని ఉంచండి, SSH మరియు ప్రాక్సీ పోర్టులను అనుమతించండి.
  • నిజంగా పబ్లిక్ అయిన కంటైనర్ పోర్టులను DOCKER-USER లో ఫిల్టర్ చేయండి, అసలు గమ్యపు పోర్టుతో సరిపోల్చి, /etc/ufw/after.rules లో నిల్వ చేయండి.
  • Docker యొక్క iptables ఇంటిగ్రేషన్‌ను ఆన్‌లోనే ఉంచండి.

ఒకసారి సెటప్ చేస్తే, ఇది ఆశ్చర్యాన్ని తొలగిస్తుంది: ufw status హోస్ట్‌ను వివరిస్తుంది, మరియు DOCKER-USER కంటైనర్‌లను వివరిస్తుంది. ప్రమాదవశాత్తూ ఏదీ ప్రచురించబడదు, మరియు మీరు టైప్ చేసే తదుపరి docker run -p మీరు అనుకున్న దానిని ఖచ్చితంగా బహిర్గతం చేస్తుంది.

FAQ

UFW పోర్టును అడ్డుకున్నప్పుటికీ, నా Docker కంటైనర్‌ను నేను ఎందుకు చేరుకోగలను?

ఎందుకంటే Docker ఆ పోర్టును PREROUTING చైన్‌లో ఒక DNAT నియమంతో ప్రచురిస్తుంది. ఈ నియమం ఏ ఫిల్టరింగ్ జరగక ముందే ప్యాకెట్ గమ్యస్థానాన్ని కంటైనర్ చిరునామాకు మారుస్తుంది. ఆ తర్వాత ప్యాకెట్ FORWARD మార్గంలో వెళుతుంది. UFW నియమాలు INPUT‌లో ఉంటాయి. ఆ చైన్‌లోకి ప్యాకెట్ ఎప్పుడూ ప్రవేశించదు. ఫైర్‌వాల్ ఎప్పుడూ పరిశీలించబడదు. కాబట్టి, ప్రచురిత కంటైనర్ పోర్టులపై దాని నిరాకరణ నియమాలకు ఎలాంటి ప్రభావం ఉండదు.

Docker ప్రచురిత పోర్టులను UFW అడ్డుకునేలా ఎలా చేస్తాను?

UFW స్వయంగా చేయలేదు, ఎందుకంటే దాని నియమాలు తప్పు చైన్‌లో ఉన్నాయి. లేదా పోర్టును బహిర్గతం చేయడం ఆపండి. దాన్ని 127.0.0.1:8080:80‌గా ప్రచురించండి, అప్పుడు హోస్ట్ మాత్రమే దాన్ని చేరుకోగలుగుతుంది. లేదా conntrack ద్వారా వాస్తవ గమ్యస్థాన పోర్టుతో సరిపోలే iptables నియమంతో DOCKER-USER చైన్‌లో ఫిల్టర్ చేయండి. ఆ నియమాన్ని /etc/ufw/after.rules‌లో నిల్వ ఉంచండి. అప్పుడు అది రీబూట్‌లు మరియు ufw reload తట్టుకుని నిలుస్తుంది.

Docker యొక్క daemon.json లో "iptables": false అని అమర్చాలా?

లేదు. ఆ సెట్టింగ్ Docker యొక్క అన్ని ఫైర్‌వాల్ మరియు NAT నియమాలను తొలగిస్తుంది. ఇది బైపాస్‌కన్నా చాలా ఎక్కువగా పనిచేయకుండా చేస్తుంది. మాస్క్వెరేడ్ నియమం పోవడం వల్ల కంటైనర్‌లు అవుట్‌బౌండ్ ఇంటర్నెట్ ప్రాప్యతను కోల్పోతాయి. DNAT నియమాలు పోవడం వల్ల ప్రచురిత పోర్టులు పనిచేయడం ఆగిపోతాయి. దానికి బదులుగా లూప్‌బ్యాక్ ప్రచురణ మరియు DOCKER-USER చైన్‌ను ఉపయోగించండి. అవి కంటైనర్ నెట్‌వర్కింగ్‌ను పాడుచేయకుండా బహిర్గత సమస్యను పరిష్కరిస్తాయి.

Docker అనామకంగా IPv6 లో కూడా UFW ను దాటుతుందా?

Docker Engine 27 మరియు తరువాత సంస్కరణలలో, ip6tables నిర్వహణ స్థిరంగా ఉంటుంది. కాబట్టి, IPv6-ప్రాప్తి Docker నెట్‌వర్క్‌లో ప్రచురించబడిన పోర్టు, IPv4 లో జరిగినట్లే UFW చుట్టూ తిరిగి మళ్లించబడుతుంది. దానికి ip6tables‌తో ప్రతిబింబించే అదే DOCKER-USER నియమం అవసరం. IPv6 లేని నెట్‌వర్క్‌లలో, docker-proxy ప్రక్రియ [::]‌లో వింటుంది. ఆ ట్రాఫిక్ INPUT గుండా వెళుతుంది. UFW IPv6 ని నిర్వహిస్తే, అక్కడ UFW దాన్ని ఫిల్టర్ చేయగలదు. 127.0.0.1‌లో ప్రచురించడం రెండు సందర్భాలనూ నివారిస్తుంది, ఎందుకంటే IPv6 లో ఏదీ వినదు.

#docker#ufw#firewall#iptables#security#networking