Gluetun-ல் உள்ள Docker container-களுக்கு network அணுகல்

ஒரு container gluetun-ன் network-ல் இணையும்போது என்ன நடக்கும்

network_mode: service:gluetun என்று அமைக்கப்பட்ட ஒரு container-க்கு சொந்தமாக network interfaces இருக்காது. அது gluetun-ன் network namespace-ல் இணைவதால், port publishing மற்றும் firewall விதிகள் அந்த container-ன் பண்புகளாக இல்லாமல், gluetun service-ன் பண்புகளாக மாறிவிடும். கீழே உள்ள ஒவ்வொரு பதிலும் இந்த ஒரு உண்மையை அடிப்படையாகக் கொண்டது.

Network namespace என்பது kernel-ன் network stack-ன் ஒரு தனிப்பட்ட நகலாகும்: இதில் சொந்த interfaces, routing table, firewall விதிகள் மற்றும் listening sockets இருக்கும். Docker இயல்பாகவே ஒவ்வொரு container-க்கும் ஒன்றை வழங்குகிறது. நீங்கள் network_mode: service:gluetun என்று குறிப்பிடும்போது, Docker அந்தப் படியைத் தவிர்த்துவிட்டு, புதிய container-ஐ ஏற்கனவே gluetun வசம் உள்ள namespace-க்குள் வைக்கிறது. அந்த container தனது சொந்த filesystem மற்றும் /etc/hosts கோப்பைத் தக்கவைத்துக்கொள்ளும், இதில் இரண்டாவது கோப்பு பிற்காலத்தில் முக்கியத்துவம் பெறுகிறது.

இதை நீங்கள் நேரடியாகப் பார்க்கலாம்.

docker inspect -f '{{.HostConfig.NetworkMode}}' qbittorrent

இது container: மற்றும் அதைத் தொடர்ந்து gluetun container ID-ஐ அச்சிடும், சாதாரண container-ஆக இருந்தால் bridge என்று அச்சிடும். இந்த வழிகாட்டி gluetun மூலம் Docker traffic-ஐ VPN வழியாக அனுப்புதல் எங்கு முடிவடைந்ததோ அங்கிருந்து தொடங்குகிறது: tunnel சரியாகச் செயல்படுகிறது, ஆனால் இப்போது அந்த container-ஐ எவராலும் தொடர்பு கொள்ள முடியாது.

Port-ஐ application-ல் அல்ல, gluetun-ல் publish செய்யவும்

சேவை ஒன்றில் ports: தொகுதியை விட்டுவிட்டால், அது network_mode-ஐ அமைக்கும், அப்போது Docker அந்த container-ஐ உருவாக்க மறுத்துவிடும்:

Error response from daemon: conflicting options: port publishing and the container type network mode

இதற்கான காரணம் நேரடியானது. ஒரு port-ஐ publish செய்வது என்பது, host port-ஐ container-ன் சொந்த network namespace-க்குள் அனுப்பும் ஒரு NAT (network address translation) விதியைச் சேர்ப்பதாகும்; ஆனால் இந்த container-க்கு அத்தகைய namespace இல்லை. எனவே, port mapping-ஐ gluetun சேவைக்கு மாற்றவும். Port எண் மாறாது, ஏனெனில் application இன்னும் அந்த shared namespace-க்குள் அதே port-ல் தான் listening நிலையில் உள்ளது.

services:
  gluetun:
    ports:
      - "8080:8080/tcp"   # qBittorrent web UI

  qbittorrent:
    network_mode: "service:gluetun"
    # no ports: block here

சார்ந்துள்ள சேவையில் உள்ள expose: தொகுதியும் பயனற்றது, மேலும் அங்குள்ள networks: தொகுதி ஒரு தடையாகும்: அந்த சேவை ஒன்றுக்கொன்று முரணான network_mode மற்றும் networks-ஐ அறிவிப்பதாக Compose தெரிவிக்கும், மேலும் அந்த file-ஐ ஏற்றவே மறுத்துவிடும்.

