Docker container को VPN से कैसे जोड़ें और ports की समस्या

Docker containers को VPN के माध्यम से रूट करने पर ports क्यों गायब हो जाते हैं

Docker containers को VPN के माध्यम से रूट करने के लिए आप एक container को tunnel प्रदान करते हैं, और फिर दूसरों को network_mode: "service:gluetun" के साथ उसके network namespace से जोड़ देते हैं। यह जुड़ाव ही वह हिस्सा है जो लोगों को हैरान करता है। जुड़े हुए container का अपना कोई network नहीं रहता, इसलिए उसके published ports और उसका Docker service name उसके साथ ही समाप्त हो जाते हैं। इसके बजाय VPN container पर ports को publish करें, और अन्य containers VPN container के नाम पर app तक पहुँच प्राप्त करेंगे।

यदि आप जुड़े हुए container पर ports: ब्लॉक छोड़ देते हैं, तो Docker उसे बनाने से पूरी तरह मना कर देता है:

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

यहाँ उपयोग किया जाने वाला टूल Gluetun है, जो एक ऐसा container है जो WireGuard या OpenVPN के माध्यम से एक commercial VPN (virtual private network) प्रदाता से जुड़ता है और अपना स्वयं का firewall रखता है। अगस्त 2026 तक Release v3.41.3 वर्तमान है। उदाहरणों में WireGuard के साथ Mullvad का उपयोग किया गया है, इसलिए आपको अपने प्रदाता से एक account और एक key की आवश्यकता होगी। यदि आप tunnel को अपने स्वयं के hardware पर terminate करना पसंद करते हैं, तो VPS पर अपना स्वयं का WireGuard server चलाना दूसरा छोर बनाता है, और Docker में wg-easy उसे एक web interface में लपेटता है।

network_mode: "service:gluetun" वास्तव में क्या करता है

प्रत्येक Docker container को सामान्यतः अपना स्वयं का network namespace मिलता है: इसके अपने interfaces, routing table, firewall rules और listening sockets। service: मोड उस चरण को छोड़ देता है और container को gluetun के namespace के भीतर शुरू करता है। एक namespace का अर्थ है एक IP address, और यह छह चीजों को बदल देता है।

• App का अपना कोई address नहीं होता है। इसका address gluetun का address होता है।
• App किसी भी Docker network से जुड़ा नहीं होता है, इसलिए इसके service name को कभी register नहीं किया जाता है और वह कभी resolve नहीं होता है। अन्य containers को gluetun का उपयोग करना चाहिए।
• Namespace के भीतर containers एक-दूसरे तक localhost के माध्यम से पहुँचते हैं।
• एक namespace में दो containers एक ही port पर listen नहीं कर सकते हैं। Gluetun documentation इस बारे में स्पष्ट है: इसका कोई workaround नहीं है।
• Capabilities एक container की होती हैं, न कि एक namespace की। Gluetun के पास NET_ADMIN और /dev/net/tun होती हैं क्योंकि यह tunnel interface बनाता है। जुड़ा हुआ container इन्हें inherit नहीं करता है।
• Compose किसी भी ऐसी file को अस्वीकार कर देता है जहाँ एक service network_mode और networks दोनों को set करती है। Gluetun को अपने networks से जोड़ें, और app उसके साथ जुड़ जाएगा।

Gluetun को restart करने से उससे जुड़ी हर चीज़ disconnect हो जाती है। यह documented व्यवहार है, और यही कारण है कि connection विफल होने पर बाहर निकलने के बजाय gluetun container के भीतर VPN process को 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 का मुख्य हिस्सा है, इसलिए जिस machine पर आप debug नहीं करना चाहते, उस पर :v3 को pin न करें।

WEBUI_PORT=8080 को published port से मेल खाना चाहिए, क्योंकि qBittorrent, gluetun के namespace के अंदर bind होता है और publish rule host traffic को वहां port 8080 पर भेजता है। यदि आप एक भी number बदलते हैं और दूसरा नहीं, तो port पर कोई response नहीं मिलेगा। 127.0.0.1:8080:8080, web interface को host loopback address पर रखता है। एक साधारण 8080:8080 हर interface पर publish हो जाता है और अपना खुद का firewall rule लिख देता है, जो कि Docker published ports के ufw से बचने का तरीका है।

