Docker UFW-ஐ தவிர்க்கிறது: ஏன் மற்றும் எப்படி சரிசெய்வது

Docker ஏன் UFW-ஐ தவிர்க்கிறது

Docker ஆனது UFW-ஐ தவிர்க்கிறது, ஏனெனில் வெளியிடப்பட்ட container போர்ட்கள் UFW நிர்வகிக்கும் firewall விதிகள் வழியாக ஒருபோதும் செல்வதில்லை. நீங்கள் docker run -p 8080:80 ஐ இயக்கும்போது, Docker ஆனது kernel-ன் nat அட்டவணையில் உள்ள PREROUTING சங்கிலியில் ஒரு DNAT (destination network address translation) விதியை எழுதுகிறது. அந்த விதி, kernel பாக்கெட் எங்கே செல்கிறது என்று தீர்மானிப்பதற்கு முன்பாக, ஒவ்வொரு பாக்கெட்டின் இலக்கையும் container-ன் தனியார் முகவரியாக மாற்றியமைக்கிறது. மாற்றியமைக்கப்பட்ட பாக்கெட் பின்னர் Docker கட்டுப்படுத்தும் FORWARD சங்கிலி வழியாக container-க்குள் அனுப்பப்படுகிறது. UFW-ன் விதிகள் INPUT சங்கிலியில் இருக்கின்றன, மேலும் பாக்கெட் அதில் ஒருபோதும் நுழைவதில்லை. எனவே ufw status இயல்புநிலை deny-ஐ காட்டுகிறது, sudo ufw deny 8080 வெற்றியைத் தெரிவிக்கிறது, மேலும் port 8080 இன்னும் முழு இணையத்திற்கும் பதிலளிக்கிறது.

இது Docker பிழை அல்ல, மேலும் UFW உடைந்ததும் அல்ல. இரண்டு கருவிகளும் ஒரே kernel firewall-ஐ நிரல்படுத்துகின்றன. Docker-ன் விதிகள் வெறுமனே பாக்கெட்டின் பாதையில் ஒரு ஆரம்ப கட்டத்தில் செயல்படுகின்றன, எனவே UFW ஒருபோதும் கேட்கப்படுவதில்லை. இந்த வழிகாட்டி இந்த தவிர்ப்பை நிரூபிக்கிறது, பொறிமுறையை விளக்குகிறது, மேலும் பணியாகும் இரண்டு தீர்வுகளையும் உள்ளடக்கியது: 127.0.0.1 இல் போர்ட்களை வெளியிடுவது, மற்றும் DOCKER-USER சங்கிலியில் வடிகட்டுவது. UFW உங்களுக்கு புதியதாக இருந்தால், அதை முதலில் UFW firewall அடிப்படைகள் வழிகாட்டி உடன் அமைக்கவும், ஏனெனில் இயல்புநிலை-deny firewall என்பது சேவையகத்தில் மற்ற அனைத்திற்கும் சரியான அடித்தளமாக இருக்கிறது.

உங்கள் சொந்த சேவையகத்தில் இந்தத் தவிர்ப்பைக் காண்க

உள்வரும் போக்குவரத்திற்கான இயல்புநிலை deny policy உடன் UFW செயலில் இருக்கும் ஒரு VPS-இல் தொடங்கவும். வெளியிடப்பட்ட port உடன் ஒரு web container-ஐ இயக்கவும்:

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

ufw status verbose என்பது Default: deny (incoming), allow (outgoing)-ஐக் காட்டுகிறது; port 8080-ற்கான விதி எதுவும் இல்லை. firewall-ன் சொந்த அறிக்கையின்படி, இந்த port மூடப்பட்டிருக்கிறது. இப்போது வேறொரு இயந்திரத்திலிருந்து சோதிக்கவும்; சேவையகத்திலிருந்து அல்ல:

curl -I http://your-vps-ip:8080/

HTTP/1.1 200 OK

container பதிலளிக்கிறது. ஒரு வெளிப்படையான deny விதியைச் சேர்த்து மீண்டும் சோதிக்கவும்:

sudo ufw deny 8080/tcp

