Gluetun سے host اور دوسرے containers تک رسائی

جب کوئی container gluetun کے network میں شامل ہوتا ہے

network_mode: service:gluetun set کرنے والے container کا اپنا کوئی 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 کو بطور default ایک network namespace دیتا ہے۔ جب آپ network_mode: service:gluetun لکھتے ہیں تو Docker یہ مرحلہ چھوڑ دیتا ہے اور نئے container کو اس namespace کے اندر رکھ دیتا ہے جس پر gluetun پہلے ہی قبضہ رکھتا ہے۔ Container اپنا filesystem اور اپنی /etc/hosts file برقرار رکھتا ہے، اور بعد میں یہی دوسری file اہم ہوتی ہے۔

آپ اسے براہ راست دیکھ سکتے ہیں۔

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

یہ output container: اور اس کے بعد gluetun container ID دکھاتا ہے، جبکہ عام container میں bridge دکھایا جاتا۔ یہ رہنما اسی مقام سے آگے بڑھتا ہے جہاں gluetun کے ذریعے Docker traffic کو VPN سے route کرنا ختم ہوتا ہے: tunnel کام کر رہا ہے، اور اب کوئی چیز container سے رابطہ نہیں کر سکتی۔

gluetun پر port publish کریں، application پر نہیں

اس service میں ports: block رکھنے سے، جو network_mode set کرتا ہے، Docker container بنانے سے انکار کر دیتا ہے:

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

وجہ واضح ہے۔ Port publish کرنے کا مطلب NAT (network address translation) rule شامل کرنا ہے، جو host port سے container کے اپنے network namespace میں forwarding کرتا ہے، لیکن اس container کا اپنا network namespace موجود نہیں ہے۔ Mapping کو gluetun service میں منتقل کریں۔ Port number تبدیل نہیں ہوگا، کیونکہ application مشترکہ namespace کے اندر اسی port پر listening کر رہی ہے۔

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

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

Dependent service میں expose: block رکھنا بھی بے فائدہ ہے، جبکہ وہاں networks: block رکھنا execution روک دیتا ہے۔ Compose رپورٹ کرتا ہے کہ service باہمی طور پر ناقابلِ استعمال network_mode اور networks کا اعلان کرتی ہے، اور file کو مکمل طور پر load کرنے سے انکار کر دیتا ہے۔

اس کا ایک اثر بعد میں سامنے آتا ہے۔ Namespace میں موجود ہر container ایک ہی port space استعمال کرتا ہے۔ اس لیے اگر دو applications کا default port 8080 ہو تو ان میں تصادم ہوگا، اور دوسری شروع ہونے والی application address already in use error کے ساتھ fail ہو جائے گی۔ ان میں سے ایک کی اپنی configuration میں port تبدیل کریں، مثلاً LinuxServer qBittorrent image میں WEBUI_PORT variable تبدیل کریں، پھر gluetun پر نیا number publish کریں۔

گلوٹن کے پیچھے موجود 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 پر listening کر رہا ہوتا ہے۔ جو لوگ Docker Compose networks اور service names کے کام کرنے کا طریقہ جانتے ہیں، ان کے لیے یہ بات غیر متوقع ہو سکتی ہے، کیونکہ وہ توقع کرتے ہیں کہ معمول کا naming طریقہ یہاں بھی لاگو ہوگا۔ یہ host پر کچھ بھی publish کیے بغیر بھی کام کرتا ہے، کیونکہ دونوں containers ایک ہی Compose network پر ہوتے ہیں۔

کسی بھی دوسری debugging سے پہلے DNS چیک کریں۔ Gluetun اپنا resolver چلاتا ہے اور اپنے container میں /etc/resolv.conf کو دوبارہ لکھتا ہے، لیکن /etc/resolv.conf ہر container کی الگ file ہے۔ اس لیے gluetun کی لکھی ہوئی file وہ file نہیں ہے جسے آپ کی application پڑھتی ہے۔

docker exec qbittorrent cat /etc/resolv.conf

Docker host پر چلنے والی service تک کیسے پہنچیں؟

host.docker.internal استعمال کریں۔ اس کے لیے دو مختلف جگہوں پر دو settings درکار ہوتی ہیں، کیونکہ دو مختلف چیزیں درست کرنا ہوتی ہیں۔

