Docker containers-ஐ VPN மூலம் route செய்வது எப்படி

Docker containers-ஐ VPN மூலம் route செய்யும்போது ports ஏன் மறைகின்றன

Docker containers-ஐ VPN மூலம் route செய்ய, ஒரு container-க்கு tunnel-ஐ வழங்கி, network_mode: "service:gluetun" மூலம் மற்ற containers-ஐ அதன் network namespace-க்கு இணைக்க வேண்டும். மக்களை ஆச்சரியப்படுத்தும் பகுதி இந்த இணைப்புதான். இணைக்கப்பட்ட container-க்கு தனிப்பட்ட network இனி இருக்காது. எனவே, அதனுடன் அதன் published ports மற்றும் Docker service name-உம் மறைந்துவிடும். Ports-ஐ VPN container-ல் publish செய்யவும். பிற containers அந்த app-ஐ VPN container-ன் name மூலம் அணுகும்.

இணைக்கப்பட்ட container-ல் ports: block-ஐ வைத்திருந்தால், Docker அதை உருவாக்கவே மறுக்கும்:

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

இங்கு பயன்படுத்தப்படும் tool Gluetun ஆகும். இது WireGuard அல்லது OpenVPN மூலம் commercial VPN (virtual private network) provider-க்கு இணைந்து, தனக்கான firewall-ஐ இயக்கும் container ஆகும். August 2026 நிலவரப்படி v3.41.3 தற்போதைய release ஆகும். இந்த எடுத்துக்காட்டுகள் WireGuard உடன் Mullvad-ஐ பயன்படுத்துகின்றன. எனவே, உங்கள் provider-இடம் account மற்றும் key தேவை. Tunnel-ஐ நீங்கள் சொந்தமாக வைத்திருக்கும் hardware-ல் terminate செய்ய விரும்பினால், VPS-ல் உங்கள் சொந்த WireGuard server-ஐ இயக்குதல் மறுபுற endpoint-ஐ உருவாக்கும். Docker-ல் wg-easy அதை web interface மூலம் நிர்வகிக்க உதவும்.

உண்மையில் network_mode: "service:gluetun" என்ன செய்கிறது

பொதுவாக, ஒவ்வொரு Docker container-க்கும் தனித்தனி network namespace கிடைக்கும். அதில் தனித்தனி interfaces, routing table, firewall rules மற்றும் listening sockets இருக்கும். service: mode இந்த படிநிலையைத் தவிர்த்து, gluetun-ன் namespace-க்குள் container-ஐ தொடங்குகிறது. ஒரு namespace என்றால் ஒரு IP address மட்டுமே. இதனால் ஆறு மாற்றங்கள் ஏற்படும்.

• Application-க்கு தனிப்பட்ட address இருக்காது. அதன் address gluetun-ன் address ஆகும்.
• Application எந்த Docker network-க்கும் இணைக்கப்படாது. எனவே அதன் service name பதிவு செய்யப்படாது; அது resolve ஆகவும்ாது. மற்ற containers gluetun-ஐ பயன்படுத்த வேண்டும்.
• ஒரே namespace-க்குள் உள்ள containers, localhost மூலம் ஒன்றையொன்று அடையும்.
• ஒரே namespace-ல் உள்ள இரண்டு containers ஒரே port-ல் listen செய்ய முடியாது. Gluetun documentation இதைத் தெளிவாகக் குறிப்பிடுகிறது: இதற்கு workaround இல்லை.
• Capabilities ஒரு namespace-க்கு அல்ல, ஒரு container-க்கு சொந்தமானவை. Tunnel interface-ஐ உருவாக்குவதால் Gluetun NET_ADMIN மற்றும் /dev/net/tun-ஐக் கொண்டுள்ளது. அதனுடன் இணைக்கப்பட்ட container அவற்றை inherit செய்யாது.
• ஒரு service network_mode மற்றும் networks இரண்டையும் அமைத்துள்ள எந்த file-ஐயும் Compose நிராகரிக்கும். gluetun-ஐ உங்கள் networks-க்கு இணைக்கவும்; application அதனுடன் இணைந்து செயல்படும்.

