Gluetun container से host और अन्य services तक कैसे पहुँचें

जब कोई container gluetun के network से जुड़ता है तो क्या होता है

जो container network_mode: service:gluetun सेट करता है, उसका अपना कोई network interface नहीं होता। वह gluetun के network namespace में शामिल हो जाता है, इसलिए port publishing और firewall rules उस container की विशेषता न रहकर gluetun service की विशेषता बन जाते हैं। नीचे दिए गए सभी उत्तर इसी एक तथ्य पर आधारित हैं।

Network namespace, kernel के network stack की एक निजी प्रतिलिपि होती है: इसके अपने interfaces, अपनी routing table, अपने firewall rules और अपने listening sockets होते हैं। Docker डिफ़ॉल्ट रूप से प्रत्येक container को एक namespace देता है। जब आप network_mode: service:gluetun लिखते हैं, तो Docker उस चरण को छोड़ देता है और नए container को उस namespace के अंदर डाल देता है जिसे gluetun पहले से नियंत्रित करता है। container अपनी filesystem और अपनी /etc/hosts फ़ाइल को बनाए रखता है, और वह दूसरी फ़ाइल बाद में महत्वपूर्ण हो जाती है।

आप इसे सीधे देख सकते हैं।

docker inspect -f '{{.HostConfig.NetworkMode}}' qbittorrent

यह container: और उसके बाद gluetun container ID को प्रिंट करता है, जबकि एक सामान्य container bridge प्रिंट करेगा। यह मार्गदर्शिका वहाँ से शुरू होती है जहाँ gluetun के साथ Docker traffic को VPN के माध्यम से रूट करना समाप्त होता है: tunnel काम कर रही है, और अब container से कोई भी संपर्क नहीं कर सकता।

Port को application पर नहीं, gluetun पर publish करें

Service पर एक ports: ब्लॉक छोड़ें जो network_mode सेट करता हो, तो Docker container बनाने से मना कर देगा:

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

इसका कारण सीधा है। Port publish करने का अर्थ है एक NAT (network address translation) नियम जोड़ना, जो host port को container के अपने network namespace में forward करता है, और इस container का अपना कोई namespace नहीं होता। Mapping को gluetun service पर ले जाएँ। Port number नहीं बदलता, क्योंकि application अभी भी shared namespace के भीतर उसी port पर listen कर रही है।

services:
  gluetun:
    ports:
      - "8080:8080/tcp"   # qBittorrent web UI

  qbittorrent:
    network_mode: "service:gluetun"
    # no ports: block here

Dependent service पर एक expose: ब्लॉक भी व्यर्थ है, और वहाँ एक networks: ब्लॉक एक hard stop है: Compose रिपोर्ट करता है कि service परस्पर विरोधी network_mode और networks घोषित करती है, और file को load करने से पूरी तरह मना कर देती है।

इसका एक परिणाम बाद में सामने आता है। Namespace में प्रत्येक container एक single port space साझा करता है, इसलिए दो applications जो दोनों default रूप से 8080 पर चलती हैं, आपस में टकराती हैं, और दूसरी service start होने पर address already in use error के साथ fail हो जाती है। उनमें से एक को उसकी अपनी configuration में बदलें, उदाहरण के लिए LinuxServer qBittorrent image पर WEBUI_PORT variable, फिर gluetun पर नया number publish करें।

gluetun के पीछे मौजूद containers एक-दूसरे तक कैसे पहुँचते हैं?

Namespace के अंदर वे पहले से ही एक loopback interface साझा करते हैं। gluetun के पीछे का एक container अपने sibling तक 127.0.0.1:<port> पर पहुँचता है, जिसमें किसी Docker network की आवश्यकता नहीं होती।

Namespace के बाहर से, container का कोई नाम नहीं होता। Docker का embedded DNS किसी service name को user-defined network पर उस service के address में resolve करता है, और इस container का किसी भी network पर कोई address नहीं होता। इसलिए Sonarr जैसा एक सामान्य container, torrent client तक http://qbittorrent:8080 पर नहीं पहुँचता। यह उस तक http://gluetun:8080 पर पहुँचता है, क्योंकि socket gluetun के namespace में, gluetun के address पर listen कर रहा होता है। यह उन लोगों को आश्चर्यचकित करता है जो Docker Compose networks और service names कैसे काम करते हैं जानते हैं और सामान्य naming लागू होने की अपेक्षा करते हैं। यह host पर कुछ भी publish किए बिना भी काम करता है, क्योंकि दोनों containers एक ही Compose network पर होते हैं।

