Docker Compose நெட்வொர்க்கிங் செயல்படும் விதம்

உங்கள் செயலி தொடங்குவதற்கு முன் Docker Compose உருவாக்கும் கட்டமைப்புகள்

Docker Compose நெட்வொர்க்கிங் ஒரு விதியுடன் தொடங்குகிறது: docker compose up அந்தத் திட்டத்திற்காக ஒரு பிரத்யேக நெட்வொர்க்கை உருவாக்கி, ஒவ்வொரு சேவையையும் அதனுடன் இணைத்து, அந்தச் சேவைகள் ஒன்றையொன்று சேவைப் பெயரின் மூலம் தொடர்பு கொள்ள அனுமதிக்கிறது. இதைப் பெறுவதற்கு நீங்கள் ஒரு networks: வரியைக் கூட எழுத வேண்டியதில்லை. Compose நெட்வொர்க்கிங் குறித்த பெரும்பாலான குழப்பங்கள், இந்த இயல்புநிலை அமைப்பு ஏற்கனவே உள்ளது என்பதை அறியாததால் ஏற்படுகின்றன.

இதோ ஒரு சிறிய கோப்பு. இதை shop என்ற கோப்பகத்தில் compose.yaml என்ற பெயரில் சேமிக்கவும்.

services:
  web:
    image: nginx:1.27
    ports:
      - "8080:80"
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example

இதை இயக்கி, Docker உருவாக்கியுள்ளதைப் பார்க்கவும்:

docker compose up -d
docker network ls

இப்போது பட்டியலில் shop_default என்ற நெட்வொர்க் உள்ளது. Compose இதற்கு <project>_default என்று பெயரிடுகிறது, மேலும் திட்டத்தின் பெயர் இயல்பாகவே கோப்பகத்தின் சிறிய எழுத்துக்களாக (lowercase) அமைகிறது. இதை docker compose -p myproject up -d மூலமாகவோ அல்லது கோப்பில் உள்ள உயர்மட்ட name: myproject மூலமாகவோ மாற்றியமைக்கலாம். இதன் டிரைவர் bridge ஆகும், இது ஹோஸ்டுக்குள் இருக்கும் ஒரு மெய்நிகர் சுவிட்ச் (virtual switch) ஆகும். ஒவ்வொரு கன்டெய்னரும் ஒரு பிரத்யேக சப்நெட்டில் முகவரியைப் பெறுகிறது, மேலும் வெளிச்செல்லும் டிராஃபிக் (outbound traffic) வெளியேறும்போது ஹோஸ்டின் முகவரிக்கு மாற்றப்படுகிறது (translated).

docker compose down அந்த நெட்வொர்க்கை மீண்டும் நீக்குகிறது. பழைய திட்டத்திலிருந்து எஞ்சியிருக்கும் ஒரு கன்டெய்னர் நெட்வொர்க்கைத் திறந்து வைத்திருப்பதால்தான் இது நிகழ்கிறது: Docker error while removing network: network shop_default has active endpoints என்ற பிழையைக் காட்டி மறுத்துவிடும், அதனுடன் இணைக்கப்பட்டுள்ள கன்டெய்னரை நிறுத்துவது அல்லது நீக்குவதே இதற்கான தீர்வாகும்.

நீங்கள் Compose-க்கு புதியவர் என்றால், Compose கோப்பு அமைப்பு மற்றும் வாழ்க்கைச் சுழற்சி கட்டளைகள் என்பதை முதலில் படிப்பது நல்லது, ஏனெனில் கீழே உள்ள அனைத்தும் ஒரு திட்டத்தைத் தொடங்கவும் நிறுத்தவும் உங்களுக்குத் தெரியும் என்ற அடிப்படையில் விளக்கப்பட்டுள்ளன.

DNS service name என்பது ஆரம்ப நிலையில் உள்ளவர்கள் தவறவிடும் ஒரு முக்கிய அம்சம்

பயனர் வரையறுத்த எந்தவொரு network-லும், Docker ஒரு embedded DNS server-ஐ இயக்குகிறது. ஒவ்வொரு container-ம் இதை 127.0.0.11 முகவரியில் காணும். இது service பெயர்களை தற்போதைய container முகவரிகளாக மாற்றுகிறது. எனவே, web ஆனது db என்ற hostname-ல், 5432 என்ற port-ல் எந்தவித கூடுதல் configuration-ம் இன்றி database-ஐ அடைகிறது.