இதன் விளைவு பின்னர் ஒரு சிக்கலை ஏற்படுத்தும். Namespace-ல் உள்ள ஒவ்வொரு container-ம் ஒரே port space-ஐப் பகிர்ந்துகொள்கின்றன, எனவே 8080-ஐ default-ஆகக் கொண்ட இரண்டு application-கள் மோதிக்கொள்ளும்; இரண்டாவதாகத் தொடங்கும் application, address already in use என்ற பிழையுடன் தோல்வியடையும். அவற்றில் ஒன்றின் configuration-ஐ மாற்றவும், உதாரணமாக LinuxServer qBittorrent image-ல் உள்ள WEBUI_PORT variable-ஐ மாற்றவும், பின்னர் அந்தப் புதிய எண்ணை gluetun-ல் publish செய்யவும்.

gluetun-க்கு பின்னால் உள்ள containers எவ்வாறு ஒன்றையொன்று தொடர்பு கொள்கின்றன?

Namespace-க்குள் அவை ஏற்கனவே ஒரு loopback interface-ஐப் பகிர்ந்து கொள்கின்றன. gluetun-க்கு பின்னால் உள்ள ஒரு container, Docker network-ன் உதவியின்றி 127.0.0.1:<port>-ல் உள்ள அதன் sibling-ஐ அடைகிறது.

Namespace-க்கு வெளியே இருந்து பார்க்கும்போது, அந்த container-க்கு பெயர் எதுவும் இல்லை. Docker-ன் embedded DNS, ஒரு service பெயரை user defined network-ல் உள்ள அந்த service-ன் முகவரிக்கு மாற்றும்; ஆனால் இந்த container-க்கு எந்த network-லும் முகவரி இல்லை. எனவே, Sonarr போன்ற ஒரு சாதாரண container, http://qbittorrent:8080-ல் உள்ள torrent client-ஐ அடையாது. அது http://gluetun:8080-ல் அதை அடைகிறது, ஏனெனில் அந்த socket gluetun-ன் namespace-ல், gluetun-ன் முகவரியில் listening நிலையில் உள்ளது. Docker Compose networks மற்றும் service பெயர்கள் எவ்வாறு செயல்படுகின்றன என்பதை அறிந்தவர்கள், வழக்கமான naming முறை பொருந்தும் என்று எதிர்பார்ப்பார்கள்; இது அவர்களை ஆச்சரியப்படுத்தும். இரண்டு container-களும் ஒரே Compose network-ல் இருப்பதால், host-க்கு எதையும் publish செய்யாமலேயே இது செயல்படுகிறது.

வேறு எதையும் debug செய்வதற்கு முன் DNS-ஐச் சரிபார்க்கவும். gluetun அதன் சொந்த resolver-ஐ இயக்குகிறது மற்றும் அதன் சொந்த container-ல் /etc/resolv.conf-ஐ மாற்றியமைக்கிறது, ஆனால் /etc/resolv.conf என்பது ஒவ்வொரு container-க்கும் தனிப்பட்டது. எனவே, gluetun மாற்றியமைத்த கோப்பு உங்கள் application படிக்கும் கோப்பு அல்ல.

docker exec qbittorrent cat /etc/resolv.conf

Docker host-ல் இயங்கும் ஒரு service-ஐ எவ்வாறு அணுகுவது?

host.docker.internal-ஐப் பயன்படுத்தவும். இது இரண்டு வெவ்வேறு இடங்களில் இரண்டு அமைப்புகளைக் கோருகிறது, ஏனெனில் இரண்டு வெவ்வேறு விஷயங்கள் சரியாகச் செயல்படுவதில்லை.