किसी भी अन्य चीज़ को debug करने से पहले DNS की जाँच करें। gluetun अपना खुद का resolver चलाता है और अपने container में /etc/resolv.conf को rewrite करता है, लेकिन /etc/resolv.conf प्रति-container file होती है, इसलिए gluetun द्वारा लिखी गई file वह नहीं है जिसे आपका application पढ़ता है।

docker exec qbittorrent cat /etc/resolv.conf

Docker host पर चल रही service तक कैसे पहुँचें?

इसके लिए host.docker.internal का उपयोग करें। इसमें दो अलग-अलग स्थानों पर दो सेटिंग्स की आवश्यकता होती है, क्योंकि दो अलग-अलग चीजें काम नहीं कर रही होती हैं।

नाम पहले आता है। /etc/hosts प्रति container होता है, इसलिए extra_hosts एंट्री application container पर होनी चाहिए, न कि gluetun पर।

  prowlarr:
    network_mode: "service:gluetun"
    extra_hosts:
      - "host.docker.internal:host-gateway"

host-gateway एक विशेष मान है जिसे Docker host के आंतरिक पते से बदल देता है। एक सामान्य Linux Docker install पर यह docker0 bridge का पता होता है, जो आमतौर पर 172.17.0.1 होता है। VPS पर ip -4 addr show docker0 के साथ इसकी पुष्टि करें। Docker Desktop इस नाम को स्वयं resolve कर लेता है, यही कारण है कि laptop पर लिखे गए guides extra_hosts लाइन को छोड़ देते हैं और वही file server पर विफल हो जाती है।

रूट दूसरे स्थान पर आता है। नाम जोड़ने से container को केवल यह पता चलता है कि किस पते का उपयोग करना है। packet अभी भी gluetun के default route, यानी tunnel के माध्यम से बाहर निकलता है, और gluetun का firewall उसे drop कर देता है। इसका लक्षण यह है कि connection hang हो जाता है और फिर time out हो जाता है, न कि यह कि उसे अस्वीकार (refuse) कर दिया गया हो। अस्वीकृति का अर्थ है कि packet पहुँच गया और किसी ने 'नहीं' में उत्तर दिया। time out का अर्थ है कि वह कभी पहुँचा ही नहीं।

  gluetun:
    environment:
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32

फिर जाँचें कि host service वास्तव में उस पते पर listen कर रही है या नहीं। केवल 127.0.0.1 पर bound PostgreSQL server किसी भी container से पहुँच योग्य नहीं होता है, चाहे tunnel हो या न हो, क्योंकि namespace के अंदर 127.0.0.1 उस namespace का अपना loopback होता है। इसके बजाय इसे 172.17.0.1 पर bind करें: यह public interface से दूर रहते हुए containers से connections स्वीकार करता है। host पर ss -lntp | grep 5432 के साथ इसकी पुष्टि करें।

FIREWALL_OUTBOUND_SUBNETS वास्तव में क्या बदलता है

gluetun का documentation इसे उन comma-separated subnets के रूप में वर्णित करता है जिन्हें gluetun और इसके network stack को साझा करने वाले containers एक्सेस कर सकते हैं। यह नोट करता है कि इसमें firewall और routing में बदलाव शामिल हैं। दोनों हिस्से महत्वपूर्ण हैं। Gluetun प्रत्येक सूचीबद्ध subnet के लिए Docker bridge gateway के माध्यम से एक route जोड़ता है, ताकि उन addresses के लिए packets tunnel के बजाय eth0 पर बाहर निकलें। यह उनके लिए firewall भी खोलता है, क्योंकि अन्यथा gluetun उस outbound traffic को drop कर देता है जो VPN server के लिए नहीं होता है।