gluetun-ஐ restart செய்தால், அதனுடன் இணைக்கப்பட்ட அனைத்தும் disconnect ஆகும். இது documentation-ல் குறிப்பிடப்பட்ட behaviour ஆகும். Connection தோல்வியுற்றால் container-லிருந்து வெளியேறுவதற்குப் பதிலாக, gluetun VPN process-ஐ container-க்குள் restart செய்வதற்கான காரணமும் இதுவே. gluetun-ஐ நீங்களே restart அல்லது recreate செய்த பிறகு, அதனுடன் இணைக்கப்பட்ட containers-ஐ restart செய்யவும்.

இயங்கும் compose file

services:
  gluetun:
    image: qmcgaw/gluetun:v3
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - SERVER_CITIES=Amsterdam
      - TZ=Europe/Amsterdam
    env_file:
      - ./gluetun.env
    volumes:
      - ./gluetun:/gluetun
    ports:
      - 127.0.0.1:8080:8080/tcp
    restart: unless-stopped

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

:v3 tag என்பது v3 series-இன் சமீபத்திய stable release ஆகும். :latest tag, master branch-இன் கடைசி commit-ஐக் குறிக்கிறது. இது development edge ஆகும். எனவே, செவ்வாய்க்கிழமை debugging செய்ய விரும்பாத machine-ல் :v3-ஐ pin செய்யவும்.

WEBUI_PORT=8080, publish செய்யப்பட்ட port-உடன் பொருந்த வேண்டும். ஏனெனில் qBittorrent, gluetun-ன் namespace-க்குள் bind ஆகிறது; publish rule, host traffic-ஐ அங்குள்ள port 8080-க்கு அனுப்புகிறது. இரண்டில் ஒரு எண்ணை மட்டும் மாற்றினால், அந்த port எந்தப் பதிலும் அளிக்காது. 127.0.0.1:8080:8080, web interface-ஐ host-ன் loopback address-ல் மட்டும் வைத்திருக்கிறது. தனியாக உள்ள 8080:8080, அனைத்து interfaces-லும்அதை publish செய்து, அதற்கான firewall rule-ஐ தானாக உருவாக்கும். இப்படித்தான் Docker published ports, ufw-ஐ நேரடியாகத் தாண்டிச் செல்கின்றன.

அதை தொடங்கிய பிறகு, பின்வரும் வரிசையில் சரிபார்க்கவும்:

docker compose up -d
docker compose ps
docker compose logs gluetun | tail -30

docker compose ps, gluetun-ஐ healthy என்றும் qbittorrent-ஐ running என்றும் காட்ட வேண்டும். அதன் பிறகு namespace-க்குள் இருந்து exit address-ஐ உறுதிப்படுத்தவும். மற்ற அனைத்தையும் தீர்மானிக்கும் சரிபார்ப்பு இதுவாகும்:

docker run --rm --network=container:gluetun alpine:3.22 sh -c "apk add wget && wget -qO- https://ipinfo.io"

அந்த JSON-ல் உள்ள ip field, உங்கள் VPN provider-ன் address ஆக இருக்க வேண்டும். அது உங்கள் server-ன் சொந்த address ஆக இருந்தால், app tunnel-க்குள் இல்லை. கீழே விவரிக்கப்பட்டுள்ள எதுவும் அந்த நிலையில் எதிர்பார்த்தபடி இயங்காது.

compose file-க்கு keys-ஐ வெளியே வைத்திருக்கவும்

gluetun.env credentials-ஐ வைத்திருக்கும்; அது git-ல் சேர்க்கப்படாது:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

