लेखक: Matt Connor 2026-11-09

Docker containers को VPN के माध्यम से कैसे रूट करें

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

क्योंकि network_mode: "service:gluetun" container को gluetun के network namespace के अंदर डाल देता है, और एक namespace में केवल एक IP address और listening ports का एक ही सेट होता है। App listening जारी रखती है, लेकिन 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।

Gluetun sidecar का उपयोग करते समय Docker containers के ports गायब होने का कारण shared network namespace है। इस लेख में सही docker-compose कॉन्फ़िगरेशन और समाधान दिया गया है।

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

Docker containers को VPN के माध्यम से route करने के लिए आप एक 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: block छोड़ देते हैं, तो Docker उसे बनाने से पूरी तरह मना कर देगा:

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

यहाँ उपयोग किया जाने वाला tool Gluetun है, जो एक ऐसा container है जो WireGuard या OpenVPN के माध्यम से एक commercial VPN (virtual private network) provider से जुड़ता है और अपना firewall साथ रखता है। अक्टूबर 2026 तक Release v3.41.3 वर्तमान है। उदाहरणों में WireGuard के साथ Mullvad का उपयोग किया गया है, इसलिए आपको अपने provider से एक 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: mode उस चरण को छोड़ देता है और 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 को reject कर देता है जहाँ एक 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 सीरीज का नवीनतम stable release है। :latest tag master branch के अंतिम commit को दर्शाता है, जो कि development edge है, इसलिए जिस मशीन पर आप मंगलवार को debug नहीं करना चाहते, उस पर :v3 को pin न करें।

WEBUI_PORT=8080 का published port से मेल खाना आवश्यक है, क्योंकि qBittorrent, gluetun के namespace के भीतर bind होता है और publish rule host traffic को वहां port 8080 पर भेजता है। एक भी नंबर बदलने पर 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 होना चाहिए। यदि यह आपके सर्वर का अपना address है, तो app tunnel के भीतर नहीं है, और नीचे दी गई कोई भी चीज़ बताए गए अनुसार काम नहीं करेगी।

Keys को compose file से बाहर रखें

gluetun.env क्रेडेंशियल्स को होल्ड करता है, और यह git से बाहर रहता है:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

दोनों values उस WireGuard कॉन्फ़िगरेशन फ़ाइल से आती हैं जिसे आप अपने प्रदाता के अकाउंट क्षेत्र में जनरेट करते हैं। फ़ाइल को mode 600 पर सेट करें। इस बात को लेकर स्पष्ट रहें कि इससे आपको क्या लाभ मिलता है: key आपके रिपॉजिटरी से बाहर रहती है, लेकिन docker inspect gluetun अभी भी हर environment variable को उस किसी भी व्यक्ति के लिए प्रिंट कर देता है जो 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 पर मौजूद लैपटॉप या अलग ब्रिज नेटवर्क पर मौजूद कंटेनर को gluetun के फ़ायरवॉल और रूटिंग द्वारा अनुमति प्राप्त रिटर्न पाथ की आवश्यकता होती है:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

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

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

किल स्विच: टनल ड्रॉप होने पर क्या होता है

यह पैटर्न विफलता के समय अपनी जटिलता को सार्थक करता है। अटैच किया गया कंटेनर Gluetun के इंटरफेस और राउटिंग टेबल को साझा करता है। Gluetun का फायरवॉल टनल के बाहर सामान्य इंटरनेट ट्रैफिक को ब्लॉक करता है, जबकि VPN सर्वर एंडपॉइंट, लोकल Docker ट्रैफिक और कॉन्फ़िगर किए गए अपवादों को अनुमति देता है। यही फायरवॉल टनल ड्रॉप होने पर plain इंटरफेस पर फॉलबैक को रोकता है। ऐसा कोई समय नहीं होता जब क्लाइंट के पुनः कनेक्ट होने के दौरान पैकेट plain इंटरफेस से लीक हों।

Gluetun अपने स्वयं के कनेक्शन की निगरानी करता है। हर मिनट यह HEALTH_ICMP_TARGET_IPS में दिए गए पतों पर एक ICMP echo (पिंग) भेजता है, जो डिफ़ॉल्ट रूप से 1.1.1.1,8.8.8.8 होते हैं। यदि ICMP की अनुमति नहीं है, तो यह छोटा चेक plaintext UDP DNS क्वेरी पर फॉलबैक कर जाता है। हर पांच मिनट में यह HEALTH_TARGET_ADDRESSES (डिफ़ॉल्ट cloudflare.com:443,github.com:443) पर एक पूर्ण TCP और TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) डायल करता है। जब ये विफल हो जाते हैं, तो यह कंटेनर के अंदर VPN को रीस्टार्ट करता है और इसे लॉग करता है:

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