முதலில் பெயர் வர வேண்டும். /etc/hosts என்பது ஒவ்வொரு container-க்கும் தனிப்பட்டது, எனவே extra_hosts உள்ளீடு gluetun-ல் அல்லாமல், application container-ல் இருக்க வேண்டும்.

  prowlarr:
    network_mode: "service:gluetun"
    extra_hosts:
      - "host.docker.internal:host-gateway"

host-gateway என்பது Docker-ஆல் host-ன் உள்முக முகவரியாக மாற்றப்படும் ஒரு சிறப்பு மதிப்பாகும். சாதாரண Linux Docker நிறுவலில், இது docker0 bridge-ன் முகவரியாகும், இது பொதுவாக 172.17.0.1 ஆக இருக்கும். VPS-ல் ip -4 addr show docker0 கட்டளையைப் பயன்படுத்தி உங்களுடையதை உறுதிப்படுத்தவும். Docker Desktop இந்த பெயரைத் தானாகவே தீர்த்துக்கொள்ளும், இதனால்தான் மடிக்கணினிகளில் எழுதப்பட்ட வழிகாட்டிகள் extra_hosts வரியைத் தவிர்க்கின்றன, ஆனால் அதே கோப்பு server-ல் தோல்வியடைகிறது.

இரண்டாவதாக, route வர வேண்டும். பெயரைச் சேர்ப்பது எந்த முகவரியைப் பயன்படுத்த வேண்டும் என்பதை மட்டுமே container-க்குத் தெரிவிக்கும். packet இன்னும் gluetun-ன் default route வழியாகவே வெளியேறுகிறது, அது tunnel ஆகும், மேலும் gluetun-ன் firewall அதைத் தடுத்துவிடும். இதன் அறிகுறி என்னவென்றால், இணைப்பு துண்டிக்கப்படாமல் அப்படியே நின்று, பின் காலாவதியாகும் (timeout). இணைப்பு மறுக்கப்பட்டால் (refused), packet சென்றடைந்து, ஏதோ ஒன்று 'இல்லை' என்று பதிலளித்துள்ளது என்று அர்த்தம். காலாவதியாதல் (timeout) என்றால், அது சென்றடையவே இல்லை என்று பொருள்.

  gluetun:
    environment:
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32

பிறகு, host service அந்த முகவரியில் தான் listening நிலையில் உள்ளதா என்பதைச் சரிபார்க்கவும். 127.0.0.1-ல் மட்டும் bound செய்யப்பட்ட PostgreSQL server-ஐ எந்த container-லிருந்தும் அணுக முடியாது, tunnel இருந்தாலும் சரி, இல்லாவிட்டாலும் சரி. ஏனெனில் namespace-க்குள் இருக்கும் 127.0.0.1 என்பது அந்த namespace-ன் சொந்த loopback ஆகும். அதற்குப் பதிலாக அதை 172.17.0.1-ல் bind செய்யவும்: இது public interface-ல் இல்லாமல், container-களிலிருந்து வரும் இணைப்புகளை ஏற்கும். host-ல் ss -lntp | grep 5432 கட்டளையைப் பயன்படுத்தி இதை உறுதிப்படுத்தவும்.

FIREWALL_OUTBOUND_SUBNETS உண்மையில் எதை மாற்றுகிறது

Gluetun ஆவணங்கள் இதை, Gluetun மற்றும் அதன் network stack-ஐப் பகிரும் containers அணுக அனுமதிக்கப்பட்ட, கமாவால் பிரிக்கப்பட்ட subnets என்று விவரிக்கிறது. இது firewall மற்றும் routing மாற்றங்களை உள்ளடக்கியது என்பதையும் அது குறிப்பிடுகிறது. இவை இரண்டுமே முக்கியமானவை. பட்டியலிடப்பட்ட ஒவ்வொரு subnet-க்கும் Docker bridge gateway வழியாக ஒரு route-ஐ Gluetun சேர்க்கிறது. இதனால் அந்த முகவரிகளுக்கான packets, tunnel வழியாகச் செல்லாமல் eth0 வழியாக வெளியேறுகின்றன. இது அவற்றுக்கான firewall-ஐயும் திறந்துவிடுகிறது; ஏனெனில், VPN server-ஐ நோக்கிச் செல்லாத outbound traffic-ஐ Gluetun பொதுவாகத் தடுத்துவிடும் (drop).