इसे start करें, और फिर इस क्रम में जाँचें:

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 उस WireGuard configuration file से आती हैं जिसे आप अपने provider के account area में generate करते हैं। file को mode 600 पर set करें। यह स्पष्ट समझें कि इससे आपको क्या लाभ मिलता है: key आपके repository से बाहर रहती है, लेकिन docker inspect gluetun अभी भी हर environment variable को उस व्यक्ति के लिए print कर देता है जो Docker socket तक पहुँच सकता है। Docker Compose में environment files और secrets अधिक सुरक्षित विकल्पों के बारे में जानकारी देता है।

टनल के बाहर का कंटेनर अंदर के कंटेनर से कैसे बात करता है

दोनों दिशाओं में संचार काम करता है, और प्रत्येक के लिए एक अलग नाम का उपयोग होता है। दोनों कंटेनरों को एक साझा Docker network की आवश्यकता होती है, जिसका अर्थ है gluetun का नेटवर्क, क्योंकि जुड़े हुए कंटेनर का अपना कोई नेटवर्क नहीं होता है। Docker Compose नेटवर्क कैसे जुड़े होते हैं में डिफ़ॉल्ट सेटिंग्स के बारे में बताया गया है।

बाहर से अंदर की ओर जाने के लिए, gluetun के नाम और उस पोर्ट का उपयोग करें जिस पर ऐप listen करता है। एक reverse proxy कंटेनर gluetun:8080 पर qBittorrent वेब इंटरफेस तक पहुँचता है। इसके लिए किसी ports: प्रविष्टि की आवश्यकता नहीं है, क्योंकि कंटेनर से कंटेनर का ट्रैफ़िक Docker network पर ही रहता है और कभी भी host पोर्ट को नहीं छूता है।

अंदर से बाहर की ओर जाने के लिए, दूसरे कंटेनर के सर्विस नाम का उपयोग करें, उदाहरण के लिए postgres:5432। Gluetun v3.41 के बाद से अपने नेमस्पेस के अंदर से अन्य कंटेनर नामों को रिज़ॉल्व कर रहा है, इसलिए यदि कोई नाम रिज़ॉल्व नहीं हो रहा है, तो उस वर्ज़न या उससे नए वर्ज़न को पिन करें।

Gluetun का फ़ायरवॉल यह तय करता है कि कौन इससे कनेक्शन खोल सकता है। Gluetun के अपने Docker network से आने वाले ट्रैफ़िक की अनुमति है। एक अलग सबनेट पर मौजूद क्लाइंट, आपके LAN पर मौजूद लैपटॉप या किसी अलग ब्रिज नेटवर्क पर मौजूद कंटेनर के ट्रैफ़िक को तब तक ड्रॉप कर दिया जाता है जब तक आप उस सबनेट का नाम न दें:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

दस्तावेजीकृत अर्थ सटीक है: अल्पविराम (comma) से अलग किए गए सबनेट जिन्हें Gluetun और इसके नेटवर्क स्टैक को साझा करने वाले कंटेनरों को एक्सेस करने की अनुमति है।

इंटरनेट से आने वाले इनबाउंड कनेक्शन एक अलग समस्या हैं। एक टोरेंट क्लाइंट के पीयर्स VPN साइड से आते हैं, इसलिए host पर पोर्ट 6881 को पब्लिश करने से उन्हें कोई लाभ नहीं होता है। आपको अपने प्रदाता से एक फॉरवर्डेड पोर्ट की आवश्यकता होती है, और वह पोर्ट FIREWALL_VPN_INPUT_PORTS में सूचीबद्ध होना चाहिए, जो VPN सर्वर साइड से पोर्ट्स की अनुमति देता है। यह वह हिस्सा है जिसे Docker Compose के साथ बनाए गए मीडिया स्टैक अक्सर अधूरा छोड़ देते हैं।

Kill switch: जब tunnel drop हो जाए तो क्या होता है

यह पैटर्न विफलता (failure) की स्थिति में अपनी जटिलता को सार्थक करता है। जुड़े हुए container के पास कोई दूसरा route नहीं होता। मशीन से बाहर जाने का इसका एकमात्र रास्ता वह namespace है जिसे यह साझा करता है, इसलिए जब tunnel down होती है तो fallback के लिए कुछ भी नहीं बचता। Gluetun का firewall दूसरी तरफ से भी यही नियम लागू करता है: outbound traffic या तो tunnel से होकर जाता है या VPN server endpoint तक, और बाकी सब कुछ drop कर दिया जाता है। ऐसा कोई समय नहीं होता जब client के reconnect होने के दौरान plain interface से packets leak हों।