இரண்டு values-உம் உங்கள் provider-ன் account area-ல் உருவாக்கும் WireGuard configuration file-லிருந்து பெறப்படுகின்றன. அந்த file-க்கு mode 600 அமைக்கவும். இது வழங்கும் பாதுகாப்பை சரியாகப் புரிந்துகொள்ள வேண்டும்: key உங்கள் repository-க்கு வெளியே இருக்கும். ஆனால் Docker socket-ஐ அணுகக்கூடிய எவருக்கும் docker inspect gluetun ஒவ்வொரு environment variable-ஐயும் print செய்யும். Docker Compose-ல் environment files மற்றும் secrets வலுவான options-ஐ விளக்குகிறது.

Tunnel-க்கு வெளியே உள்ள container, அதற்குள் உள்ள container-உடன் எவ்வாறு தொடர்புகொள்கிறது

இரு திசைகளிலும் தொடர்பு செயல்படும். ஒவ்வொரு திசைக்கும் வெவ்வேறு பெயர் பயன்படுத்தப்படும். இந்த இரண்டு containers-க்கும் ஒரு shared Docker network தேவை. அது gluetun-ன் network ஆக இருக்க வேண்டும், ஏனெனில் இணைக்கப்பட்ட container-க்கு தனிப்பட்ட network எதுவும் இருக்காது. Docker Compose networks எவ்வாறு இணைக்கப்படுகின்றன என்ற பகுதி defaults குறித்து விளக்குகிறது.

வெளியிலிருந்து உள்ளே தொடர்புகொள்ள, gluetun-ன் பெயரையும் application listening செய்யும் port-ஐயும் பயன்படுத்தவும். reverse proxy container, qBittorrent web interface-ஐ gluetun:8080 இல் அணுகும். இதற்காக ports: entry தேவையில்லை. காரணம், container-to-container traffic Docker network-க்குள் தங்கிவிடும்; அது host port-ஐ அணுகாது.

உள்ளிருந்து வெளியே தொடர்புகொள்ள, மற்ற container-ன் service name-ஐ பயன்படுத்தவும். உதாரணமாக, postgres:5432. v3.41 முதல், Gluetun தனது namespace-க்குள் மற்ற containers-ன் பெயர்களை resolve செய்கிறது. ஒரு பெயர் resolve ஆகவில்லை என்றால், அந்த version அல்லது அதற்குப் பிந்தைய version-ஐ pin செய்யவும்.

தனது மீது connection திறக்க யாரை அனுமதிப்பது என்பதை Gluetun-ன் firewall தீர்மானிக்கிறது. Gluetun-ன் சொந்த Docker network-லிருந்து வரும் traffic அனுமதிக்கப்படும். வேறு subnet-ல் உள்ள client, உங்கள் LAN-ல் உள்ள laptop, அல்லது தனி bridge network-ல் உள்ள container ஆகியவற்றிலிருந்து வரும் traffic, அந்த subnet-ஐ குறிப்பிடும் வரை drop செய்யப்படும்:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

ஆவணப்படுத்தப்பட்ட பொருள் துல்லியமானது: Gluetun மற்றும் அதன் network stack-ஐ பகிரும் containers அணுக அனுமதிக்கப்படும், comma-separated subnets.

Internet-லிருந்து வரும் inbound connections என்பது தனிப் பிரச்சினை. torrent client-ன் peers VPN பக்கத்திலிருந்து வருகின்றனர். எனவே host-ல் port 6881-ஐ publish செய்வது அவர்களுக்கு எந்தப் பயனும் அளிக்காது. உங்கள் provider-இலிருந்து forwarded port தேவை. அந்த port-ஐ FIREWALL_VPN_INPUT_PORTS இல் குறிப்பிட வேண்டும்; இது VPN server பக்கத்திலிருந்து வரும் ports-ஐ அனுமதிக்கும். பெரும்பாலான Docker Compose மூலம் உருவாக்கப்பட்ட media stacks சரியாகச் செயல்படாமல் இருப்பதற்கான முக்கிய காரணம் இதுவாகும்.