value को commas के बाद बिना किसी space के लिखें।

      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,192.168.1.0/24,100.64.7.9/32

दो properties को अनदेखा करना आसान है। यह एक namespace level की setting है, इसलिए यह केवल आपके द्वारा सोचे गए container पर ही नहीं, बल्कि gluetun के पीछे के हर container पर लागू होती है। और यह केवल outbound है: यह उन connections को नियंत्रित करती है जिन्हें एक container शुरू करता है। published port पर आने वाले connections एक अलग रास्ते से आते हैं और उन्हें यहाँ किसी entry की आवश्यकता नहीं होती है।

Tailscale peer से web UI तक पहुँचना

Tailscale प्रत्येक machine को 100.64.0.0/10 में एक address देता है। यह range carrier grade NAT के लिए reserved है। Personal tailnet पर इसकी कोई लागत नहीं होती। हालांकि, free plan की user और device limits यह तय करती हैं कि जब अन्य लोगों को उन्हीं UIs का access चाहिए हो, तब भी यह बात लागू रहेगी या नहीं। Billing में machines के बजाय users की गिनती होती है। इसलिए वास्तव में paid tailnet की लागत कितनी होती है यह इस पर निर्भर करती है कि आप कितने लोगों को invite करते हैं, न कि इस पर कि कितने containers उनके लिए expose करते हैं। दोनों दिशाओं के लिए अलग-अलग काम करना पड़ता है।

Inbound (आने वाला traffic) सरल है। Gluetun पर 8080:8080 को publish करने से वह port host के सभी पतों पर bind हो जाता है, और host का tailscale0 interface उनमें से एक है, इसलिए एक peer http://<machine-name>:8080 खोलता है और container तक पहुँच जाता है। उस रास्ते में Gluetun की कोई भूमिका नहीं होती, क्योंकि Docker का NAT rule host पर, namespace के बाहर स्थित होता है।

UI को केवल tailnet पर ही सुलभ बनाने के लिए, published port को हर पते के बजाय host के Tailscale पते पर bind करें।

    ports:
      - "100.101.102.103:8080:8080/tcp"

उस पते को host पर tailscale ip -4 के साथ ढूँढें। यहाँ binding, firewall rule की तुलना में अधिक मजबूत नियंत्रण है, क्योंकि port public interface पर कभी खुलता ही नहीं है। यदि आप host और port के बजाय HTTPS नाम पर UI तक पहुँचना पसंद करते हैं, तो tailscale serve उस published port के सामने लग सकता है, हालाँकि serve और funnel में यह अंतर होता है कि अंत में कौन उस तक पहुँच सकता है और दोनों में से केवल एक ही UI को tailnet पर रखता है। यह Docker द्वारा ufw को दरकिनार कर सीधे port publish करने की समस्या से भी बचाता है।

Outbound (बाहर जाने वाला traffic) वह जगह है जहाँ FIREWALL_OUTBOUND_SUBNETS वापस आता है। यदि किसी container को किसी peer को call करना है, तो उस peer का पता जोड़ें, और पूरे /10 के बजाय प्रति peer /32 को प्राथमिकता दें। यदि आप जिस मशीन को call कर रहे हैं वह आपके tailnet पर उस subnet को advertise करने वाले VPS के माध्यम से पहुँचे जाने वाले private network पर स्थित है, तो router के स्वयं के 100.x पते के बजाय advertised range को सूचीबद्ध करें, और पुष्टि करें कि host ने स्वयं उन routes को स्वीकार कर लिया है। MagicDNS नाम container के अंदर resolve नहीं होंगे, क्योंकि container host के resolver का उपयोग नहीं करता है, इसलिए संख्यात्मक 100.x पते का उपयोग करें या इसे extra_hosts line के साथ pin करें। यही बात तब भी लागू होती है जब आप Headscale के साथ अपना स्वयं का Tailscale control server चलाते हैं।

सामान्य संरचना के लिए एक पूर्ण compose फाइल