port இன்னும் பதிலளிக்கிறது, ஏனெனில் deny விதி ஒரு chain-ல் இருக்கிறது; அந்தப் பாக்கெட் அங்கே செல்வதே இல்லை. UFW தோல்வியடையவில்லை. அது இதில் எப்போதும் அணுகப்பட்டதே இல்லை. இந்தப் பிரச்சினை இவ்வளவு நன்றாக மறைந்திருப்பதற்கும் இதுவே காரணம்: எங்கும் எந்தப் பிழையும் அச்சிடப்படவில்லை, deploy வேலை செய்கிறது, மேலும் firewall status வெளியீடு ஆரோக்கியமான பூட்டப்பட்ட சேவையகத்தைப் போலவே தெரிகிறது.

இயங்குமுறை: 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

அல்லது ஒரு Compose கோப்பில்:

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: என்ட்ரிகள் எப்படி டிக்ளேர் செய்யப்படுகின்றன, மீதமுள்ள Compose வொர்க்ஃப்ளோ பற்றி Docker Compose அடிப்படை வழிகாட்டி-இல் விளக்கப்பட்டுள்ளது.

ஒவ்வொரு உள்நாட்டு கன்டெய்னரும் லூப்பேக்கில் இருப்பதால், UFW தனது இயல்பான வேலையை மீண்டும் செய்கிறது: ஹோஸ்ட் தானே சர்வ் செய்யும் போர்ட்களை பாதுகாப்பது. அந்த விதி தொகுப்பை இங்கே உருவாக்கவும், பிறகு கட்டளைகளை வரிசையாக இயக்கவும்:

உண்மையான வடிகட்டல்: 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-இன் firewall விதிகள் port-களை வெளியிடுவதை விட மேலும் பல காரியங்களைச் செய்கின்றன. masquerade விதி என்பது container-களுக்கு host-இன் முகவரி வழியாக வெளிச்சேவையக இணைய அணுகலை வழங்குகிறது. எனவே, ஒருங்கிணைப்பு முடக்கப்பட்டிருந்தால், container-களால் image-களை எடுக்கவோ, package mirror-களை அணுகவோ, எந்த ஒரு புற API (application programming interface)-ஐயும் அழைக்கவோ முடியாது. DNAT விதிகளே -p ஐ இயங்கச் செய்கின்றன. எனவே, வெளியிடப்பட்ட port-கள் முற்றிலும் இயங்காது. தனித்தனி Compose network-களைப் பிரித்து வைக்கும் தனிமைப்படுத்தல் விதிகளும் நீக்கப்படும். container இணைப்பியலை உடைத்து தவிர்ப்புப் பாதையை நீங்கள் சரிசெய்திருப்பீர்கள். அந்த ஒவ்வொரு விதியையும் நீங்களாகவே எழுதி பராமரிக்க வேண்டும். Docker-இன் சொந்த ஆவணங்கள் இந்த அமைப்பை அதைத் தான் செய்ய விரும்புபவர்களுக்கானது என விவரிக்கின்றன. யாருக்கும் இந்த switch தேவையில்லை என்பதற்காகத் தான் DOCKER-USER chain உள்ளது.

இதே பிரச்சினையின் 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 ஆல் கையாளப்படுகிறார்கள். இது ஒரு சாதாரண user-space செயல்முறை. இது [::]:8080-இல் கேட்கிறது. போக்குவரத்தை IPv4 வழியாக கொள்கலனுக்குள் அனுப்புகிறது. புரவல செயல்முறைக்கான போக்குவரத்து INPUT வழியாகத்தான் செல்கிறது. எனவே UFW அந்தப் பாதையை வடிகட்ட முடியும். ஆனால் UFW IPv6-ஐ நிர்வகிக்கும்போது மட்டுமே. UFW அப்படி செய்கிறதா, மேலும் ஒரு VPS-இல் IPv6 இடைவெளி திறக்கும் மற்ற வழிகள் எவை என்பது UFW மற்றும் IPv6 வழிகாட்டி என்பதன் தலைப்பு.

loopback-இல் வெளியிடுவது இந்த முழு கேள்வியையும் தவிர்க்கிறது: -p 127.0.0.1:8080:80 IPv4 loopback-ஐ மட்டுமே பிணைக்கிறது. எனவே IPv6 கேட்பவர் யாரும் இல்லை. இரு ஸ்டாக்குகளிலும் வெளியிலிருந்து அடைய எதுவும் இல்லை.