மதிப்பை உள்ளிடும்போது கமாக்களுக்குப் பிறகு இடைவெளி (space) விட வேண்டாம்.

      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,192.168.1.0/24,100.64.7.9/32

இரண்டு பண்புகளைக் கவனிக்கத் தவறுவது எளிது. இது ஒரு namespace அளவிலான அமைப்பு (setting), எனவே இது நீங்கள் கருத்தில் கொண்ட container-க்கு மட்டுமல்லாமல், Gluetun-க்கு பின்னால் உள்ள அனைத்து containers-க்கும் பொருந்தும். மேலும், இது outbound-க்கு மட்டுமே: ஒரு container தொடங்கும் இணைப்புகளை இது கட்டுப்படுத்துகிறது. ஒரு published port-க்கு வரும் இணைப்புகள் வேறு பாதையில் பயணிக்கும், அவற்றுக்கு இங்கே எந்த உள்ளீடும் தேவையில்லை.

Tailscale peer மூலம் web UI-ஐ அணுகுதல்

Tailscale ஒவ்வொரு machine-க்கும் 100.64.0.0/10-ல் ஒரு முகவரியை வழங்குகிறது, இது carrier grade NAT-க்காக ஒதுக்கப்பட்ட வரம்பாகும். இரு திசைகளிலும் வெவ்வேறு செயல்பாடுகள் தேவைப்படுகின்றன.

Inbound அணுகல் எளிதானது. 8080:8080-ஐ gluetun-ல் வெளியிடுவது (publish), host-ன் அனைத்து முகவரிகளிலும் அந்த port-ஐ பிணைக்கிறது (bind). host-ன் tailscale0 interface-ம் அவற்றில் ஒன்று என்பதால், ஒரு peer http://<machine-name>:8080-ஐத் திறந்து container-ஐ அணுக முடியும். இந்த பாதையில் Gluetun எந்தப் பங்கையும் வகிப்பதில்லை, ஏனெனில் Docker-ன் NAT விதி host-ல், namespace-க்கு வெளியே அமைகிறது.

UI-ஐ tailnet வழியாக மட்டுமே அணுகக்கூடியதாக மாற்ற, வெளியிடப்பட்ட port-ஐ அனைத்து முகவரிகளுக்கும் பிணைப்பதற்குப் பதிலாக, host-ன் Tailscale முகவரிக்கு மட்டும் பிணைக்கவும்.

    ports:
      - "100.101.102.103:8080:8080/tcp"

host-ல் tailscale ip -4 கட்டளையைப் பயன்படுத்தி அந்த முகவரியைக் கண்டறியவும். firewall விதியை விட பிணைப்பு (binding) வலுவான கட்டுப்பாட்டைக் கொண்டது, ஏனெனில் port பொதுவான interface-ல் திறக்கப்படுவதே இல்லை. இது Docker publishing ports straight past ufw-ல் உள்ள சிக்கலையும் தவிர்க்கிறது.

Outbound அணுகலில் தான் FIREWALL_OUTBOUND_SUBNETS மீண்டும் வருகிறது. ஒரு container ஒரு peer-ஐ அழைக்க வேண்டியிருந்தால், அந்த peer-ன் முகவரியைச் சேர்க்கவும். முழு /10 வரம்பிற்குப் பதிலாக, ஒவ்வொரு peer-க்கும் ஒரு /32-ஐ முன்னுரிமைப்படுத்தவும். MagicDNS பெயர்கள் container-க்குள் resolve ஆகாது, ஏனெனில் container host-ன் resolver-ஐப் பயன்படுத்துவதில்லை. எனவே, எண் சார்ந்த 100.x முகவரியைப் பயன்படுத்தவும் அல்லது extra_hosts வரியைக் கொண்டு அதை உறுதிப்படுத்தவும். your own Tailscale control server with Headscale-ஐ நீங்கள் இயக்கும்போதும் இதே விதி பொருந்தும்.