docker compose exec web getent hosts db

இது 172.18.0.2 db போன்ற ஒரு வரியை வெளியிடும். இது எதையும் காட்டவில்லை என்றால், அந்த இரண்டு service-களும் ஒரே network-ல் இல்லை என்று அர்த்தம்.

அனைவரும் ஒருமுறை செய்யும் பொதுவான தவறு, application configuration-ல் localhost-ஐப் பயன்படுத்துவதுதான். ஒரு container-க்குள், localhost என்பது அந்த குறிப்பிட்ட container-ஐ மட்டுமே குறிக்கும்; அது host-ஐயோ அல்லது மற்றொரு service-ஐயோ குறிக்காது. Postgres clients இதைத் தெளிவாகக் குறிப்பிடுகின்றன:

could not connect to server: Connection refused
	Is the server running on host "localhost" (127.0.0.1) and accepting
	TCP connections on port 5432?

Connection string என்பது postgresql://postgres:example@db:5432/postgres என்று இருக்க வேண்டும். இதில் host பகுதி என்பது service-ன் பெயராகும்.

பிற்காலத்தில் நேரத்தை மிச்சப்படுத்தும் இரண்டு விவரங்கள் இங்கே உள்ளன. பெயர்கள் தற்போது இயங்கிக்கொண்டிருக்கும் எதனுடனும் இணையும், எனவே docker compose up -d --scale web=3 என்பது மூன்று முகவரிகளைக் கொண்ட ஒரு பெயரை வழங்கும். DNS-ஐ நிரந்தரமாக cache செய்யும் ஒரு client, செயலிழந்த container-உடன் தன்னை இணைத்துக்கொள்ளும். மேலும், --network இல்லாமல் வெறும் docker run-ஐப் பயன்படுத்தும் பழைய bridge network-ல் பெயர் மாற்றம் (name resolution) வசதி கிடையாது. இதனால்தான் 2016-ல் கூறப்பட்ட container links தொடர்பான ஆலோசனைகள் தற்போது நீங்கள் காண்பவற்றுடன் ஒத்துப்போவதில்லை.

இரண்டு சேவைகளை இணைக்க உங்களுக்கு ports: தேவையில்லை

ports: என்பது ஒரு container-ன் port-ஐ host-ல் வெளியிடுகிறது. இது Docker-க்கு வெளியிலிருந்து வரும் traffic-க்காக மட்டுமே. இது சேவைக்கு-சேவை (service-to-service) இடையிலான traffic-க்குத் தேவையில்லை, ஏனெனில் project network-ல் உள்ள அனைத்து port-களும் ஏற்கனவே அவற்றுக்கிடையே செயல்படும்.

எனவே, பலர் தங்கள் database சேவைக்குச் சேர்க்கும் ports: - "5432:5432" எந்தப் பயனும் தராது, மாறாகத் தீமையே விளைவிக்கும்: இது Postgres-ஐ server-ன் public interface-ல் வெளிப்படுத்துகிறது. அதை நீக்கிவிடவும். ஒரு migration-க்காக உங்கள் laptop-லிருந்து அதை அணுக விரும்பினால், "127.0.0.1:5432:5432" மூலம் loopback-ல் bind செய்து, SSH tunnel வழியாக அணுகவும். ஒரு listening socket, published port மற்றும் firewall rule ஆகியவற்றிற்கு இடையிலான வேறுபாடுகள் Linux-ல் ports மற்றும் listening services எவ்வாறு செயல்படுகின்றன என்பதில் விளக்கப்பட்டுள்ளன.

expose: என்பது Compose-ல் ஆவணப்படுத்துதலுக்காக மட்டுமே. இது எதையும் திறப்பதில்லை, ஏனெனில் ஒரே network-ல் உள்ள containers-க்கு இடையே எதுவும் மூடப்பட்டிருக்கவில்லை.

network_mode host எப்போது பொருத்தமானது மற்றும் அதன் விளைவுகள்

Host mode, container-ன் சொந்த network namespace-ஐ நீக்கிவிட்டு, host-ன் interfaces-ஐ நேரடியாகப் பயன்படுத்த process-ஐ அனுமதிக்கிறது.

services:
  probe:
    image: alpine:3.20
    network_mode: host
    command: sleep infinity

