Docker container-ஐ VPN வழியாக இணைப்பது எப்படி?

Docker containers-ஐ VPN வழியாக route செய்யும்போது ports ஏன் மறைந்துவிடுகின்றன

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

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

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

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

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

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

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

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

செயல்படும் compose கோப்பு

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 தொடரில் உள்ள புதிய நிலையான release ஆகும். :latest tag என்பது master கிளையின் கடைசி commit-ஐக் குறிக்கிறது; இது மேம்பாட்டு நிலையில் (development edge) இருப்பதால், நீங்கள் debug செய்ய விரும்பாத ஒரு machine-ல் :v3-ஐப் பயன்படுத்த வேண்டாம்.

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

இதை இயக்கி, பின்வரும் வரிசையில் சரிபார்க்கவும்:

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

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

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

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

Compose file-ல் keys-ஐ வைக்க வேண்டாம்

gluetun.env என்பது credentials-ஐக் கொண்டுள்ளது, இது git-ல் சேர்க்கப்படக்கூடாது:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

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

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

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

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

உள்ளிருந்து வெளியே செல்ல, மற்ற container-ன் service பெயரைப் பயன்படுத்தவும், உதாரணமாக postgres:5432. v3.41 பதிப்பிலிருந்து, gluetun தனது namespace-க்குள் மற்ற container-களின் பெயர்களைத் தீர்மானிக்கிறது (resolve), எனவே பெயர் தீர்மானிக்கப்படாவிட்டால் அந்தப் பதிப்பையோ அல்லது அதற்குப் பிந்தைய பதிப்பையோ பயன்படுத்தவும்.

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

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

இதன் பொருள் துல்லியமானது: Gluetun மற்றும் அதன் network stack-ஐப் பகிர்ந்து கொள்ளும் container-கள் அணுக அனுமதிக்கப்படும் comma-ஆல் பிரிக்கப்பட்ட subnet-கள் இவை.

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

கில் ஸ்விட்ச் (kill switch): டன்னல் துண்டிக்கப்படும்போது என்ன நடக்கும்

இந்த அமைப்பு தோல்வியடையும் போது அதன் சிக்கலான தன்மையை வெளிப்படுத்துகிறது. இணைக்கப்பட்ட container-க்கு இரண்டாவது வழித்தடம் (route) இல்லை. அது பகிரும் namespace மட்டுமே அதன் ஒரே வெளியேறும் வழியாகும், எனவே டன்னல் துண்டிக்கப்படும்போது, அதற்கு மாற்று வழி ஏதுமில்லை. Gluetun-ன் firewall மறுபுறத்தில் அதே விதியை அமல்படுத்துகிறது: வெளிச்செல்லும் traffic டன்னல் வழியாகவோ அல்லது VPN server endpoint வழியாகவோ மட்டுமே செல்ல வேண்டும், மற்ற அனைத்தும் நிராகரிக்கப்படும். client மீண்டும் இணையும் இடைப்பட்ட நேரத்தில், சாதாரண interface வழியாக packets கசியும் வாய்ப்பு இல்லை.

Gluetun தனது சொந்த இணைப்பைக் கண்காணிக்கும். ஒவ்வொரு நிமிடமும் HEALTH_ICMP_TARGET_IPS-ல் உள்ள முகவரிகளுக்கு ICMP echo (ping) அனுப்பும், இது இயல்பாக 1.1.1.1,8.8.8.8 என இருக்கும். ஒவ்வொரு ஐந்து நிமிடங்களுக்கும் HEALTH_TARGET_ADDRESSES-க்கு முழுமையான TCP மற்றும் TLS (transport layer security) இணைப்பை ஏற்படுத்தும், இது இயல்பாக cloudflare.com:443,github.com:443 என இருக்கும். இவை தோல்வியடையும் போது, அது container-க்குள் இருக்கும் VPN-ஐ மறுதொடக்கம் செய்து, அதை 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 போன்ற வரிகள் டன்னல் செயலிழந்ததன் விளைவுகளே தவிர, அதற்கான காரணங்கள் அல்ல. Gluetun ஆவணங்கள் இதைத் தெளிவாகக் குறிப்பிடுகின்றன, ஏனெனில் பயனர்கள் விளைவுகளை மட்டும் கவனித்துவிட்டு, அதற்கான காரணத்தைத் தேடி மணிக்கணக்கில் வீணடிக்கின்றனர்.