VPN के पीछे एक डाउनलोड क्लाइंट, केवल tailnet पर प्रतिक्रिया देने वाले दो वेब UI, और एक कंटेनर जो होस्ट पर चल रहे PostgreSQL डेटाबेस को पढ़ता है।

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - "127.0.0.1:8000:8000/tcp"        # gluetun control server, host only
      - "100.101.102.103:8080:8080/tcp"  # qBittorrent UI, tailnet only
      - "100.101.102.103:9696:9696/tcp"  # Prowlarr UI, tailnet only
    volumes:
      - ./gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - WIREGUARD_ADDRESSES=${WIREGUARD_ADDRESSES}
      - SERVER_CITIES=Amsterdam
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,100.64.7.9/32
      - TZ=Europe/Amsterdam
    restart: unless-stopped

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

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    network_mode: "service:gluetun"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - PROWLARR__POSTGRES__HOST=host.docker.internal
      - PROWLARR__POSTGRES__PORT=5432
      - PROWLARR__POSTGRES__USER=prowlarr
      - PROWLARR__POSTGRES__PASSWORD=${PROWLARR_DB_PASSWORD}
      - PROWLARR__POSTGRES__MAINDB=prowlarr-main
      - PROWLARR__POSTGRES__LOGDB=prowlarr-log
    volumes:
      - ./prowlarr:/config
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

उत्पाद के नामों के बजाय पैटर्न के लिए फाइल को पढ़ें। दोनों UI gluetun पर पब्लिश किए गए हैं और होस्ट के tailnet पते से बंधे हैं, इसलिए वे केवल Tailscale पर ही प्रतिक्रिया देते हैं। केवल Prowlarr में extra_hosts लाइन शामिल है, क्योंकि Prowlarr वह कंटेनर है जो host.docker.internal को रिज़ॉल्व करता है। FIREWALL_OUTBOUND_SUBNETS दो एकल पतों को नामित करता है: होस्ट का Docker ब्रिज पता, ताकि Prowlarr डेटाबेस कनेक्शन खोल सके, और एक tailnet पीयर।

PostgreSQL सर्वर जानबूझकर फाइल में नहीं है। यह VPS पर एक सामान्य सिस्टम सर्विस के रूप में चलता है जो 172.17.0.1:5432 पर लिसन करता है। यह Docker Compose पर एक arr स्टैक के समान लेयरिंग है, जिसमें डेटाबेस को Docker के बाहर रखा गया है।

WireGuard प्राइवेट की को compose फाइल से बाहर रखें। ${WIREGUARD_PRIVATE_KEY} अपने बगल में स्थित एक .env फाइल से पढ़ता है, यह पैटर्न Docker Compose के लिए env फाइलें और सीक्रेट्स में कवर किया गया है। condition: service_healthy क्लॉज उस हेल्थचेक का उपयोग करता है जो gluetun इमेज में पहले से ही मौजूद है, इसलिए जब तक टनल के चालू होने की रिपोर्ट नहीं मिलती, तब तक कुछ भी शुरू नहीं होता। Compose हेल्थचेक इसके सामान्य स्वरूप की व्याख्या करते हैं।

    ports:
      - "8080:8080/tcp"

पुष्टि करें कि टनल अभी भी ट्रैफिक ले जा रही है

एक ही request को दो बार चलाएं, एक बार namespace के अंदर से और एक बार host से, और फिर तुलना करें।

docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org
curl -s https://api.ipify.org

पहली request को आपके VPN प्रदाता का exit address दिखाना चाहिए। दूसरी को VPS का address दिखाना चाहिए। यदि वे मेल खाते हैं, तो container का ट्रैफिक टनल से होकर नहीं जा रहा है, और इस गाइड का कोई भी सुधार तब तक व्यर्थ है जब तक इसे ठीक नहीं किया जाता।

Routing table दिखाती है कि क्या टनल से बाहर है और क्या नहीं।

docker run --rm --network=container:gluetun alpine:3.22 ip route show

Default route को टनल इंटरफ़ेस, tun0 की ओर इशारा करना चाहिए। इसके नीचे आपको FIREWALL_OUTBOUND_SUBNETS में प्रत्येक प्रविष्टि के लिए एक route दिखना चाहिए, जो Docker bridge gateway की ओर इशारा करता हो। eth0 के माध्यम से बाहर जाने वाला कोई भी अन्य route वह ट्रैफिक है जो VPN को छोड़ देता है।