இதை விரும்புவதற்கு வலுவான காரணங்கள் உள்ளன. Media server அல்லது home automation hub போன்ற சாதனங்களைக் கண்டறியும் (device discovery) செயல்பாடுகளுக்கு, local network-ல் உள்ள broadcast அல்லது multicast traffic-ஐப் பார்க்க வேண்டியிருக்கும். Bridge-க்கு பின்னால் இருக்கும் container-களுக்கு இந்த traffic கிடைக்காது, ஏனெனில் bridge அதை forward செய்யாது. Host-ன் interface counters-ஐ வாசிக்கும் monitoring agent-க்கு host-ன் interfaces தேவைப்படும். மேலும், address translation-ஐத் தவிர்ப்பதன் மூலம், அதிக packet rate உள்ள சூழலில் செயல்திறன் மேம்படும்.

இதற்கான விளைவுகள் குறிப்பிட்டவை.

ports: வேலை செய்யாது. Host network mode-ஐப் பயன்படுத்தும்போது published ports நிராகரிக்கப்படும் என்று Docker எச்சரிக்கிறது; process எதனுடன் bind ஆகிறதோ, அதையே container பயன்படுத்தும். ஒரே host-ல் இரண்டு host mode container-கள் port 8080-ஐப் பயன்படுத்த முயன்றால் மோதல் ஏற்படும், இரண்டாவது container bind: address already in use பிழையுடன் நின்றுவிடும்.

Service name மூலம் பெயர் தீர்மானம் (name resolution) இரு திசைகளிலும் இருக்காது. Container project network-ல் இல்லாததால், அதனால் db-ஐத் தீர்க்க முடியாது, மற்ற services-ஆலும் இதைக் கண்டறிய முடியாது. இது வழக்கமாக 127.0.0.1-ல் host-ல் publish செய்யப்பட்ட ports வழியாக மட்டுமே மற்றவற்றைச் சென்றடையும்.

Isolation நீங்கிவிடும். Host mode container-க்குள் 0.0.0.0-ஐ bind செய்யும் ஒரு process, உங்கள் server-ன் அனைத்து interfaces-களிலும், public interface உட்பட, கேட்கத் தொடங்கும் (listening). இது apt மூலம் நிறுவப்பட்ட ஒரு package போலவே செயல்படும். இதில் ஒரு நன்மை உண்டு: இந்த traffic சாதாரண input path-ஐப் பின்பற்றுவதால், UFW விதிகள் இதற்குப் பொருந்தும்; published ports-க்கு இது பொருந்தாது.

Host mode என்பது Linux Docker Engine-ன் ஒரு வசதியாகும். Docker Desktop-ல் இது 4.34 பதிப்பிற்குப் பிறகு, நீங்கள் அதை enable செய்த பின்னரே செயல்படும். மேலும், container-கள் host IP addresses-ஐ bind செய்ய முடியாது மற்றும் TCP, UDP மட்டுமே கையாளப்படும் போன்ற கூடுதல் கட்டுப்பாடுகள் உள்ளன. உங்கள் குழுவில் பாதி பேர் Linux server-களிலும், மீதி பேர் Docker Desktop-லும் இருந்தால், ஒரே கோப்பு வெவ்வேறு விதமாகச் செயல்படுவதை எதிர்பார்க்கலாம்.

Host-ன் interfaces தேவைப்படும்போது மட்டும் host mode-ஐத் தேர்ந்தெடுக்கவும். ஒரு connection சிக்கலைத் தீர்க்க இதை நாட வேண்டாம், ஏனெனில் இது வழக்கமாக ஒரு சிக்கலைத் தீர்த்துவிட்டு, அதைவிடக் கடினமான மற்றொரு சிக்கலை உருவாக்கும்.

இரண்டு Compose திட்டங்களை ஒரு external network மூலம் இணைத்தல்

ஒரு திட்டத்தால் உருவாக்கப்பட்ட network மற்றொன்றுக்குத் தெரியாது. இதனால்தான் proxy/compose.yaml-ல் உள்ள ஒரு reverse proxy, அதே server-ல் இருந்தாலும் app/compose.yaml-ல் உள்ள ஒரு app-ஐப் பார்க்க முடியாது. இதற்குத் தீர்வு, எந்தத் திட்டத்திற்கும் சொந்தமில்லாத ஒரு network-ஐப் பயன்படுத்துவதாகும்.