Gluetun अपने स्वयं के connection पर नज़र रखता है। हर मिनट यह HEALTH_ICMP_TARGET_IPS में दिए गए addresses पर एक ICMP echo (ping) भेजता है, जो डिफ़ॉल्ट रूप से 1.1.1.1,8.8.8.8 होते हैं। हर पाँच मिनट में यह HEALTH_TARGET_ADDRESSES पर एक पूर्ण TCP और TLS (transport layer security) dial करता है, जो डिफ़ॉल्ट रूप से 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 डिफ़ॉल्ट है और इसे चालू रहना चाहिए। इसे केवल तभी बंद करें जब आप किसी विशिष्ट विफलता को debug कर रहे हों, क्योंकि इसे बंद करने पर एक मृत tunnel मृत ही बनी रहती है।

Ordering: tunnel up होने से पहले stack को start होने से रोकना

यह image एक Docker healthcheck के साथ आती है:

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

यह command gluetun की एक दूसरी, अल्पकालिक copy चलाती है जो http://127.0.0.1:9999/ पर चल रहे health server से query करती है। एक कार्यशील tunnel 200 OK का उत्तर देती है। एक खराब tunnel 500 Internal server error का उत्तर एक error string के साथ देती है, और एक ही विफलता के बाद container को unhealthy चिह्नित कर दिया जाता है।

condition: service_healthy वह है जो इसके लिए प्रतीक्षा करता है। साधारण depends_on: [gluetun] केवल container के start होने की प्रतीक्षा करता है, जो handshake पूरा होने से कई सेकंड पहले हो जाता है, इसलिए app एक मृत network में start होती है और अक्सर अपने पहले connection प्रयास पर ही हार मान लेती है। Docker Compose में Healthchecks में syntax और timing fields की विस्तार से चर्चा की गई है।

एक सीमा लोगों को अक्सर परेशान करती है। Compose उस condition का मूल्यांकन केवल एक बार करता है, जब वह container बनाता है। यदि gluetun बाद में unhealthy हो जाता है, तो यह app को रोकता या restart नहीं करता है। इसके बजाय, gluetun का आंतरिक auto-healing उस स्थिति को संभालता है, यही कारण है कि यह container के बजाय VPN process को restart करता है।

सेटअप पर भरोसा करने से पहले DNS leak की जाँच करें

DNS (domain name system) वह leak है जो एक सही tunnel के बाद भी बनी रहती है। Gluetun अपने namespace के भीतर अपना resolver चलाता है और queries को डिफ़ॉल्ट रूप से DoT (DNS over TLS) के माध्यम से Cloudflare को forward करता है: DNS_UPSTREAM_RESOLVER_TYPE=dot और DNS_UPSTREAM_RESOLVERS=cloudflare। इन दोनों को न बदलें, इससे आपकी lookups encrypted रहेंगी और tunnel के माध्यम से यात्रा करेंगी।

जो setting इसे खराब करती है वह है DNS_UPSTREAM_PLAIN_ADDRESSES। जब कोई नाम resolve नहीं हो पाता, तो लोग इसका उपयोग करते हैं ताकि उनका router या provider का resolver जवाब दे सके। Gluetun documentation में इसका नुकसान स्पष्ट रूप से बताया गया है: सारा DNS traffic VPN tunnel से होकर नहीं जाएगा और बाहर leak हो जाएगा। आपका traffic private रहता है, लेकिन आपके द्वारा देखे गए hostnames की सूची नहीं। इसी तरह की गलती का WireGuard संस्करण DNS that stops resolving over a WireGuard tunnel में कवर किया गया है।

इसका परीक्षण करने के लिए, gluetun पर HTTPPROXY=on सेट करें और 8888:8888/tcp को publish करें, फिर एक browser को उस proxy पर point करें और DNS leak test लोड करें। परिणाम में आपके provider या Cloudflare का नाम होना चाहिए, न कि आपके home router का। Gluetun का अपना documentation चेतावनी देता है कि कुछ leak tests अजीब परिणाम दे सकते हैं, क्योंकि namespace के भीतर का resolver अंतिम जवाब देने वाले server के बजाय एक local caching intermediary होता है। यदि परिणाम में गलत देश या आपके अपने ISP का resolver दिखाई दे, तो इसे वास्तविक संकेत मानें।