پہلے name شامل کریں۔ /etc/hosts ہر container کے لیے الگ ہوتا ہے، اس لیے extra_hosts entry application container میں ہونی چاہیے، gluetun میں نہیں۔

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

host-gateway ایک خاص value ہے جسے Docker خود host کے internal address سے بدل دیتا ہے۔ عام Linux Docker installation میں یہ docker0 bridge کا address ہوتا ہے، عموماً 172.17.0.1۔ VPS پر ip -4 addr show docker0 چلا کر اپنا address معلوم کریں۔ Docker Desktop اس name کو خود resolve کرتا ہے۔ اسی لیے laptop پر لکھی گئی guides میں extra_hosts line شامل نہیں ہوتی، لیکن وہی file server پر fail ہو جاتی ہے۔

اس کے بعد route شامل کریں۔ صرف name شامل کرنے سے container کو استعمال کرنے والا address معلوم ہوتا ہے۔ packet پھر بھی gluetun کے default route سے نکلتا ہے، جو tunnel ہوتا ہے، اور gluetun کا firewall اسے drop کر دیتا ہے۔ اس کی علامت یہ ہے کہ connection پہلے hang ہوتا ہے اور پھر timeout ہو جاتا ہے، نہ کہ فوراً refuse ہوتا ہے۔ refusal کا مطلب ہے کہ packet پہنچ گیا اور کسی service نے جواب دیا کہ connection قبول نہیں ہے۔ timeout کا مطلب ہے کہ packet پہنچا ہی نہیں۔

  gluetun:
    environment:
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32

پھر تصدیق کریں کہ host service واقعی اس address پر listen کر رہی ہے۔ صرف 127.0.0.1 پر bound PostgreSQL server کسی بھی container سے، tunnel کے موجود ہونے یا نہ ہونے سے قطع نظر، قابل رسائی نہیں ہوگا، کیونکہ namespace کے اندر 127.0.0.1 اسی namespace کا اپنا loopback ہوتا ہے۔ اس کے بجائے اسے 172.17.0.1 پر bind کریں۔ اس طرح یہ containers سے connections قبول کرے گا، جبکہ public interface پر دستیاب نہیں ہوگا۔ Host پر ss -lntp | grep 5432 چلا کر تصدیق کریں۔

FIREWALL_OUTBOUND_SUBNETS اصل میں کیا تبدیل کرتا ہے

gluetun کی دستاویزات کے مطابق یہ ان subnets کی comma-separated فہرست ہے جن تک gluetun اور اس کے network stack کو share کرنے والے containers کو رسائی کی اجازت ہوتی ہے۔ اس میں firewall اور routing دونوں کی تبدیلیاں شامل ہوتی ہیں۔ دونوں پہلو اہم ہیں۔ gluetun ہر درج شدہ subnet کے لیے Docker bridge gateway کے ذریعے ایک route شامل کرتا ہے، اس لیے ان addresses کے packets tunnel کے بجائے eth0 سے باہر جاتے ہیں۔ یہ ان کے لیے firewall بھی کھولتا ہے، کیونکہ gluetun بصورت دیگر اس outbound traffic کو drop کر دیتا ہے جو VPN server کی طرف نہ جا رہی ہو۔

Value میں commas کے بعد spaces نہ لکھیں۔

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

دو خصوصیات آسانی سے نظر انداز ہو جاتی ہیں۔ یہ namespace-level setting ہے، اس لیے اس کا اطلاق gluetun کے پیچھے موجود ہر container پر ہوتا ہے، صرف اس container پر نہیں جسے آپ کے ذہن میں رکھا گیا تھا۔ دوسری خصوصیت یہ ہے کہ یہ صرف outbound traffic کے لیے ہے: یہ ان connections کو control کرتی ہے جو کوئی container خود شروع کرتا ہے۔ Published port پر آنے والے connections مختلف path سے گزرتے ہیں، اس لیے ان کے لیے یہاں کوئی entry درکار نہیں۔

Tailscale peer سے web UI تک رسائی

Tailscale ہر مشین کو 100.64.0.0/10 میں ایک address دیتا ہے۔ یہ range carrier grade NAT کے لیے reserved ہے۔ دونوں سمتوں کے لیے مختلف اقدامات درکار ہوتے ہیں۔