Tunnel துண்டிக்கப்பட்டால் என்ன நடக்கும்: kill switch

இந்த அமைப்பு தோல்வி நேரத்தில்தான் அதன் சிக்கலுக்கான காரணத்தை நிரூபிக்கிறது. இணைக்கப்பட்ட container-க்கு இரண்டாவது route இல்லை. அது machine-இலிருந்து வெளியே செல்லப் பகிர்ந்து கொள்ளும் namespace மட்டுமே ஒரே பாதையாகும். எனவே tunnel செயலிழந்தால் fallback செய்ய வேறு வழி இருக்காது. Gluetun-ன் firewall இதே விதியை மறுபுறத்திலிருந்து அமல்படுத்துகிறது: outbound traffic tunnel வழியாக அல்லது VPN server endpoint-க்கு மட்டும் செல்லும்; மற்ற அனைத்தும் drop செய்யப்படும். client மீண்டும் connect ஆகும் நேரத்தில் packets plain interface வழியாக வெளியேறக்கூடிய இடைவெளி இருக்காது.

Gluetun தனது connection-ஐ தானாகக் கண்காணிக்கிறது. ஒவ்வொரு நிமிடமும் HEALTH_ICMP_TARGET_IPS-ல் உள்ள addresses-க்கு ICMP echo (ping) அனுப்புகிறது. இவற்றின் default value 1.1.1.1,8.8.8.8 ஆகும். ஒவ்வொரு 5 நிமிடத்திற்கும் HEALTH_TARGET_ADDRESSES-க்கு முழுமையான TCP மற்றும் TLS (transport layer security) dial செய்கிறது; இதன் default cloudflare.com:443,github.com:443 ஆகும். இவை தோல்வியடைந்தால் container-க்குள் உள்ள VPN-ஐ restart செய்து, அதை log செய்கிறது:

WARN [vpn] restarting VPN because it failed to pass the healthcheck: periodic check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout

இந்த வரிசையை நினைவில் கொண்டு இணைக்கப்பட்ட container-ன் logs-ஐப் படிக்கவும். app-க்குள் காணப்படும் connection refused, operation not permitted மற்றும் i/o timeout போன்ற lines, செயலிழந்த tunnel-ன் விளைவுகள்; காரணங்கள் அல்ல. Gluetun documentation இதைத் தெளிவாகக் கூறுகிறது. ஏனெனில் பலர் விளைவைப் பார்த்து, காரணத்தைத் தேடி மணிநேரங்கள் செலவிடுகின்றனர்.

HEALTH_RESTART_VPN=on default நிலையில் on-ஆக இருக்க வேண்டும். ஒரு குறிப்பிட்ட failure-ஐ debug செய்யும் போது மட்டும் அதை off செய்யவும். அது off நிலையில் இருந்தால், செயலிழந்த tunnel தொடர்ந்து செயலிழந்த நிலையிலேயே இருக்கும்.

Ordering: tunnel இயக்கத்திற்கு முன் stack தொடங்குவதைத் தடுக்குதல்

இந்த image ஒரு Docker healthcheck-ஐ கொண்டுள்ளது:

HEALTHCHECK --interval=5s --timeout=5s --start-period=10s --retries=1 CMD /gluetun-entrypoint healthcheck

இந்த command, இயங்கிக்கொண்டிருக்கும் gluetun-ன் health server-ஐ http://127.0.0.1:9999/ இல் query செய்யும் gluetun-ன் இரண்டாவது, குறுகிய கால copy-ஐ இயக்குகிறது. Tunnel சரியாக இயங்கினால் 200 OK என்ற பதில் கிடைக்கும். Tunnel செயலிழந்திருந்தால், error string-உடன் 500 Internal server error என்ற பதில் கிடைக்கும்; ஒரே ஒரு failure ஏற்பட்டதும் container unhealthy எனக் குறிக்கப்படும்.