பொதுவான வடிவத்திற்கான முழுமையான compose கோப்பு

VPN-க்கு பின்னால் இயங்கும் ஒரு download client, tailnet-ல் மட்டும் பதிலளிக்கும் இரண்டு web UI-கள், மற்றும் host-ல் இயங்கும் PostgreSQL database-ஐ வாசிக்கும் ஒரு container.

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - "127.0.0.1:8000:8000/tcp"        # gluetun control server, host only
      - "100.101.102.103:8080:8080/tcp"  # qBittorrent UI, tailnet only
      - "100.101.102.103:9696:9696/tcp"  # Prowlarr UI, tailnet only
    volumes:
      - ./gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - WIREGUARD_ADDRESSES=${WIREGUARD_ADDRESSES}
      - SERVER_CITIES=Amsterdam
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,100.64.7.9/32
      - TZ=Europe/Amsterdam
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent:/config
      - /srv/downloads:/downloads
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    network_mode: "service:gluetun"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - PROWLARR__POSTGRES__HOST=host.docker.internal
      - PROWLARR__POSTGRES__PORT=5432
      - PROWLARR__POSTGRES__USER=prowlarr
      - PROWLARR__POSTGRES__PASSWORD=${PROWLARR_DB_PASSWORD}
      - PROWLARR__POSTGRES__MAINDB=prowlarr-main
      - PROWLARR__POSTGRES__LOGDB=prowlarr-log
    volumes:
      - ./prowlarr:/config
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

தயாரிப்புப் பெயர்களைக் காட்டிலும், கோப்பின் கட்டமைப்பைக் கவனிக்கவும். இரண்டு UI-களும் gluetun-ல் வெளியிடப்பட்டு, host-ன் tailnet முகவரியுடன் இணைக்கப்பட்டுள்ளன; எனவே அவை Tailscale-ல் மட்டுமே பதிலளிக்கும். Prowlarr-ல் மட்டுமே extra_hosts வரி உள்ளது, ஏனெனில் host.docker.internal-ஐத் தீர்க்கும் (resolve) container அதுவே. FIREWALL_OUTBOUND_SUBNETS இரண்டு தனித்தனி முகவரிகளைக் குறிப்பிடுகிறது: ஒன்று Prowlarr தரவுத்தள இணைப்பை ஏற்படுத்த host-ன் Docker bridge முகவரி, மற்றொன்று ஒரு tailnet peer.

PostgreSQL server இந்த கோப்பில் வேண்டுமென்றே சேர்க்கப்படவில்லை. அது VPS-ல் ஒரு சாதாரண system service-ஆக 172.17.0.1:5432-ல் இயங்குகிறது. இது Docker Compose-ல் ஒரு arr stack அமைப்பைப் போன்ற அடுக்குமுறைதான், ஆனால் தரவுத்தளம் Docker-க்கு வெளியே உள்ளது.

WireGuard private key-ஐ compose கோப்பில் வைக்க வேண்டாம். .env கோப்பிலிருந்து ${WIREGUARD_PRIVATE_KEY} அதை வாசிக்கும்; இந்த முறை Docker Compose-க்கான env கோப்புகள் மற்றும் secrets பகுதியில் விளக்கப்பட்டுள்ளது. condition: service_healthy நிபந்தனை gluetun image-ல் ஏற்கனவே உள்ள healthcheck-ஐப் பயன்படுத்துகிறது, எனவே tunnel தயாராகும் வரை எதுவும் தொடங்காது. Compose healthchecks பொதுவான வடிவத்தை விளக்குகின்றன.

    ports:
      - "8080:8080/tcp"