Inbound سمت آسان ہے۔ gluetun پر 8080:8080 publish کرنے سے وہ port host کے تمام addresses پر bind ہو جاتا ہے۔ host کا tailscale0 interface بھی انہی میں شامل ہے۔ اس لیے peer http://<machine-name>:8080 کھول کر container تک پہنچ جاتا ہے۔ اس path میں Gluetun کا کوئی کردار نہیں، کیونکہ Docker کا NAT rule host پر، namespace سے باہر، موجود ہوتا ہے۔

UI کو صرف tailnet کے ذریعے accessible بنانے کے لیے published port کو ہر address کے بجائے host کے Tailscale address سے bind کریں۔

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

Host پر tailscale ip -4 سے یہ address معلوم کریں۔ یہاں binding firewall rule سے زیادہ مضبوط control ہے، کیونکہ port public interface پر بالکل open نہیں ہوتا۔ اس سے Docker کے ذریعے ports کو براہ راست ufw سے باہر publish کرنے کا مسئلہ بھی ختم ہو جاتا ہے۔

Outbound سمت میں FIREWALL_OUTBOUND_SUBNETS واپس آتا ہے۔ اگر container کو کسی peer سے رابطہ کرنا ہو تو اس peer کا address شامل کریں، اور پورے /10 کے بجائے ہر peer کے لیے /32 کو ترجیح دیں۔ MagicDNS names container کے اندر resolve نہیں ہوں گے، کیونکہ container host کا resolver استعمال نہیں کرتا۔ اس لیے numeric 100.x address استعمال کریں، یا اسے extra_hosts line کے ذریعے pin کریں۔ یہی بات اس وقت بھی لاگو ہوتی ہے جب آپ Headscale کے ساتھ اپنا Tailscale control server چلاتے ہیں۔

عام ساخت کے لیے مکمل compose فائل

ایک download client جو VPN کے پیچھے چلتا ہے، دو web UIs جو صرف tailnet پر جواب دیتی ہیں، اور ایک container جو host پر چلنے والے PostgreSQL database کو پڑھتا ہے۔

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

مصنوعات کے ناموں کے بجائے فائل میں موجود pattern کو سمجھیں۔ دونوں UIs کو gluetun پر publish کیا گیا ہے اور host کے tailnet address سے bind کیا گیا ہے، اس لیے وہ صرف Tailscale پر جواب دیتی ہیں اور کہیں اور نہیں۔ صرف Prowlarr میں extra_hosts لائن موجود ہے، کیونکہ host.docker.internal کو resolve کرنے والا container Prowlarr ہے۔ FIREWALL_OUTBOUND_SUBNETS میں دو single addresses درج ہیں: host کا Docker bridge address، تاکہ Prowlarr database connection کھول سکے، اور ایک tailnet peer۔

PostgreSQL server جان بوجھ کر اس فائل میں شامل نہیں ہے۔ یہ VPS پر عام system service کے طور پر چلتا ہے اور 172.17.0.1:5432 پر listening کرتا ہے۔ یہ وہی layering ہے جو Docker Compose پر arr stack میں ہوتی ہے، فرق صرف یہ ہے کہ database کو Docker سے باہر منتقل کیا گیا ہے۔

WireGuard private key کو compose فائل سے باہر رکھیں۔ ${WIREGUARD_PRIVATE_KEY} اس کے ساتھ موجود .env فائل سے values پڑھتا ہے۔ یہ وہی pattern ہے جسے Docker Compose کے لیے env files اور secrets میں بیان کیا گیا ہے۔ condition: service_healthy clause اس healthcheck کو استعمال کرتا ہے جو gluetun image میں پہلے سے شامل ہے، اس لیے tunnel کے up ہونے کی اطلاع دینے تک کوئی چیز start نہیں ہوتی۔ عمومی ساخت کے لیے Compose healthchecks دیکھیں۔

    ports:
      - "8080:8080/tcp"

تصدیق کریں کہ tunnel اب بھی traffic منتقل کر رہا ہے

اسی request کو دو بار چلائیں: ایک بار namespace کے اندر سے اور دوسری بار host سے۔ پھر دونوں نتائج کا موازنہ کریں۔

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