அதற்காகவே condition: service_healthy காத்திருக்கிறது. சாதாரண depends_on: [gluetun] container தொடங்கியதை மட்டும் காத்திருக்கும். Handshake நிறைவடைவதற்கு பல seconds முன்பே container தொடங்கிவிடும். எனவே app செயலிழந்த network நிலையில் தொடங்கி, தனது முதல் connection attempt-ஐ அடிக்கடி கைவிடும். Docker Compose-ல் healthchecks syntax மற்றும் timing fields-ஐ விளக்குகிறது.

ஒரு வரம்பு பலருக்கும் சிக்கலை ஏற்படுத்துகிறது. Compose, container-ஐ உருவாக்கும்போது இந்த condition-ஐ ஒருமுறை மட்டுமே மதிப்பிடும். பின்னர் gluetun unhealthy நிலைக்கு மாறினால், app-ஐ அது stop அல்லது restart செய்யாது. அதற்குப் பதிலாக gluetun-ன் internal auto-healing இந்த நிலையை கையாளும். அதனால்தான் அது container-ஐ அல்ல, VPN process-ஐ restart செய்கிறது.

சுற்றுப்புற அமைப்பை நம்புவதற்கு முன் DNS leak-ஐச் சரிபார்க்கவும்

சரியான tunnel இருந்தாலும் நீடிக்கும் leak என்பது DNS (domain name system) ஆகும். Gluetun namespace-க்குள் சொந்த resolver-ஐ இயக்குகிறது. இயல்பாக, அது queries-ஐ DoT (DNS over TLS) மூலம் Cloudflare-க்கு forward செய்கிறது: DNS_UPSTREAM_RESOLVER_TYPE=dot மற்றும் DNS_UPSTREAM_RESOLVERS=cloudflare. இந்த இரண்டையும் மாற்றாமல் விட்டால், உங்கள் lookups encrypted நிலையில் tunnel வழியாகச் செல்லும்.

இந்த அமைப்பைச் சீர்குலைப்பது DNS_UPSTREAM_PLAIN_ADDRESSES ஆகும். ஒரு name resolve ஆகாதபோது, router அல்லது provider-ன் resolver பதிலளிக்க வேண்டும் என்பதற்காக இதைப் பயன்படுத்துவார்கள். இதன் விளைவை Gluetun documentation தெளிவாகக் கூறுகிறது: DNS traffic முழுவதும் VPN tunnel வழியாகச் செல்லாது; அது tunnel-க்கு வெளியே leak ஆகும். உங்கள் traffic private-ஆகவே இருக்கும். ஆனால் நீங்கள் அணுகும் hostnames பட்டியல் private-ஆக இருக்காது. இதே தவறின் WireGuard பதிப்பு WireGuard tunnel வழியாக DNS resolve ஆகாமல் போவது பகுதியில் விளக்கப்பட்டுள்ளது.

சோதிக்க, gluetun-ல் HTTPPROXY=on அமைத்து 8888:8888/tcp-ஐ publish செய்யவும். பின்னர் அந்த proxy-ஐ browser-ல் பயன்படுத்தி DNS leak test-ஐத் திறக்கவும். முடிவில் உங்கள் provider அல்லது Cloudflare குறிப்பிடப்பட வேண்டும்; உங்கள் home router குறிப்பிடப்படக் கூடாது. namespace-க்குள் உள்ள resolver, இறுதியாகப் பதிலளிக்கும் server அல்ல; local caching intermediary ஆக இருப்பதால், சில leak tests வித்தியாசமான முடிவுகளைக் காட்டலாம் என்று Gluetun-ன் documentation எச்சரிக்கிறது. தவறான country அல்லது உங்கள் சொந்த ISP-ன் resolver தோன்றுவது உண்மையான signal ஆகும்.

VPN sidecar-க்கு அடுத்ததாக Tailscale-ஐ சேர்த்தல் மற்றும் எது முன்னுரிமை பெறும்