Tunnel traffic-ஐ உறுதிப்படுத்துதல்

ஒரே கோரிக்கையை (request) இரண்டு முறை இயக்கவும்; முதலில் namespace-க்குள் இருந்தும், பிறகு host-ல் இருந்தும் இயக்கி ஒப்பிடவும்.

docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org
curl -s https://api.ipify.org

முதல் கோரிக்கை உங்கள் VPN provider-ன் exit address-ஐக் காட்ட வேண்டும். இரண்டாவது கோரிக்கை VPS address-ஐக் காட்ட வேண்டும். இவை இரண்டும் ஒன்றாக இருந்தால், container-ன் traffic tunnel வழியாகச் செல்லவில்லை என்று பொருள். அதைச் சரிசெய்யும் வரை இந்த வழிகாட்டியில் உள்ள பிற தீர்வுகள் பயனளிக்காது.

Routing table, எவை tunnel வழியாகச் செல்கின்றன, எவை செல்லவில்லை என்பதைக் காட்டும்.

docker run --rm --network=container:gluetun alpine:3.22 ip route show

Default route, tunnel interface-ஐக் குறிக்க வேண்டும், tun0. அதற்கு கீழே FIREWALL_OUTBOUND_SUBNETS-ல் உள்ள ஒவ்வொரு entry-க்கும் ஒரு route இருக்க வேண்டும்; அவை Docker bridge gateway-ஐக் குறிக்க வேண்டும். eth0 வழியாகச் செல்லும் வேறு எந்த route-ம் VPN-ஐத் தவிர்க்கும் traffic ஆகும்.

Gluetun-ன் control server, port 8000-ல் அதே public IP-ஐக் காட்டும், /v1/publicip/ip. சமீபத்திய பதிப்புகளில் control server routes-க்கு authentication அமைக்க வேண்டியது அவசியம், எனவே அதைச் சார்ந்திருப்பதற்கு முன் அதை அமைக்கவும்.

தவறான subnet-ஆல் ஏற்படும் கசிவு

FIREWALL_OUTBOUND_SUBNETS என்பது firewall-ல் நீங்கள் வேண்டுமென்றே உருவாக்கும் ஒரு துளை, எனவே அந்தத் துளையின் அளவுதான் ஆபத்தின் அளவும் ஆகும். அதை மிகப்பாரியதாக மாற்றும் நான்கு வழிகள்:

• 0.0.0.0/0 என்பது tunnel-க்கு வெளியே அனைத்தையும் அனுப்புகிறது. மேலே உள்ள இரண்டு IP சோதனைகளும் இதை முதல் முறையிலேயே கண்டறிந்துவிடும், ஏனெனில் அவை ஒரே முகவரியையே திருப்பித் தரும்.
• இலக்கை விட அகலமான ஒரு வரம்பு. 10.0.1.7-ல் உள்ள ஒரு machine-ஐ அடைய 10.0.0.0/8-ஐத் திறப்பது, அந்த வரம்பிற்குள் ஒரு torrent peer விளம்பரப்படுத்தக்கூடிய அனைத்து முகவரிகளையும் திறந்துவிடும். 10.0.1.7/32 என்று எழுதவும்.
• tunnel-ன் சொந்த முகவரிகளுடன் ஒன்றுடன் ஒன்று சேரும் ஒரு வரம்பு. gluetun ஆவணங்கள், இது VPN traffic-ஐ bridge வழியாக வெளியே அனுப்பச் செய்துவிடும் என்றும், அது port forwarding-ஐப் பாதிக்கும் என்றும் எச்சரிக்கிறது. ஏதேனும் private வரம்பைத் திறக்கும் முன் உங்கள் WIREGUARD_ADDRESSES மதிப்பைச் சரிபார்க்கவும்.
• Tailscale-க்கான 100.64.0.0/10. இது சுமார் நான்கு மில்லியன் முகவரிகளைத் திறந்துவிடுகிறது, ஒரு peer-ஐ அடைய மட்டுமே இது தேவைப்படுகிறது. உங்களுக்குத் தேவையான peer-களை /32 உள்ளீடுகளாகப் பட்டியலிடவும்.