پہلے command کو آپ کے VPN provider کا exit address دکھانا چاہیے۔ دوسرے command کو VPS address دکھانا چاہیے۔ اگر دونوں ایک جیسے ہیں تو container کا traffic tunnel سے نہیں گزر رہا۔ اس مسئلے کے درست ہونے تک اس guide کی باقی تمام اصلاحات بے اثر رہیں گی۔

Routing table دکھاتی ہے کہ کون سا traffic tunnel سے گزر رہا ہے اور کون سا نہیں۔

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

Default route کو tunnel interface، tun0، کی طرف point کرنا چاہیے۔ اس کے نیچے FIREWALL_OUTBOUND_SUBNETS کی ہر entry کے لیے ایک route نظر آنا چاہیے، جو Docker bridge gateway کی طرف point کرے۔ eth0 کے ذریعے باہر جانے والا کوئی بھی دوسرا route وہ traffic ہے جو VPN کو bypass کرتا ہے۔

Gluetun کا control server port 8000 پر /v1/publicip/ip میں یہی public IP دکھاتا ہے۔ حالیہ versions میں control server routes کے لیے authentication configure کرنا ضروری ہے، اس لیے اس پر انحصار کرنے سے پہلے authentication configure کریں۔

ایک غلط subnet سے پیدا ہونے والا رساؤ

FIREWALL_OUTBOUND_SUBNETS وہ سوراخ ہے جو آپ firewall میں جان بوجھ کر بناتے ہیں، اس لیے سوراخ کا حجم خطرے کے حجم کے برابر ہوتا ہے۔ اسے بہت بڑا بنانے کے چار طریقے یہ ہیں:

• 0.0.0.0/0 تمام traffic کو tunnel سے باہر بھیجتا ہے۔ اوپر دیے گئے دونوں IP checks پہلی run میں ہی اسے پکڑ لیتے ہیں، کیونکہ وہ ایک ہی address واپس کریں گے۔
• target سے وسیع range۔ ایک machine کو 10.0.1.7 پر پہنچنے کے لیے 10.0.0.0/8 کھولنے سے اس range میں torrent peer کے مشتہر کردہ ہر address تک رسائی کھل جاتی ہے۔ 10.0.1.7/32 لکھیں۔
• ایسی range جو tunnel کے اپنے addresses سے overlap کرے۔ gluetun documentation خبردار کرتی ہے کہ اس صورت میں gluetun VPN traffic کو bridge کے ذریعے باہر بھیجتا ہے، جس سے port forwarding ناکام ہو جاتی ہے۔ کوئی بھی private range کھولنے سے پہلے اپنی WIREGUARD_ADDRESSES value چیک کریں۔
• Tailscale کے لیے 100.64.0.0/10۔ اس سے تقریباً چار million addresses کھل جاتے ہیں تاکہ ایک peer تک رسائی حاصل کی جا سکے۔ مطلوبہ peers کو /32 entries کے طور پر درج کریں۔

یاد رکھیں کہ یہ setting پورے namespace پر لاگو ہوتی ہے۔ کسی indexer کو host service تک پہنچانے کے لیے subnet کھولنے سے اسی namespace کو share کرنے والے torrent client کے لیے بھی وہی subnet کھل جاتا ہے۔ اس variable میں ہر تبدیلی کے بعد public IP check دوبارہ چلائیں، کیونکہ یہی واحد test ہے جو دکھاتا ہے کہ تبدیلی نے وہی نتیجہ دیا جو آپ چاہتے تھے۔

gluetun کو restart کرنے پر کیا خراب ہوتا ہے

gluetun namespace کا مالک ہوتا ہے، اس لیے gluetun کا lifecycle ہی namespace کا lifecycle ہوتا ہے۔ gluetun کے بند ہونے کے دوران dependent container شروع کرنے کی کوشش فوراً ناکام ہو جاتی ہے:

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

gluetun کو اسی جگہ restart کرنا زیادہ خاموشی سے پیدا ہونے والی خرابی ہے۔ dependent containers چلتے رہتے ہیں، جبکہ وہ namespace جس سے یہ منسلک تھے، ان کے نیچے دوبارہ بن رہا ہوتا ہے۔ اس لیے docker ps تمام چیزوں کو healthy رپورٹ کرتا ہے، لیکن کوئی جواب نہیں دیتا۔ gluetun service میں کسی بھی تبدیلی کے بعد صرف ایک حصے کو restart کرنے کے بجائے پورے group کو دوبارہ بنائیں۔