HEALTH_RESTART_VPN=on என்பது இயல்பான அமைப்பாகும், இதை மாற்றாமல் வைத்திருப்பது நல்லது. ஒரு குறிப்பிட்ட தோல்வியைப் பிழைத்திருத்தம் (debug) செய்யும் போது மட்டும் இதை அணைக்கவும், ஏனெனில் இதை அணைத்துவிட்டால், செயலிழந்த டன்னல் தானாக மீண்டும் இயங்காது.

வரிசைப்படுத்துதல்: tunnel தயாராகும் முன் stack தொடங்குவதைத் தடுத்தல்

இந்த image-ல் Docker healthcheck வசதி உள்ளது:

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

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

condition: service_healthy என்பது இதற்காகவே காத்திருக்கிறது. சாதாரண depends_on: [gluetun] என்பது container தொடங்குவதற்கு மட்டுமே காத்திருக்கும். ஆனால், handshake முடிவதற்கு முன்பே container தொடங்கிவிடும் என்பதால், network இணைப்பு இல்லாத நிலையில் application தொடங்கப்பட்டு, முதல் முயற்சியிலேயே தோல்வியடையக்கூடும். Docker Compose-ல் Healthchecks பகுதியில் இதற்கான syntax மற்றும் timing விவரங்கள் உள்ளன.

ஒரு முக்கியமான வரம்பு கவனிக்கத்தக்கது. Compose இந்த நிபந்தனையை container-ஐ உருவாக்கும்போது ஒருமுறை மட்டுமே சரிபார்க்கும். gluetun பிற்காலத்தில் 'unhealthy' நிலைக்கு மாறினால், அது application-ஐ நிறுத்தாது அல்லது restart செய்யாது. gluetun-ன் உள்ளமைக்கப்பட்ட auto-healing வசதியே இந்தச் சூழலைக் கையாள்கிறது; அதனால்தான் அது container-ஐ restart செய்வதற்குப் பதிலாக, VPN process-ஐ மட்டும் restart செய்கிறது.

அமைப்பை நம்புவதற்கு முன் DNS leak உள்ளதா எனச் சரிபார்க்கவும்

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

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

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

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

Tailscale என்பது உங்கள் சொந்த கணினிகளை அணுகுவதற்காக WireGuard-ஐ அடிப்படையாகக் கொண்டு உருவாக்கப்பட்ட ஒரு overlay network ஆகும். நிர்வாகப் பணிகளுக்காக, ஒரு VPN provider-உடன் இணைந்து இதைப் பயன்படுத்துவது வழக்கம். இவை இரண்டும் பொதுவாக ஒன்றையொன்று பாதிப்பதில்லை; இதற்கான காரணத்தைப் புரிந்துகொள்வது அவசியம். Tailscale-ன் ஆவணங்களின்படி, இது ஒரு overlay network-ஆகச் செயல்படுகிறது. இது Tailscale இயங்கும் சாதனங்களுக்கு இடையிலான traffic-ஐ மட்டுமே கையாளுகிறது; உங்கள் பொது இணைய (public internet) traffic-ஐ இது தொடுவதில்லை.

எனவே, இதற்கான விடை ஒரு குறிப்பிட்ட அமைப்பைச் சார்ந்தது.

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

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

எவை செயலிழக்கின்றன மற்றும் நீங்கள் காணும் செய்திகள்

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

Compose முழு கோப்பையும் நிராகரிக்கிறது. ஒரு service-ஆல் network_mode மற்றும் networks ஆகிய இரண்டையும் ஒரே நேரத்தில் அமைக்க முடியாது. networks-ஐ gluetun-ல் வைக்கவும்.

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

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

gluetun-ஐ மாற்றிய பிறகு app-ல் network இல்லை. gluetun-ஐ restart செய்வது அல்லது மீண்டும் உருவாக்குவது அதனுடன் இணைக்கப்பட்ட அனைத்தின் இணைப்பையும் துண்டிக்கும். அந்த container-களை restart செய்யவும்.

சிறிய பக்கங்கள் ஏற்றப்படுகின்றன, பெரிய பக்கங்கள் முடங்குகின்றன. இது MTU (maximum transmission unit) தொடர்பான சிக்கல். tunnel கூடுதல் overhead-ஐ சேர்க்கிறது, மேலும் பாதையில் உள்ள ஏதோ ஒன்று பிழையைத் தெரிவிக்காமல் பெரிய packets-ஐ நிராகரிக்கிறது. 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

Gluetun-க்கு பின்னால் உள்ள எனது container-ன் published ports ஏன் வேலை செய்யவில்லை?

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

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

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

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

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

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

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