இதை ஒருமுறை கைமுறையாக உருவாக்கவும்:

docker network create edge

பிறகு, ஒவ்வொரு திட்டத்திலும் இதை external என்று அறிவிக்கவும். Proxy பக்கம்:

services:
  proxy:
    image: traefik:v3.1
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - edge

networks:
  edge:
    name: edge
    external: true

Application பக்கம்:

services:
  app:
    image: nginx:1.27
    networks:
      - edge
      - internal
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    networks:
      - internal

networks:
  edge:
    name: edge
    external: true
  internal:

external: true, ஒரு புதிய network-ஐ உருவாக்குவதற்குப் பதிலாக ஏற்கனவே உள்ள ஒன்றில் இணையுமாறு Compose-க்குக் கட்டளையிடுகிறது, மேலும் docker compose down-ன் போது அதை அப்படியே விட்டுவிடுகிறது. தனித்தனி name: key பார்ப்பதை விட முக்கியமானது: இது இல்லையென்றால், Compose சரியாக edge என்று பெயரிடப்பட்ட network-ஐத் தேடும்; இது இருந்தால், உங்கள் கோப்பில் ஒரு பெயரையும் host-ல் மற்றொரு பெயரையும் பயன்படுத்தலாம்.

Network இல்லை என்றால், Compose தொடங்க மறுத்துவிடும் மற்றும் network external என்று அறிவிக்கப்பட்டும் அதைக் கண்டறிய முடியவில்லை என்று பிழையைக் காட்டும். எனவே, முதலில் அதை உருவாக்கவும்.

Application கோப்பு internal-ஐ எவ்வாறு பயன்படுத்துகிறது என்பதைக் கவனிக்கவும். Database அந்தத் திட்டத்திற்குரிய local network-ல் மட்டுமே இருப்பதால், proxy-ஆல் அதை அணுக முடியாது, app-ஆல் மட்டுமே முடியும். ஒரு network-ன் கீழ் internal: true-ஐச் சேர்ப்பது, வெளிப்புற உலகிற்கான அதன் தொடர்பை முழுமையாக நீக்கிவிடும். Database-க்கு இது ஒரு சிறந்த இயல்புநிலை (default) அமைப்பாகும், ஆனால் இதை அமைக்கும் முன் ஒரு விஷயத்தை நினைவில் கொள்ள வேண்டும்: internal network-ல் உள்ள ஒரு container-ஆல் எதையும் download செய்ய முடியாது. எனவே, தொடக்கத்தின் போது apt-get update அல்லது pip install-ஐ இயக்கும் ஒரு entrypoint, timeout ஆகித் தோல்வியடையும்.

Routing விதிகள் மற்றும் certificates கொண்ட முழுமையான செயல்பாட்டு அமைப்பிற்கு, ஒரே Traefik instance-க்கு பின்னால் பல செயலிகளை இயக்குதல் என்பதைப் பார்க்கவும்.

Published ports UFW-ஐத் தவிர்க்கின்றன

Compose networking-ல் இதுவே பாதுகாப்புச் சிக்கலுக்கு வழிவகுக்கும் பகுதியாகும். நீங்கள் ஒரு port-ஐ publish செய்கிறீர்கள், UFW active நிலையில் உள்ளதா மற்றும் SSH தவிர மற்ற அனைத்தையும் அது தடுக்கிறதா என்று சரிபார்க்கிறீர்கள், ஆனாலும் அந்த service இணையத்திலிருந்து அணுகக்கூடியதாகவே இருக்கும்.

sudo ufw status
curl http://203.0.113.10:8080

UFW அந்த port தடுக்கப்பட்டுள்ளதாகக் கூறுகிறது. ஆனாலும் curl அந்தப் பக்கத்தைக் காட்டுகிறது. இதில் எதுவும் பழுதடையவில்லை. Docker தனது சொந்த address translation மற்றும் forwarding விதிகளை நேரடியாக iptables-ல் எழுதுகிறது. ஒரு published container port-க்கு வரும் traffic, host-க்கு வழங்கப்படுவதற்குப் பதிலாக நேரடியாக container-க்கு அனுப்பப்படுகிறது. எனவே, உள்ளூர் traffic-க்காக UFW நிர்வகிக்கும் chain வழியாக அது செல்வதில்லை. மேலும், UFW-ன் விதிகளுக்கு முன்பாகவே Docker-ன் விதிகள் சரிபார்க்கப்படுகின்றன.