docker compose up -d --force-recreate

یہی اصول image updates پر بھی لاگو ہوتا ہے۔ نئی gluetun image pull کرکے صرف اسی service کو دوبارہ بنانے سے باقی services ایسے namespace کی طرف اشارہ کرتی رہتی ہیں جو اب موجود نہیں ہے۔

FAQ

Docker یہ کیوں کہتا ہے کہ "port publishing and the container type network mode"؟

کیونکہ ports: block اب بھی اس service پر موجود ہے جو network_mode: service:gluetun بھی set کرتی ہے۔ Port publish کرنے سے ایک NAT rule شامل ہوتا ہے جو host port سے container کے اپنے network namespace میں forwarding کرتا ہے، لیکن اس mode میں container کا اپنا network namespace نہیں ہوتا۔ اس service سے ports: block حذف کریں اور یہی mapping gluetun service میں شامل کریں۔ Port number وہی رہے گا، کیونکہ application shared namespace کے اندر اسی port پر listening کر رہی ہے۔

gluetun کے پیچھے موجود service تک دوسرے containers کیسے پہنچیں؟

اسی namespace کے اندر موجود containers ایک دوسرے تک 127.0.0.1 پر پہنچتے ہیں۔ اس کے باہر موجود containers gluetun service name استعمال کرتے ہیں، اس لیے جہاں http://qbittorrent:8080 کام نہیں کرتا وہاں http://gluetun:8080 کام کرتا ہے۔ Application container کسی Docker network پر اپنا address نہیں رکھتا، اس لیے embedded DNS server کے پاس اس کے name کو resolve کرنے کے لیے کچھ نہیں ہوتا۔ اس مقصد کے لیے port publishing ضروری نہیں، بشرطیکہ دونوں containers ایک ہی Compose network share کرتے ہوں۔

FIREWALL_OUTBOUND_SUBNETS میں کیا شامل کرنا چاہیے؟

صرف وہ addresses شامل کریں جن سے gluetun کے پیچھے موجود container کو connection شروع کرنا ضروری ہو، اور انہیں ممکنہ حد تک narrow لکھیں۔ ایک machine کے لیے /32 استعمال ہوتا ہے۔ دو عام entries Docker host کے لیے 172.17.0.1/32 اور ہر Tailscale peer کے لیے ایک /32 ہیں جس سے آپ connection کرتے ہیں۔ 0.0.0.0/0 کبھی شامل نہ کریں، اور نہ ہی ایسی range شامل کریں جو آپ کے VPN کے اپنے tunnel addresses سے overlap کرتی ہو۔ Published port پر آنے والی inbound connections کے لیے یہاں کسی entry کی ضرورت نہیں۔

Container میرے Tailscale MagicDNS names کو resolve کیوں نہیں کر پاتا؟

MagicDNS اس طرح کام کرتا ہے کہ host کے resolver کو Tailscale کے DNS server کی طرف point کرتا ہے، لیکن container host کا resolver استعمال نہیں کرتا۔ یہ وہ resolver استعمال کرتا ہے جو اس کے اپنے /etc/resolv.conf میں درج ہوتا ہے؛ gluetun کے پیچھے یہ gluetun کا DNS setup ہوتا ہے۔ docker exec <container> cat /etc/resolv.conf سے تصدیق کریں۔ Peer کا numeric 100.x address استعمال کریں، یا اس container پر extra_hosts entry کے ذریعے name کو pin کریں۔

میں کیسے تصدیق کروں کہ traffic اب بھی VPN کے ذریعے جا رہا ہے؟

Namespace کے اندر سے ایک request چلائیں اور host سے وہی request دوبارہ چلائیں، پھر دونوں responses کا موازنہ کریں۔ docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org کو آپ کے VPN provider کا exit address واپس کرنا چاہیے، جبکہ VPS پر curl -s https://api.ipify.org کو VPS address واپس کرنا چاہیے۔ اگر دونوں responses ایک جیسے ہوں تو tunnel container کا traffic منتقل نہیں کر رہا۔ FIREWALL_OUTBOUND_SUBNETS میں ہر تبدیلی کے بعد یہ check دوبارہ چلائیں۔