Gluetun का control server पोर्ट 8000 पर, /v1/publicip/ip पर वही public IP रिपोर्ट करता है। हाल के संस्करणों में आपको control server routes के लिए authentication कॉन्फ़िगर करने की आवश्यकता होती है, इसलिए उस पर निर्भर होने से पहले उसे सेट अप करें।

गलत सबनेट से होने वाला लीक

FIREWALL_OUTBOUND_SUBNETS फायरवॉल में जानबूझकर किया गया एक छेद है, इसलिए छेद का आकार ही जोखिम का आकार है। इसे बहुत बड़ा बनाने के चार तरीके:

• 0.0.0.0/0 सब कुछ टनल के बाहर भेज देता है। ऊपर दिए गए दो IP चेक पहली बार में ही इसे पकड़ लेते हैं, क्योंकि वे एक ही एड्रेस लौटाएंगे।
• लक्ष्य से अधिक विस्तृत रेंज। 10.0.1.7 पर एक मशीन तक पहुँचने के लिए 10.0.0.0/8 को खोलना उन सभी एड्रेस को भी खोल देता है जिन्हें कोई टोरेंट पीयर उस रेंज में विज्ञापित कर सकता है। 10.0.1.7/32 लिखें।
• ऐसी रेंज जो टनल के अपने एड्रेस के साथ ओवरलैप करती हो। gluetun का डॉक्यूमेंटेशन चेतावनी देता है कि इससे gluetun VPN ट्रैफिक को ब्रिज के माध्यम से बाहर भेज देता है, जिससे पोर्ट फॉरवर्डिंग टूट जाती है। किसी भी प्राइवेट रेंज को खोलने से पहले अपने WIREGUARD_ADDRESSES मान की जाँच करें।
• Tailscale के लिए 100.64.0.0/10। यह लगभग चालीस लाख एड्रेस खोल देता है ताकि एक पीयर तक पहुँचा जा सके। जिन पीयर्स की आपको आवश्यकता है, उन्हें /32 प्रविष्टियों के रूप में सूचीबद्ध करें।

याद रखें कि यह सेटिंग पूरे नेमस्पेस को कवर करती है। एक सबनेट को खोलना ताकि इंडेक्सर किसी होस्ट सर्विस तक पहुँच सके, उसी सबनेट को उस नेमस्पेस को साझा करने वाले टोरेंट क्लाइंट के लिए भी खोल देता है। इस वेरिएबल में हर बदलाव के बाद पब्लिक IP चेक को दोबारा चलाएं, क्योंकि यही एकमात्र परीक्षण है जो यह दिखाता है कि बदलाव ने वही किया जो आप चाहते थे।

gluetun को restart करने पर क्या खराब होता है

gluetun namespace का स्वामी होता है, इसलिए gluetun का lifecycle ही namespace का lifecycle है। जब gluetun बंद हो, तो उस पर निर्भर container को start करने का प्रयास तुरंत विफल हो जाता है:

Error response from daemon: cannot join network of a non running container

gluetun को उसी स्थान पर restart करना एक शांत विफलता (quieter failure) है। निर्भर containers चलते रहते हैं, जबकि जिस namespace से वे जुड़े थे, उसे उनके नीचे से ही फिर से बनाया (rebuild) जा रहा होता है। इस कारण docker ps सब कुछ सही (healthy) बताता है, लेकिन कोई भी response नहीं मिलता। gluetun service में किसी भी बदलाव के बाद, किसी एक हिस्से को restart करने के बजाय पूरे group को फिर से बनाएँ (recreate)।

docker compose up -d --force-recreate

यही बात image updates पर भी लागू होती है। gluetun की नई image pull करना और केवल उस एक service को recreate करने से बाकी services ऐसे namespace की ओर संकेत करती हैं जो अब अस्तित्व में ही नहीं है।

FAQ

Docker "port publishing and the container type network mode" क्यों कहता है?