இந்த அமைப்பு முழு namespace-க்கும் பொருந்தும் என்பதை நினைவில் கொள்க. ஒரு indexer ஒரு host service-ஐ அடைய ஒரு subnet-ஐத் திறப்பது, அதே namespace-ஐப் பகிரும் torrent client-க்கும் அதே subnet-ஐத் திறந்துவிடும். இந்த variable-ல் ஒவ்வொரு மாற்றத்தைச் செய்த பிறகும் public IP சோதனையை மீண்டும் இயக்கவும், ஏனெனில் நீங்கள் செய்த மாற்றம் நீங்கள் எதிர்பார்த்ததைச் செய்ததா என்பதைக் காட்டும் ஒரே சோதனை அதுதான்.

gluetun-ஐ restart செய்யும்போது என்ன பாதிப்புகள் ஏற்படும்

gluetun ஒரு namespace-ஐக் கட்டுப்படுத்துவதால், அதன் lifecycle-தான் அந்த namespace-ன் lifecycle-ஆகும். gluetun இயங்காத நிலையில், அதைச் சார்ந்திருக்கும் container-ஐத் தொடங்க முயன்றால் அது உடனடியாகத் தோல்வியடையும்:

Error response from daemon: cannot join network of a non running container

gluetun-ஐ மட்டும் restart செய்வது அமைதியான தோல்விக்கு வழிவகுக்கும். dependent container-கள் தொடர்ந்து இயங்கிக்கொண்டிருக்கும், ஆனால் அவை இணைக்கப்பட்டிருந்த namespace அதற்கு அடியில் மீண்டும் கட்டமைக்கப்படும். இதனால் docker ps அனைத்தும் சரியாக இருப்பதாகக் காட்டும், ஆனால் எந்தப் பதிலுமிருக்காது. gluetun service-ல் ஏதேனும் மாற்றம் செய்த பிறகு, ஒரு பகுதியை மட்டும் restart செய்வதற்குப் பதிலாக, முழு குழுவையும் (group) மீண்டும் உருவாக்கவும்.

docker compose up -d --force-recreate

இது image updates-க்கும் பொருந்தும். புதிய gluetun image-ஐப் பதிவிறக்கி அந்த ஒரு service-ஐ மட்டும் மீண்டும் உருவாக்கினால், மற்றவை ஏற்கனவே இல்லாத ஒரு namespace-ஐச் சுட்டிக்காட்டும்.

FAQ

Docker ஏன் "port publishing and the container type network mode" என்று பிழையைக் காட்டுகிறது?

ஏனெனில் ports: தொகுதி, network_mode: service:gluetun அமைக்கப்பட்ட ஒரு service-ல் இன்னும் உள்ளது. ஒரு port-ஐ publish செய்வது, host port-ஐ container-ன் சொந்த network namespace-க்குள் அனுப்பும் ஒரு NAT விதியைச் சேர்க்கிறது; ஆனால் இந்த mode-ல் உள்ள container-க்கு அத்தகைய namespace கிடையாது. அந்த service-லிருந்து ports: தொகுதியை நீக்கிவிட்டு, அதே mapping-ஐ gluetun service-ல் சேர்க்கவும். அந்த application இன்னும் பகிரப்பட்ட namespace-க்குள் அதே port-ல் தான் listening செய்வதால், port எண் மாறாது.

gluetun-க்கு பின்னால் உள்ள ஒரு service-ஐ மற்ற container-கள் எவ்வாறு அணுகுவது?