इस क्रम को ध्यान में रखते हुए अटैच किए गए कंटेनर के लॉग पढ़ें। ऐप के अंदर connection refused, operation not permitted और i/o timeout जैसी लाइनें मृत टनल का परिणाम हैं, कारण नहीं। Gluetun का डॉक्यूमेंटेशन इसे स्पष्ट रूप से कहता है, क्योंकि लोग परिणाम की रिपोर्ट करते हैं और घंटों तक उसका पीछा करते रहते हैं।

HEALTH_RESTART_VPN=on डिफ़ॉल्ट है और इसे चालू रहना चाहिए। इसे केवल तभी बंद करें जब आप किसी विशिष्ट विफलता को डीबग कर रहे हों, क्योंकि इसे बंद करने पर मृत टनल मृत ही बनी रहती है।

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

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

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

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

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

एक सीमा लोगों को अक्सर परेशान करती है। Compose उस condition का मूल्यांकन तब करता है जब वह stack को start करता है। यदि 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 के माध्यम से यात्रा करेंगी।

जो सेटिंग इसे तब तोड़ देती है जब इसे local resolver की ओर point किया जाता है, वह है DNS_UPSTREAM_PLAIN_ADDRESSES। लोग इसका उपयोग तब करते हैं जब कोई name resolve नहीं हो पाता और वे चाहते हैं कि उनका router या provider का resolver उत्तर दे। Gluetun documentation चेतावनी देता है कि आपके Docker bridge या LAN पर स्थित resolver को भेजी गई queries VPN tunnel के बाहर leak हो जाती हैं। एक public plaintext resolver को queries tunnel के माध्यम से प्राप्त होती हैं, लेकिन VPN provider उन्हें पढ़ और बदल सकता है। इसी गलती का WireGuard संस्करण WireGuard tunnel पर DNS का resolve न होना में वर्णित है।

इसका परीक्षण करने के लिए, gluetun पर SHADOWSOCKS=on और SHADOWSOCKS_PASSWORD सेट करें, 8388:8388/tcp और 8388:8388/udp publish करें, फिर UDP DNS को tunnel करने के लिए configured Shadowsocks client से connect करें और एक DNS leak test load करें। परिणाम में आपके 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 बना रहे। एक ही namespace साझा करने का अर्थ है firewall rules साझा करना, इसलिए दोनों के लिए compatible firewall और routing settings का होना आवश्यक है। Tailscale का documentation डिफ़ॉल्ट स्थिति स्पष्ट करता है: यह एक overlay network के रूप में कार्य करता है, यह केवल Tailscale चलाने वाले उपकरणों के बीच traffic route करता है, और यह आपके public internet traffic को प्रभावित नहीं करता है।

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

Tailscale अपने स्वयं के container में, डिफ़ॉल्ट configuration के साथ: यह app के outbound traffic को नहीं देखता है। Gluetun ही सारा traffic ले जाता है। Tailscale container में चल रही एक process साझा Docker network पर gluetun:8080 पर app तक पहुँचती है; उस connection को tailnet clients के लिए expose करने हेतु forwarding या proxy की आवश्यकता होती है।
network_mode: "service:gluetun" के साथ gluetun के namespace से जुड़ा Tailscale: डिफ़ॉल्ट userspace networking mode में, TS_USERSPACE चालू रहता है, tailscaled कोई interface नहीं बनाता है और SOCKS5 या HTTP proxy के रूप में कार्य करता है, इसलिए यह routing को नहीं बदल सकता है। Gluetun अभी भी सामान्य outbound traffic ले जाता है जब तक कि कोई app स्पष्ट रूप से उस proxy का उपयोग न करे।
वही, TS_USERSPACE=false के साथ: Tailscale को अपने स्वयं के /dev/net/tun device और capabilities की आवश्यकता होती है क्योंकि वे namespace के साथ नहीं आते हैं। Tailscaled एक tunnel device बनाता है और, Linux पर, सामान्यतः 100.64.0.0/10 के लिए एक route के बजाय व्यक्तिगत IPv4 peer /32 routes install करता है। केवल TS_USERSPACE=false सेट करने से aggregate route सक्षम नहीं होता है। यह अन्य nodes के subnet routes तभी install करता है जब आप TS_EXTRA_ARGS के माध्यम से --accept-routes पास करते हैं। TS_ROUTES विपरीत दिशा में कार्य करता है: यह उन subnets को advertise करता है जिन तक यह container पहुँच सकता है, जो tailscale set --advertise-routes= के समान है, और यहाँ कोई route नहीं जोड़ता है। Public traffic अभी भी gluetun के माध्यम से ही बाहर जाता है।
Exit node चुने जाने पर gluetun के namespace में kernel networking, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale उस namespace में डिफ़ॉल्ट routes install करता है, लेकिन Gluetun का firewall उस path को block कर सकता है। एक अलग container में exit node चुनने से app के routes नहीं बदलते हैं, और userspace mode केवल उसी traffic को ले जाता है जिसे स्पष्ट रूप से इसके proxy के माध्यम से भेजा गया हो। Gluetun के namespace में प्रतिस्पर्धा करने वाले डिफ़ॉल्ट routes को न मिलाएं। एक डिफ़ॉल्ट route, एक ही owner।