Tailscale என்பது உங்கள் சொந்த machines-ஐ அணுகுவதற்காக WireGuard அடிப்படையில் உருவாக்கப்பட்ட overlay network ஆகும். நிர்வாக அணுகல் பாதையை stack-க்குள் வைத்திருக்க, பலர் இதை provider VPN-க்கு இணையாக இயக்குகின்றனர். இவை இரண்டும் அரிதாகவே மோதுகின்றன. இதற்கான காரணத்தைப் புரிந்துகொள்வது பயனுள்ளதாகும். Tailscale documentation கூறும் default நடத்தை இதுதான்: இது overlay network ஆக செயல்படும்; Tailscale இயங்கும் devices-க்கிடையே மட்டுமே traffic-ஐ route செய்யும்; public internet traffic-ஐ மாற்றாது.

எனவே, பதில் ஒரு setting-ஐப் பொறுத்தது.

• Tailscale தனி container-ல் default configuration-உடன் இயங்கினால், app-ன் outbound traffic-ஐ அது ஒருபோதும் காணாது. அந்த traffic முழுவதையும் Gluetun கையாளும். மற்றொரு வெளிப்புற container போலவே, Tailscale gluetun:8080 மூலம் app-ஐ அணுகும்.
• Tailscale-ஐ network_mode: "service:gluetun" மூலம் gluetun-ன் namespace-க்கு இணைத்தால், அதற்கு net_admin-ன் சொந்த cap_add மற்றும் net_raw தேவைப்படும்; namespace-உடன் capabilities தானாக கிடைக்காது. Default userspace networking mode-ல் TS_USERSPACE இயக்கப்பட்டிருக்கும். tailscaled எந்த interface-ஐயும் உருவாக்காது; SOCKS5 அல்லது HTTP proxy ஆக மட்டுமே செயல்படும். எனவே routing-ஐ மாற்ற முடியாது. Gluetun தொடர்ந்து முழு traffic-ஐ கையாளும்.
• TS_USERSPACE=false உடன் அதே configuration பயன்படுத்தப்பட்டால், tailscaled ஒரு tunnel device-ஐ உருவாக்கி routes-ஐ நிறுவும். ஆனால் அவை tailnet range 100.64.0.0/10 மற்றும் TS_ROUTES மூலம் advertise செய்யப்படும் subnet routes-க்கு மட்டுமே பொருந்தும். Public traffic தொடர்ந்து gluetun வழியாக வெளியேறும்.
• மேலே உள்ள எந்த configuration-உடனும் exit node தேர்ந்தெடுக்கப்பட்டிருந்தால், sudo tailscale set --exit-node=<exit-node-ip>, Tailscale default route-ஐக் கைப்பற்றி முன்னுரிமை பெறும். இதை gluetun-உடன் இணைக்க வேண்டாம். ஒரே default route-க்கு ஒரே owner மட்டுமே இருக்க வேண்டும்.

Advertise செய்யப்பட்ட routes-தான் நோக்கமாக இருந்து, box-ஐ மட்டும் அல்லாமல் அதன் பின்னால் உள்ள முழு private network-ஐ அணுக விரும்பினால், VPS-ல் Tailscale subnet router-ஐ இயக்குதல் route approval, IP forwarding மற்றும் TS_ROUTES தனியாகச் செய்யாமல் விடும் client-side flag ஆகியவற்றை விளக்குகிறது.

Route-க்குப் பதிலாக admin URL வழங்குவதற்காக Tailscale பயன்படுத்தப்பட்டால், tailscale serve மற்றும் tailscale funnel உங்கள் tailnet-க்காக gluetun:8080 முன் HTTPS-ஐ அமைக்கும். இதில் funnel மட்டுமே அதை public internet-க்கு திறக்கும்.