இதற்கான எளிய தீர்வு, உங்களுக்குத் தேவையான இடத்தில் மட்டும் port-ஐ publish செய்வதாகும்:

    ports:
      - "127.0.0.1:8080:80"

இது host-ன் பக்கத்தை loopback-உடன் இணைக்கிறது. எனவே, அந்த port-ஐ server-லிருந்தோ அல்லது SSH tunnel வழியாகவோ மட்டுமே அணுக முடியும், வேறு எங்கிருந்தும் அணுக முடியாது. பொதுவான entry point-ஐ, 80 மற்றும் 443 ports-ஐ முறையாகப் பயன்படுத்தும் ஒரு reverse proxy-க்கு பின்னால் வைக்கவும். நீங்கள் ஒரு published port-ஐ வடிகட்ட வேண்டிய சூழல்களுக்கான DOCKER-USER chain உள்ளிட்ட முழுமையான விளக்கம் Docker ஏன் UFW-ஐத் தாண்டி port-ஐ publish செய்கிறது மற்றும் அதை எப்படிச் சரிசெய்வது என்பதில் உள்ளது.

நான்கு கட்டளைகள் மூலம் பிழைத்திருத்தம் செய்வது எப்படி

ஒவ்வொரு container-ம் எந்த network-ல் உள்ளது என்பதை முதலில் சரிபார்க்கவும்:

docker network inspect shop_default

Containers தொகுதி, இணைக்கப்பட்டுள்ள ஒவ்வொரு container-ன் முகவரியையும் பட்டியலிடுகிறது. அந்தப் பட்டியலில் ஒரு service இல்லை என்றால், அது வேறு network-ல் உள்ளது, host mode-ல் உள்ளது அல்லது இயங்கவில்லை என்று அர்த்தம்.

உங்கள் சொந்த image-க்குள் எந்தக் கருவியும் தேவையில்லாமல், அதே network-ல் இணைக்கப்பட்ட ஒரு தற்காலிக container மூலம் name resolution-ஐச் சோதிக்கவும்:

docker run --rm --network shop_default busybox nslookup db
docker run --rm --network shop_default busybox nc -zv db 5432

nslookup தோல்வியடைந்தால், அது name resolution அல்லது network membership-ல் உள்ள சிக்கலைக் குறிக்கிறது. nslookup வெற்றிபெற்று, nc தோல்வியடைந்தால், அந்த service இயங்குகிறது ஆனால் அந்த port-ல் listening நிலையில் இல்லை அல்லது அதன் container-க்குள் 127.0.0.1-க்கு பதிலாக 0.0.0.0-ல் listening நிலையில் உள்ளது என்று அர்த்தம். இது development server-களில் பொதுவாக நடக்கும், இதற்கான தீர்வு Docker-ல் இல்லை, application-ன் bind address-ல் உள்ளது.

Docker bug போலத் தோன்றும் மற்றொரு பிழை இது. Container-கள் தங்களுக்குள் பேசிக்கொள்ள முடிகிறது, ஆனால் உங்கள் அலுவலகம் அல்லது VPN network-ல் உள்ள ஒரு machine-ஐ அடைய முடியவில்லை என்றால், Docker subnet அந்த network-டன் மேலெழுதப்படலாம் (overlap). Docker இயல்பாகவே 172.17.0.0/16-லிருந்து முகவரிகளை ஒதுக்குகிறது. /etc/docker/daemon.json-ல் அந்த pool-ஐ மாற்றவும்:

{
  "default-address-pools": [
    { "base": "10.200.0.0/16", "size": 24 }
  ]
}

பின்பு sudo systemctl restart docker கட்டளையை இயக்கவும், பாதிக்கப்பட்ட network-களை மீண்டும் உருவாக்கவும். ஏனெனில், ஏற்கனவே உள்ள ஒரு network அது உருவாக்கப்பட்டபோது இருந்த subnet-ஐயே வைத்திருக்கும்.

FAQ

எனது containers ஏன் service name மூலம் ஒன்றையொன்று தொடர்பு கொள்ள முடியவில்லை?