यदि उन advertised routes का उपयोग करना ही मुख्य उद्देश्य है, और आप केवल box के बजाय box के पीछे के पूरे private network तक पहुँचना चाहते हैं, तो VPS पर Tailscale subnet router चलाना route approval, IP forwarding और उस client side flag को कवर करता है जिसे TS_ROUTES अकेले पूरा नहीं करता है।

यदि Tailscale का उद्देश्य route के बजाय admin URL प्रदान करना है, तो tailscale serve और tailscale funnel एक local HTTP service के सामने HTTPS लगा देते हैं, जिसमें केवल funnel ही इसे public internet के लिए खोलता है। Tailscale v1.104.5 में, उनके HTTP reverse proxies सीधे http://gluetun:8080 को स्वीकार करते हैं जब Tailscale container साझा Docker network पर उस तक पहुँच सकता है। Non-localhost target के लिए http:// scheme शामिल करें। Gluetun के network namespace को साझा करना और http://127.0.0.1:8080 को target करना भी काम करता है।

इसका एक दुष्प्रभाव तब दिखता है जब 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 की जाँच करें, जिसका v3.41.3 में डिफ़ॉल्ट 1320 है, और यदि पाथ को छोटे पैकेट्स की आवश्यकता है तो इसे कम करें। जब यह सेटिंग सेट नहीं होती है, तो डेवलपमेंट इमेज पाथ MTU डिस्कवरी का उपयोग करती है।

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 listening जारी रखती है, लेकिन 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 और routing द्वारा अनुमति प्राप्त return path की आवश्यकता होती है; उस subnet को FIREWALL_OUTBOUND_SUBNETS में जोड़ें।

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

हाँ, यदि इसका firewall enabled है। Attached container, Gluetun के interfaces और routes को साझा करता है, और firewall tunnel के बाहर के सामान्य internet traffic को रोकता है, जबकि VPN server endpoint, local Docker traffic और configured exceptions को अनुमति देता है। 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 सामान्य outbound traffic ले जाता है जब तक कि आप उसे स्पष्ट रूप से Tailscale के माध्यम से न भेजें। Tailscale डिफ़ॉल्ट रूप से केवल आपके tailnet में मौजूद devices के बीच traffic route करता है और public traffic को नहीं छेड़ता। Container image के डिफ़ॉल्ट userspace mode में यह कोई interface create नहीं करता, इसलिए यह routing को प्रभावित नहीं कर सकता। TS_USERSPACE=false के साथ, Linux को सामान्यतः aggregate 100.64.0.0/10 route के बजाय व्यक्तिगत IPv4 peer /32 routes मिलते हैं, साथ ही अन्य nodes के subnet routes केवल तभी मिलते हैं यदि आप --accept-routes के माध्यम से TS_EXTRA_ARGS जोड़ते हैं। TS_ROUTES इस container के subnets को आपके tailnet में advertise करता है और कोई local route नहीं जोड़ता। sudo tailscale set --exit-node=<exit-node-ip> के साथ exit node चुनने पर डिफ़ॉल्ट routes केवल उसी namespace में install होते हैं जो Tailscale के kernel networking का उपयोग कर रहा हो; एक अलग container app के routes को नहीं बदलता है, और userspace mode केवल उसके proxy के माध्यम से भेजे गए traffic को ही ले जाता है। दोनों को एक साथ stack करने के बजाय डिफ़ॉल्ट route के लिए एक ही product चुनें।

क्या यह लेख उपयोगी था?

#Docker #gluetun #vpn #नेटवर्किंग #wireguard