Tailscale tunnel-க்குள் இயங்கும்போது ஒரு விளைவு காணப்படும். அதன் peers, VPN provider-ன் address-ஐக் காணும். எனவே அது relays-க்கு அதிகமாக fallback ஆகலாம். அது நிகழ்ந்தபோது, tailscale status ஒரு peer அருகில் direct என்பதற்குப் பதிலாக relay "..." என்பதைக் காட்டும். Connection செயல்படும்; ஆனால் வேகம் குறையும். உங்களுக்கு உண்மையில் தேவையானது overlay மட்டுமே என்றால், plain WireGuard மற்றும் Tailscale இடையிலான வேறுபாடு சிறந்த தொடக்கப் புள்ளியாகும்.

எது செயலிழக்கும், நீங்கள் பார்க்கும் செய்தி

Docker app container-ஐ உருவாக்க மறுக்கிறது. இணைக்கப்பட்ட service-ல் இன்னும் Error response from daemon: conflicting options: port publishing and the container type network mode என்ற ports: block இருப்பதால் இது நிகழ்கிறது. அதை gluetun-க்கு மாற்றவும்.

Compose முழு file-ஐ ஏற்க மறுக்கிறது. ஒரு service network_mode மற்றும் networks இரண்டையும் அமைக்க முடியாது. networks-ஐ gluetun-ல் அமைக்கவும்.

மற்றொரு container-ஆல் app-ஐ resolve செய்ய முடியவில்லை. இணைக்கப்பட்ட container எந்த network-லும் இணையாமல், எந்த name-ஐயும் பதிவு செய்யாததால் curl: (6) Could not resolve host: qbittorrent என்பது சரியான செயல்பாடாகும். gluetun மற்றும் port-ஐ பயன்படுத்தவும்.

இரண்டாவது இணைக்கப்பட்ட container தொடங்காது. ஒரே namespace-ல் உள்ள இரண்டு processes ஒரே port-ஐ bind செய்ய முடியாது. இரண்டாவது process, address ஏற்கனவே பயன்பாட்டில் இருப்பதாகத் தெரிவிக்கும். app-ன் internal port-ஐ மாற்றவும் அல்லது இரண்டாவது gluetun-ஐ இயக்கவும்.

gluetun-ஐ மாற்றிய பிறகு app-க்கு network இல்லை. gluetun-ஐ restart அல்லது recreate செய்வதால் அதனுடன் இணைக்கப்பட்ட அனைத்திற்குமான connectivity துண்டிக்கப்படும். அந்த containers-ஐ restart செய்யவும்.

சிறிய pages load ஆகின்றன; பெரியவை hang ஆகின்றன. இது MTU (maximum transmission unit) பிரச்சினையாகும். tunnel கூடுதல் overhead-ஐச் சேர்க்கிறது. பாதையில் உள்ள ஏதோ ஒன்று, அளவு அதிகமான packets-ஐ error திருப்பி அனுப்பாமல் drop செய்கிறது. WIREGUARD_MTU-ஐக் குறைத்து, 1400-ஐ முயற்சிக்கவும்; பின்னர் 1320-ஐ முயற்சிக்கவும்.

Gluetun ஒருபோதும் healthy நிலையை அடையவில்லை. startup check முதலில் சந்தேகிக்க வேண்டியவற்றை குறிப்பிடுகிறது: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. முதலில் key காலாவதியானதா என்பதைச் சரிபார்க்கவும். பின்னர் server list பழையதா என்பதைச் சரிபார்க்கவும். அடுத்து உங்கள் host firewall outbound UDP-ஐத் தடுக்கிறதா என்பதைச் சரிபார்க்கவும்.

FAQ

எனது container-ன் published ports, Gluetun-க்கு பின்னால் ஏன் செயல்படுவதை நிறுத்தின?

network_mode: "service:gluetun", அந்த container-ஐ gluetun-ன் network namespace-க்குள் வைக்கிறது. ஒரு namespace-க்கு ஒரு IP address மற்றும் listening ports-ன் ஒரு தொகுப்பு மட்டுமே இருக்கும். Application தொடர்ந்து listening நிலையில் இருக்கும். ஆனால் publish rule, namespace-ஐ வைத்திருக்கும் container-ல் இருக்க வேண்டும். ports: பட்டியலை gluetun service-க்கு மாற்றவும். அதை இணைக்கப்பட்ட service-ல் வைத்திருந்தால், Docker அந்த container-ஐ உருவாக்கவே செய்யாது: Error response from daemon: conflicting options: port publishing and the container type network mode.