ஒரே namespace-க்குள் இருக்கும் container-கள் 127.0.0.1 மூலம் ஒன்றையொன்று அணுகிக்கொள்ளும். அதற்கு வெளியே உள்ள container-கள் gluetun service பெயரைப் பயன்படுத்தும், எனவே http://qbittorrent:8080 வேலை செய்யாத இடத்தில் http://gluetun:8080 வேலை செய்யும். அந்த application container-க்கு எந்த Docker network-லும் முகவரி இல்லாததால், அதன் பெயருக்காக embedded DNS server-ஆல் எதையும் resolve செய்ய முடியாது. இரண்டு container-களும் ஒரே Compose network-ஐப் பகிர்ந்துகொள்ளும் வரை, இதற்கு port publishing தேவையில்லை.

FIREWALL_OUTBOUND_SUBNETS-ல் நான் எதை உள்ளிட வேண்டும்?

gluetun-க்கு பின்னால் உள்ள ஒரு container எந்த முகவரிகளுக்குத் தொடர்பைத் தொடங்க வேண்டுமோ, அவற்றை மட்டும் மிகத் துல்லியமாகக் குறிப்பிடவும். ஒரு தனி இயந்திரம் என்பது /32 ஆகும். பொதுவாகப் பயன்படுத்தப்படும் இரண்டு உள்ளீடுகள்: 172.17.0.1/32-ல் உள்ள Docker host மற்றும் நீங்கள் அழைக்கும் ஒவ்வொரு Tailscale peer-க்கும் ஒரு /32. ஒருபோதும் 0.0.0.0/0-ஐச் சேர்க்க வேண்டாம், மேலும் உங்கள் VPN-ன் சொந்த tunnel முகவரிகளுடன் மேலெழும்பும் (overlap) எந்த range-ஐயும் சேர்க்க வேண்டாம். publish செய்யப்பட்ட port-க்கான உள்வரும் இணைப்புகளுக்கு (inbound connections) இங்கே எந்த உள்ளீடும் தேவையில்லை.

container-ஆல் ஏன் எனது Tailscale MagicDNS பெயர்களை resolve செய்ய முடியவில்லை?

MagicDNS, host-ன் resolver-ஐ Tailscale-ன் DNS server-க்குச் சுட்டிக்காட்டுவதன் மூலம் செயல்படுகிறது; ஆனால் container host-ன் resolver-ஐப் பயன்படுத்துவதில்லை. அது அதன் சொந்த /etc/resolv.conf சொல்வதைப் பயன்படுத்துகிறது, இது gluetun-க்கு பின்னால் gluetun-ன் DNS அமைப்பாக இருக்கும். இதை docker exec <container> cat /etc/resolv.conf மூலம் உறுதிப்படுத்தவும். peer-ன் எண் சார்ந்த 100.x முகவரியைப் பயன்படுத்தவும் அல்லது அந்த container-ல் extra_hosts உள்ளீடு மூலம் பெயரைப் பொருத்தவும் (pin).

traffic இன்னும் VPN வழியாகத்தான் செல்கிறது என்பதை நான் எப்படி உறுதிப்படுத்துவது?

namespace-க்குள் இருந்து ஒரு கோரிக்கையை (request) இயக்கவும், அதே கோரிக்கையை host-லிருந்து இயக்கவும், பின்னர் பதில்களை ஒப்பிடவும். docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org உங்கள் VPN வழங்குநரின் exit முகவரியைத் தர வேண்டும், அதேசமயம் VPS-ல் உள்ள curl -s https://api.ipify.org, VPS-ன் முகவரியைத் தர வேண்டும். இரண்டு பதில்களும் ஒன்றாக இருந்தால், tunnel அந்த container-ன் traffic-ஐக் கொண்டு செல்லவில்லை என்று அர்த்தம். FIREWALL_OUTBOUND_SUBNETS-ல் ஒவ்வொரு மாற்றத்தைச் செய்த பிறகும் இந்தச் சோதனையை மீண்டும் செய்யவும்.