அவை ஒரே network-ல் இல்லை. Compose ஒவ்வொரு service-ஐயும் தானாகவே <project>_default-ல் சேர்க்கிறது. ஆனால், நீங்கள் ஒரு service-க்கு networks: பட்டியலைச் சேர்த்தவுடன், அந்தப் பட்டியல் மட்டுமே அதன் முழுமையான network தொகுப்பாகிவிடும்; இயல்பான (default) network இனி அதில் இருக்காது. docker network inspect <network> கட்டளையை இயக்கி, இரண்டு containers-ம் Containers தொகுதியில் உள்ளனவா என்று சரிபார்க்கவும். மேலும், எந்த service-ம் network_mode: host-ஐப் பயன்படுத்தவில்லை என்பதை உறுதிப்படுத்தவும்; ஏனெனில் host mode-ல் உள்ள container எந்த Docker network-லும் இருக்காது, அதனால் service name-களை resolve செய்ய முடியாது.

ஒரு service மற்றொன்றைத் தொடர்பு கொள்ள ports-ஐ publish செய்ய வேண்டுமா?

தேவையில்லை. ஒரு Compose network-ல், ஒரு container-ன் அனைத்து ports-ம் அந்த network-ல் உள்ள பிற containers-க்கு அணுகக்கூடியவை. ports: என்பது Docker-க்கு வெளியிலிருந்து வரும் traffic-ஐ அனுமதிக்க மட்டுமே பயன்படுகிறது, expose: என்பது ஆவணப்படுத்துதலுக்காக மட்டுமே. database port-ஐ publish செய்வது பொதுவான மற்றும் ஆபத்தான பழக்கமாகும், ஏனெனில் இது உங்கள் server-ன் public interface-ல் database-ஐ வெளிப்படையாக வைக்கிறது.

bridge மற்றும் host networking-க்கு என்ன வித்தியாசம்?

Bridge முறை container-க்கு அதன் சொந்த network namespace மற்றும் virtual switch-ல் ஒரு முகவரியை வழங்குகிறது; இது containers-க்கு இடையே தானியங்கி பெயர் தீர்மானிப்பு (name resolution) மற்றும் outbound traffic மாற்றத்தை (translation) செய்கிறது. Host முறை container-க்கு host-ன் network stack-ஐ நேரடியாக வழங்குகிறது: இதில் தனி முகவரி கிடையாது, service name மூலம் பெயர் தீர்மானிக்க முடியாது, port publishing கிடையாது, மேலும் host-ன் பிற listeners-லிருந்து எந்தப் பாதுகாப்பும் (isolation) கிடையாது. Bridge முறையே இயல்பானது மற்றும் சரியான தேர்வாகும்; process-க்கு host-ன் interfaces தேவைப்பட்டால் ஒழிய இதையே பயன்படுத்தவும்.

இரண்டு வெவ்வேறு Compose files-ல் உள்ள containers-ஐ எவ்வாறு இணைப்பது?

docker network create edge மூலம் பகிரப்பட்ட network ஒன்றை உருவாக்கவும். பின், இரண்டு கோப்புகளிலும் external: true மூலம் அதை அறிவித்து, தொடர்பு கொள்ள வேண்டிய services-ஐ அதனுடன் இணைக்கவும். Compose இதை உருவாக்கவோ அல்லது நீக்கவோ செய்யாது. நீங்கள் உருவாக்கும் படியைத் தவிர்த்தால், network external என்று அறிவிக்கப்பட்டும் அது கிடைக்கவில்லை என்று கூறி Compose தொடங்க மறுத்துவிடும்.

UFW port-ஐத் தடுத்தும், எனது container ஏன் இணையத்திலிருந்து அணுக முடிகிறது?

ஏனெனில், publish செய்யப்பட்ட port-ஐ Docker-ன் iptables forwarding விதிகள் கையாளுகின்றன. அந்த விதிகள் UFW விதிகளை விட முன்னதாகவே பொருந்தும், மேலும் forwarded traffic UFW வடிகட்டும் சங்கிலி (chain) வழியாகச் செல்வதில்லை. host-ன் பக்கத்தை "127.0.0.1:8080:80" மூலம் loopback-க்கு பிணைக்கவும் (bind), பொதுமக்களுக்குத் தேவையான அனைத்தையும் ports 80 மற்றும் 443-ல் உள்ள reverse proxy-க்கு பின்னால் வைக்கவும்.