VPN tunnel-க்கு உள்ளே இருக்கும் container-ஐ, அதற்கு வெளியே இருக்கும் container-லிருந்து எவ்வாறு அணுகுவது?

gluetun-ன் service name மற்றும் application listening செய்யும் port-ஐ பயன்படுத்தவும். எடுத்துக்காட்டாக, gluetun:8080. இணைக்கப்பட்ட container-க்கு தனிப்பட்ட Docker network இல்லை. எனவே அதன் சொந்த name resolve ஆகாது. Container-to-container traffic-க்கு எந்த port publishing-உம் தேவையில்லை. எதிர் திசையில், namespace-க்கு உள்ளே இருக்கும் container, வெளியே இருக்கும் container-ஐ அதன் service name மூலம் அணுகலாம். உதாரணமாக, Gluetun v3.41 மற்றும் அதற்குப் பிந்தைய versions-ல் postgres:5432. வேறு subnet-ல் இருக்கும் client, உதாரணமாக உங்கள் LAN-ல் உள்ள laptop, FIREWALL_OUTBOUND_SUBNETS-ல் அந்த subnet-ஐ சேர்க்கும் வரை gluetun firewall மூலம் drop செய்யப்படும்.

VPN துண்டிக்கப்பட்டால் Gluetun kill switch ஆகச் செயல்படுமா?

ஆம். இதற்கு ஒரே நேரத்தில் 2 காரணங்கள் உள்ளன. இணைக்கப்பட்ட container-க்கு shared namespace-ல் உள்ள route-ஐத் தவிர வேறு route இல்லை. எனவே tunnel செயலிழந்தால், machine-ஐ விட்டு வெளியே செல்ல அதற்கு எந்த network path-உம் இருக்காது. Gluetun-ன் firewall, outbound traffic-ஐ tunnel வழியாகவும் VPN server endpoint-க்கு மட்டுமேவும் அனுமதிக்கும். Gluetun, WARN [vpn] restarting VPN because it failed to pass the healthcheck என்று log செய்தபடி, VPN-ஐ internally restart செய்யும்; அது exit ஆகாது. ஏனெனில் gluetun தானே restart ஆனால், இணைக்கப்பட்ட ஒவ்வொரு container-மும் அதன் network-ஐ இழக்கும்.

ஒரே stack-ல் Tailscale மற்றும் Gluetun இருந்தால், outbound traffic-ஐ எது கையாளும்?

ஒரு விதிவிலக்கைத் தவிர, எல்லா configuration-களிலும் Gluetun கையாளும். Tailscale, இயல்பாக உங்கள் tailnet-ல் உள்ள devices-க்கு இடையிலான traffic-ஐ மட்டுமே route செய்யும். Public traffic-ஐ அது மாற்றாது. Container image-ன் default userspace mode-ல் அது எந்த interface-ஐயும் உருவாக்காது. எனவே routing-ஐ அது பாதிக்க முடியாது. TS_USERSPACE=false பயன்படுத்தும்போது, 100.64.0.0/10 மற்றும் நீங்கள் advertise செய்த subnets-க்கான routes-ஐ மட்டுமே அது நிறுவும். விதிவிலக்கு exit node ஆகும்: sudo tailscale set --exit-node=<exit-node-ip> Tailscale-ஐ default route ஆக மாற்றும். அப்போது Tailscale வெற்றி பெறும். Default route-ஐ நிர்வகிக்க ஒரு product-ஐ மட்டும் தேர்ந்தெடுக்கவும்; இரண்டையும் ஒன்றின் மேல் ஒன்றாக அமைக்க வேண்டாம்.