क्योंकि एक ports: ब्लॉक अभी भी उस सर्विस पर है जो network_mode: service:gluetun को भी सेट करती है। पोर्ट पब्लिश करने से एक NAT नियम जुड़ जाता है जो होस्ट पोर्ट को कंटेनर के अपने नेटवर्क नेमस्पेस में फॉरवर्ड करता है, और इस मोड में कंटेनर के पास अपना नेमस्पेस नहीं होता है। उस सर्विस से ports: ब्लॉक को हटा दें और वही मैपिंग gluetun सर्विस में जोड़ दें। पोर्ट नंबर वही रहेगा, क्योंकि एप्लिकेशन अभी भी शेयर्ड नेमस्पेस के अंदर उसी पर लिसन कर रही है।

gluetun के पीछे स्थित सर्विस तक अन्य कंटेनर कैसे पहुँचते हैं?

एक ही नेमस्पेस के अंदर के कंटेनर एक-दूसरे तक 127.0.0.1 पर पहुँचते हैं। इसके बाहर के कंटेनर gluetun सर्विस नाम का उपयोग करते हैं, इसलिए http://gluetun:8080 काम करता है जबकि http://qbittorrent:8080 नहीं। एप्लिकेशन कंटेनर के पास किसी भी Docker नेटवर्क पर कोई एड्रेस नहीं होता है, इसलिए एम्बेडेड DNS सर्वर के पास उसके नाम के लिए रिजॉल्व करने हेतु कुछ नहीं होता है। इसके लिए किसी पोर्ट पब्लिशिंग की आवश्यकता नहीं है, बशर्ते दोनों कंटेनर एक ही Compose नेटवर्क साझा करते हों।

मुझे FIREWALL_OUTBOUND_SUBNETS में क्या डालना चाहिए?

केवल वे एड्रेस जिन्हें gluetun के पीछे के कंटेनर को कनेक्शन शुरू करने की आवश्यकता है, उन्हें यथासंभव सटीक रूप से लिखें। एक सिंगल मशीन एक /32 है। दो सामान्य प्रविष्टियाँ 172.17.0.1/32 पर Docker होस्ट और आपके द्वारा कॉल किए जाने वाले प्रत्येक Tailscale पीयर के लिए एक /32 हैं। कभी भी 0.0.0.0/0 न जोड़ें, और कभी भी ऐसी रेंज न जोड़ें जो आपके VPN के अपने टनल एड्रेस के साथ ओवरलैप हो। पब्लिश किए गए पोर्ट पर आने वाले इनबाउंड कनेक्शन के लिए यहाँ किसी प्रविष्टि की आवश्यकता नहीं है।

कंटेनर मेरे Tailscale MagicDNS नामों को रिजॉल्व क्यों नहीं कर पा रहा है?

MagicDNS होस्ट के रिजॉल्वर को Tailscale के DNS सर्वर की ओर पॉइंट करके काम करता है, और कंटेनर होस्ट के रिजॉल्वर का उपयोग नहीं करता है। यह उसका उपयोग करता है जो इसका अपना /etc/resolv.conf कहता है, जो gluetun के पीछे gluetun का DNS सेटअप है। docker exec <container> cat /etc/resolv.conf के साथ पुष्टि करें। पीयर के संख्यात्मक 100.x एड्रेस का उपयोग करें, या उस कंटेनर पर extra_hosts प्रविष्टि के साथ नाम को पिन करें।

मैं यह कैसे पुष्टि करूँ कि ट्रैफ़िक अभी भी VPN के माध्यम से जा रहा है?

नेमस्पेस के अंदर से एक रिक्वेस्ट चलाएँ और होस्ट से वही रिक्वेस्ट चलाएँ, फिर उत्तरों की तुलना करें। docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org को आपके VPN प्रदाता का एग्जिट एड्रेस दिखाना चाहिए, जबकि VPS पर curl -s https://api.ipify.org को VPS का एड्रेस दिखाना चाहिए। दो मेल खाते उत्तरों का मतलब है कि टनल कंटेनर के ट्रैफ़िक को नहीं ले जा रही है। FIREWALL_OUTBOUND_SUBNETS में हर बदलाव के बाद इस जाँच को फिर से चलाएँ।