நிலைத்து நிற்கும் அமைப்பு

• ஒவ்வொரு உள் போர்ட்டையும் 127.0.0.1 இல் வெளியிடு. அப்படியானால் அது ஆரம்பத்திலேயே வெளிப்படாது.
• போர்ட் 80 மற்றும் 443 ஐ கட்டுப்படுத்தும் ஒரு reverse proxy க்கு பொதுப் பக்கத்தை ஒப்படை.
• ஹோஸ்ட்டிற்கான UFW இயல்புநிலை deny ஐ தக்கவை. SSH மற்றும் proxy போர்ட்களை மட்டும் அனுமதி.
• உண்மையில் பொதுவான container போர்ட்களை DOCKER-USER இல் வடிகட்டு. இது அசல் இலக்கு போர்ட்டுடன் பொருத்தப்பட்டு, /etc/ufw/after.rules இல் நிலைப்படுத்தப்படுகிறது.
• Docker இன் iptables ஒருங்கிணைப்பை இயக்கத்திலேயே விட்டுவை.

ஒருமுறை அமைத்தால், இது ஆச்சரியத்தை நீக்குகிறது: ufw status ஹோஸ்ட்டை விவரிக்கிறது, மற்றும் DOCKER-USER containerகளை விவரிக்கிறது. எதுவும் தற்செயலாக வெளியிடப்படாது. நீங்கள் அடுத்து தட்டச்சு செய்யும் 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 செயினில் வடிகட்டுங்கள். மறுதொடக்கங்கள் மற்றும் ufw reload ஆகியவற்றின்போது அந்த விதி நீடித்திருக்க, அதை /etc/ufw/after.rules இல் நிலைநிறுத்துங்கள்.

Docker-இன் daemon.json கோப்பில் "iptables": false என அமைக்க வேண்டுமா?

இல்லை. அந்த அமைப்பு, Docker-இன் அனைத்து ஃபயர்வால் மற்றும் NAT விதிகளையும் நீக்கிவிடுகிறது. இது பைபாஸ் சிக்கலை விட மிக அதிகமான இடையூறுகளை ஏற்படுத்துகிறது. masquerade விதி அகற்றப்படுவதால், கொள்கலன்கள் வெளிச்செல்லும் இணைய அணுகலை இழக்கின்றன. DNAT விதிகள் அகற்றப்படுவதால், வெளியிடப்பட்ட போர்ட்டுகள் செயல்படுவதை நிறுத்துகின்றன. அதற்குப் பதிலாக loopback வெளியீடு மற்றும் DOCKER-USER செயின் ஆகியவற்றைப் பயன்படுத்துங்கள்; இவை கொள்கலன் நெட்வொர்க்கிங்கைப் பழுதடையாமல் வெளிப்பாட்டுப் பிரச்சினையைச் சரிசெய்கின்றன.

IPv6 இலும் Docker ஆனது UFW-ஐத் தவிர்க்கிறதா?

Docker Engine 27 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், ip6tables மேலாண்மை இயல்பாகவே இயக்கத்தில் உள்ளது. எனவே, IPv6 இயக்கப்பட்ட Docker நெட்வொர்க்கில் வெளியிடப்பட்ட ஒரு போர்ட், IPv4 இல் நிகழ்வதைப் போலவே UFW-ஐத் தவிர்த்து மாற்றியமைக்கப்படுகிறது. இதற்கும் அதே DOCKER-USER விதி, ip6tables உடன் இணைக்கப்பட வேண்டும். IPv6 இல்லாத நெட்வொர்க்குகளில், docker-proxy செயல்முறையானது [::] இல் கேட்கிறது; அந்தப் போக்குவரத்து INPUT வழியாகச் செல்கிறது. UFW ஆனது IPv6-ஐ நிர்வகித்தால், அங்கு அது இதை வடிகட்ட முடியும். 127.0.0.1 இல் வெளியிடுவது இரண்டு நிலைகளையும் தவிர்க்கிறது, ஏனெனில் IPv6 இல் எதுவுமே கேட்பதில்லை.