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

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

Docker containers को VPN के माध्यम से रूट करने के लिए आप एक container को tunnel प्रदान करते हैं, और फिर अन्य containers को 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 port को टच नहीं करता है।

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

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 के साथ बनाए गए मीडिया स्टैक अधूरा छोड़ देते हैं।

किल स्विच: टनल बंद होने पर क्या होता है

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

Gluetun अपने स्वयं के कनेक्शन की निगरानी करता है। हर मिनट यह HEALTH_ICMP_TARGET_IPS में दिए गए पतों पर एक ICMP echo (पिंग) भेजता है, जो डिफ़ॉल्ट रूप से 1.1.1.1,8.8.8.8 होते हैं। हर पांच मिनट में यह HEALTH_TARGET_ADDRESSES पर एक पूर्ण TCP और TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) डायल करता है, जो डिफ़ॉल्ट रूप से cloudflare.com:443,github.com:443 है। जब ये विफल हो जाते हैं, तो यह कंटेनर के अंदर 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 के चालू होने से पहले 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 त्रुटि string के साथ 500 Internal server error का उत्तर देती है, और एक ही विफलता के बाद 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 चलाता है और डिफ़ॉल्ट रूप से DoT (DNS over TLS) के माध्यम से Cloudflare को queries forward करता है: DNS_UPSTREAM_RESOLVER_TYPE=dot और DNS_UPSTREAM_RESOLVERS=cloudflare। इन दोनों को न बदलें, तो आपकी lookups encrypted रहेंगी और tunnel से होकर गुजरेंगी।

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

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

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

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

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

• Tailscale अपने स्वयं के container में, डिफ़ॉल्ट configuration के साथ: यह app के outbound traffic को नहीं देखता है। Gluetun ही सारा traffic संभालता है। Tailscale app तक gluetun:8080 पर पहुँचता है, ठीक वैसे ही जैसे कोई अन्य बाहरी container पहुँचता है।
• Tailscale को network_mode: "service:gluetun" के साथ gluetun के namespace से जोड़ना: इसे net_admin और net_raw के अपने स्वयं के cap_add की आवश्यकता होती है, क्योंकि namespace के साथ capabilities नहीं मिलती हैं। डिफ़ॉल्ट userspace networking mode में, TS_USERSPACE चालू रहता है, tailscaled कोई interface नहीं बनाता है और SOCKS5 या HTTP proxy के रूप में कार्य करता है, इसलिए यह routing को नहीं बदल सकता है। Gluetun ही सब कुछ संभालता है।
• वही स्थिति, 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 का केवल एक ही स्वामी हो सकता है।

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

यदि Tailscale का उद्देश्य route के बजाय admin URL प्रदान करना है, तो tailscale serve and tailscale funnel आपके tailnet के लिए gluetun:8080 के सामने HTTPS लगा देते हैं, जिसमें केवल funnel ही इसे public internet के लिए खोलता है।

इसका एक दुष्प्रभाव तब दिखता है जब Tailscale tunnel के अंदर चलता है। इसके peers को VPN provider का address दिखता है, इसलिए उम्मीद करें कि यह अक्सर relays पर निर्भर रहेगा। जब ऐसा होता है, तो tailscale status एक peer के बगल में relay "..." दिखाता है, न कि direct। connection काम करता है लेकिन यह धीमा होता है। यदि आपको वास्तव में केवल overlay की ही आवश्यकता है, तो the difference between plain WireGuard and 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 इसे बनाएगा भी नहीं: 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, का traffic 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 कौन ले जाता है?

एक को छोड़कर हर configuration में Gluetun ही traffic ले जाता है। Tailscale डिफ़ॉल्ट रूप से केवल आपके tailnet में मौजूद devices के बीच 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 करने के बजाय किसी एक product को डिफ़ॉल्ट route का स्वामी चुनें।