VPN sidecar के साथ Tailscale जोड़ना, और कौन सा प्रभावी रहता है

Tailscale, WireGuard पर आधारित एक overlay network है जिसका उपयोग आप अपनी मशीनों तक पहुँचने के लिए करते हैं। लोग इसे अक्सर एक provider VPN के साथ चलाते हैं ताकि stack में एक admin path बना रहे। ये दोनों शायद ही कभी आपस में टकराते हैं, और इसका कारण समझना महत्वपूर्ण है। Tailscale का documentation डिफ़ॉल्ट स्थिति को स्पष्ट करता है: यह एक overlay network के रूप में कार्य करता है, यह केवल Tailscale चलाने वाले उपकरणों के बीच traffic को route करता है, और यह आपके public internet traffic को प्रभावित नहीं करता है।

इसलिए इसका उत्तर एक setting पर निर्भर करता है।

• Tailscale अपने स्वयं के container में, डिफ़ॉल्ट configuration के साथ: यह app के outbound traffic को कभी नहीं देखता है। सारा traffic Gluetun के माध्यम से ही जाता है। Tailscale app तक gluetun:8080 पर पहुँचता है, बिल्कुल किसी अन्य बाहरी container की तरह।
• Tailscale को network_mode: "service:gluetun" के साथ gluetun के namespace से जोड़ना: इसे net_admin और net_raw के अपने स्वयं के cap_add की आवश्यकता होती है, क्योंकि capabilities namespace के साथ नहीं आती हैं। डिफ़ॉल्ट userspace networking mode में, TS_USERSPACE चालू रहता है, tailscaled कोई interface नहीं बनाता है और SOCKS5 या HTTP proxy के रूप में काम करता है, इसलिए यह routing को बदल नहीं सकता है। Gluetun अभी भी सब कुछ carry करता है।
• वही स्थिति, TS_USERSPACE=false के साथ: tailscaled एक tunnel device बनाता है और routes install करता है, लेकिन केवल tailnet range 100.64.0.0/10 और उन subnet routes के लिए जिन्हें आप TS_ROUTES के साथ advertise करते हैं। Public traffic अभी भी gluetun के माध्यम से ही बाहर जाता है।
• ऊपर दी गई कोई भी स्थिति जिसमें exit node चुना गया हो, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale default route पर दावा करता है और प्रभावी हो जाता है। इसे gluetun के साथ न जोड़ें। एक default route, एक ही owner।

एक side effect तब दिखाई देता है जब Tailscale tunnel के अंदर चलता है। इसके peers को VPN provider का address दिखाई देता है, इसलिए उम्मीद करें कि यह अधिक बार relays पर निर्भर करेगा। जब ऐसा होता है, तो tailscale status एक peer के बगल में direct के बजाय relay "..." दिखाता है। connection काम करता है और यह धीमा होता है। यदि आपको वास्तव में केवल overlay की आवश्यकता है, तो plain WireGuard और Tailscale के बीच का अंतर बेहतर शुरुआती बिंदु है।

क्या खराब होता है, और आपको क्या संदेश दिखाई देगा

Docker ऐप कंटेनर बनाने से मना कर देता है। Error response from daemon: conflicting options: port publishing and the container type network mode का अर्थ है कि एक ports: ब्लॉक अभी भी अटैच्ड सर्विस पर मौजूद है। इसे gluetun पर ले जाएँ।

Compose पूरी फाइल को अस्वीकार कर देता है। कोई सर्विस एक साथ network_mode और networks दोनों सेट नहीं कर सकती। नेटवर्क्स को gluetun पर रखें।

कोई अन्य कंटेनर ऐप को रिजॉल्व नहीं कर पाता। curl: (6) Could not resolve host: qbittorrent सही व्यवहार है, क्योंकि अटैच्ड कंटेनर किसी नेटवर्क से नहीं जुड़ा और उसने कोई नाम रजिस्टर नहीं किया। gluetun और पोर्ट का उपयोग करें।

दूसरा अटैच्ड कंटेनर स्टार्ट नहीं होगा। एक ही नेमस्पेस में दो प्रोसेस एक ही पोर्ट को बाइंड नहीं कर सकते, और जो प्रोसेस हारता है वह रिपोर्ट करता है कि एड्रेस पहले से उपयोग में है। ऐप का इंटरनल पोर्ट बदलें, या दूसरा gluetun चलाएँ।

gluetun को छूने के बाद ऐप में नेटवर्क नहीं है। gluetun को रीस्टार्ट या रीक्रिएट करने से उससे जुड़ी हर चीज़ की कनेक्टिविटी खत्म हो जाती है। उन कंटेनर्स को रीस्टार्ट करें।

छोटे पेज लोड होते हैं और बड़े पेज हैंग हो जाते हैं। यह MTU (maximum transmission unit) है। टनल ओवरहेड जोड़ता है, और रास्ते में कोई चीज़ बिना एरर भेजे बड़े पैकेट को ड्रॉप कर देती है। WIREGUARD_MTU को कम करें, 1400 आज़माएँ, फिर 1320 का उपयोग करें।

gluetun कभी हेल्दी नहीं होता। स्टार्टअप चेक पहले संदिग्धों के नाम बताता है: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout। जाँचें कि क्या की (key) की समय-सीमा समाप्त हो गई है, फिर देखें कि क्या सर्वर लिस्ट पुरानी है, और अंत में जाँचें कि क्या आपका होस्ट फायरवॉल आउटबाउंड UDP को ब्लॉक कर रहा है।

FAQ

Gluetun के पीछे मेरे container के published ports काम करना क्यों बंद कर देते हैं?

क्योंकि network_mode: "service:gluetun" container को gluetun के network namespace के अंदर डाल देता है, और एक namespace में केवल एक IP address और listening ports का एक ही सेट होता है। App listen करना जारी रखता है, लेकिन publish rule को उस container पर होना चाहिए जो namespace का स्वामी है। ports: list को gluetun service पर ले जाएँ। यदि आपने इसे attached service पर छोड़ दिया, तो Docker उसे create भी नहीं करेगा: Error response from daemon: conflicting options: port publishing and the container type network mode।

मैं VPN tunnel के अंदर वाले container तक बाहर के container से कैसे पहुँचूँ?

Gluetun के service name और उस port का उपयोग करें जिस पर app listen करता है, उदाहरण के लिए gluetun:8080। Attached container का अपना कोई Docker network नहीं होता, इसलिए उसका अपना नाम कभी resolve नहीं होता। Container-to-container traffic के लिए कुछ भी publish करने की आवश्यकता नहीं है। दूसरी दिशा में, namespace के अंदर का container बाहर के container तक उसके service name, जैसे postgres:5432, के माध्यम से पहुँचता है (Gluetun v3.41 और नए संस्करणों पर)। एक अलग subnet पर मौजूद client, जैसे आपके LAN पर मौजूद laptop, को gluetun का firewall तब तक drop कर देता है जब तक आप उस subnet को FIREWALL_OUTBOUND_SUBNETS में न जोड़ दें।

क्या VPN drop होने पर Gluetun एक kill switch के रूप में काम करता है?

हाँ, और एक साथ दो कारणों से। Attached container के पास shared namespace में मौजूद route के अलावा कोई अन्य route नहीं होता, इसलिए 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 करता है, बजाय इसके कि वह exit करे, क्योंकि gluetun के restart होते ही हर attached container अपना network खो देता है।

एक ही stack में Tailscale और Gluetun: कौन सा outbound traffic ले जाता है?

Gluetun, एक को छोड़कर हर configuration में। Tailscale डिफ़ॉल्ट रूप से केवल आपके tailnet में मौजूद उपकरणों के बीच traffic route करता है और public traffic को नहीं छेड़ता। Container image के डिफ़ॉल्ट userspace mode में यह कोई interface ही नहीं बनाता, इसलिए यह routing को प्रभावित नहीं कर सकता। TS_USERSPACE=false के साथ यह केवल 100.64.0.0/10 और आपके द्वारा advertise किए गए subnets के लिए routes install करता है। अपवाद एक exit node है: sudo tailscale set --exit-node=<exit-node-ip> Tailscale को डिफ़ॉल्ट route बना देता है, और तब वह प्रभावी होता है। दोनों को एक साथ stack करने के बजाय, डिफ़ॉल्ट route के लिए किसी एक product को चुनें।