VPN سے Docker containers route کریں، ports کیوں غائب ہیں؟

VPN کے ذریعے Docker containers کو route کرنے پر ports کیوں غائب ہو جاتے ہیں

Docker containers کو VPN کے ذریعے route کرنے کے لیے ایک container کو tunnel فراہم کریں، پھر network_mode: "service:gluetun" کے ذریعے دوسرے containers کو اس کے network namespace سے منسلک کریں۔ یہی attachment اکثر لوگوں کو حیران کرتی ہے۔ منسلک container کا اپنا network نہیں رہتا، اس لیے اس کے published ports اور Docker service name بھی ختم ہو جاتے ہیں۔ Ports کو VPN container پر publish کریں، پھر دوسرے containers ایپ تک VPN container کے name کے ذریعے پہنچیں گے۔

منسلک container پر ports: block رہنے کی صورت میں Docker اسے create کرنے سے مکمل طور پر انکار کر دیتا ہے:

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 سے connect ہوتا ہے اور اپنا firewall بھی چلاتا ہے۔ August 2026 تک Release v3.41.3 موجودہ version ہے۔ مثالوں میں WireGuard کے ساتھ Mullvad استعمال کیا گیا ہے، اس لیے آپ کو اپنے provider کا account اور key درکار ہے۔ اگر آپ tunnel اپنے زیرِ انتظام hardware پر terminate کرنا چاہتے ہیں تو VPS پر اپنا WireGuard server چلانا دوسرے سرے کو تیار کرتا ہے، جبکہ Docker میں wg-easy اسے web interface میں فراہم کرتا ہے۔

What network_mode: "service:gluetun" actually does

ہر Docker container کو عموماً اپنا network namespace ملتا ہے: اپنے interfaces، routing table، firewall rules اور listening sockets۔ service: mode یہ مرحلہ چھوڑ کر container کو gluetun کے namespace میں شروع کرتا ہے۔ ایک namespace کا مطلب ایک IP address ہے، اور اس سے چھ چیزیں تبدیل ہوتی ہیں۔

• ایپ کا اپنا کوئی address نہیں ہوتا۔ اس کا address gluetun کا address ہوتا ہے۔
• ایپ کسی Docker network سے منسلک نہیں ہوتی، اس لیے اس کا service name کبھی register یا resolve نہیں ہوتا۔ دیگر containers کو gluetun استعمال کرنا ہوگا۔
• namespace کے اندر موجود containers ایک دوسرے تک localhost کے ذریعے پہنچتے ہیں۔
• ایک namespace میں موجود دو containers ایک ہی port پر listen نہیں کر سکتے۔ Gluetun documentation اس بارے میں واضح ہے: اس کا کوئی workaround نہیں ہے۔
• Capabilities کسی namespace کے بجائے container سے وابستہ ہوتی ہیں۔ Gluetun کے پاس NET_ADMIN اور /dev/net/tun ہوتی ہیں کیونکہ tunnel interface وہی بناتا ہے۔ اس سے منسلک container انہیں inherit نہیں کرتا۔
• Compose ایسی file مسترد کر دیتا ہے جس میں کسی ایک service کے لیے network_mode اور networks دونوں set ہوں۔ gluetun کو اپنے networks سے منسلک کریں، اور ایپ اسی کے ساتھ چلنے لگے گی۔

gluetun کو restart کرنے سے اس سے منسلک ہر چیز disconnect ہو جاتی ہے۔ یہ documented behaviour ہے، اور اسی وجہ سے connection fail ہونے پر gluetun container سے exit ہونے کے بجائے VPN process کو container کے اندر restart کرتا ہے۔ gluetun کو خود restart یا recreate کرنے کے بعد اس سے منسلک containers کو restart کریں۔

وہ Compose فائل جو کام کرتی ہے

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 edge ہے، اس لیے ایسی مشین پر :v3 کو pin کریں جس پر آپ منگل کے دن debugging نہیں کرنا چاہتے۔

WEBUI_PORT=8080 کو published port سے مطابقت رکھنی چاہیے، کیونکہ qBittorrent، gluetun کے namespace کے اندر bind ہوتا ہے، اور publish rule host کا network traffic وہاں port 8080 پر بھیجتا ہے۔ ایک number کو دوسرے کے بغیر تبدیل کرنے سے port کسی درخواست کا جواب نہیں دے گا۔ 127.0.0.1:8080:8080 web interface کو host کے loopback address پر محدود رکھتی ہے۔ سادہ 8080:8080 ہر interface پر port publish کرتی ہے اور اپنی firewall rule بناتی ہے۔ اسی طرح Docker کے published ports براہ راست ufw سے گزر جاتے ہیں۔

اسے start کریں، پھر اس ترتیب سے check کریں:

docker compose up -d
docker compose ps
docker compose logs gluetun | tail -30

docker compose ps میں gluetun کی حالت healthy اور qbittorrent کی حالت running دکھائی دینی چاہیے۔ اس کے بعد namespace کے اندر سے exit address کی تصدیق کریں۔ یہی check باقی تمام نتائج کا فیصلہ کرتا ہے:

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 فائل سے باہر رکھیں

gluetun.env credentials رکھتی ہے، اور اسے git میں شامل نہ کریں:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

دونوں values آپ کے provider کے account area میں تیار کی گئی WireGuard configuration file سے حاصل ہوتی ہیں۔ اس فائل کا mode 600 مقرر کریں۔ اس سے حاصل ہونے والے فائدے کو درست طور پر سمجھیں: key آپ کی repository سے باہر رہتی ہے، لیکن docker inspect gluetun پھر بھی تمام environment variables ہر اس شخص کو دکھاتا ہے جو Docker socket تک رسائی حاصل کر سکتا ہو۔ زیادہ مضبوط اختیارات کے لیے Docker Compose میں environment files اور secrets دیکھیں۔

ایک tunnel سے باہر موجود container اس کے اندر موجود container سے کیسے رابطہ کرتا ہے

دونوں سمتوں میں رابطہ ممکن ہے، اور ہر سمت کے لیے مختلف نام استعمال ہوتا ہے۔ دونوں containers کے لیے مشترکہ Docker network ضروری ہے۔ یہ gluetun کا network ہوتا ہے، کیونکہ اس سے منسلک container کا اپنا کوئی network نہیں ہوتا۔ Docker Compose networks کو کیسے مربوط کرتا ہے default settings کی وضاحت کرتا ہے۔

باہر سے اندر کی سمت رابطے کے لیے gluetun کا نام اور وہ port استعمال کریں جس پر ایپ listening کر رہی ہے۔ reverse proxy container، qBittorrent web interface تک gluetun:8080 کے ذریعے پہنچتا ہے۔ اس کے لیے ports: entry ضروری نہیں، کیونکہ containers کے درمیان network traffic Docker network پر رہتا ہے اور host port تک نہیں پہنچتا۔

اندر سے باہر کی سمت رابطے کے لیے دوسرے container کا service name استعمال کریں، مثلاً postgres:5432۔ v3.41 کے بعد سے Gluetun اپنے namespace کے اندر دوسرے containers کے نام resolve کر لیتا ہے۔ اگر کوئی نام resolve نہ ہو تو v3.41 یا اس کے بعد کا version مقرر کریں۔

Gluetun کا firewall طے کرتا ہے کہ کون اس سے connection کھول سکتا ہے۔ gluetun کے اپنے Docker network سے آنے والا traffic allowed ہوتا ہے۔ مختلف subnet پر موجود client، آپ کے LAN کا laptop، یا الگ bridge network پر موجود container کا traffic اس وقت تک drop ہوتا ہے جب تک آپ اس subnet کو درج نہ کریں:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

دستاویزی معنی بالکل واضح ہے: comma-separated subnets جنہیں Gluetun اور اس کے network stack کا اشتراک کرنے والے containers تک رسائی کی اجازت ہے۔

internet سے آنے والے inbound connections الگ مسئلہ ہیں۔ torrent client کے peers VPN side سے آتے ہیں، اس لیے host پر port 6881 publish کرنے سے ان کے لیے کچھ نہیں ہوتا۔ آپ کو اپنے provider کی طرف سے forwarded port درکار ہے، اور اسے FIREWALL_VPN_INPUT_PORTS میں درج کرنا ہوگا۔ یہ setting VPN server side سے آنے والے ports کی اجازت دیتی ہے۔ یہی وہ حصہ ہے جسے بیشتر Docker Compose سے بنائے گئے media stacks خراب حالت میں چھوڑ دیتے ہیں۔

فیل سیف: ٹنل ختم ہونے پر کیا ہوتا ہے

یہ ڈیزائن ناکامی کی صورت میں اپنی پیچیدگی کو ثابت کرتا ہے۔ منسلک container کے پاس کوئی دوسرا route نہیں ہے۔ مشین سے باہر جانے کا اس کا واحد راستہ وہی namespace ہے جسے یہ share کرتا ہے۔ اس لیے ٹنل بند ہونے پر fallback کے لیے کچھ نہیں بچتا۔ Gluetun کا firewall بھی دوسری جانب سے یہی اصول نافذ کرتا ہے: outbound traffic یا تو ٹنل کے ذریعے جاتا ہے یا VPN server endpoint تک، جبکہ باقی تمام traffic drop کر دیا جاتا ہے۔ اس دوران کوئی ایسا وقفہ نہیں آتا جس میں client کے reconnect ہونے تک packets plain interface سے باہر نکل سکیں۔

Gluetun اپنے connection کی نگرانی کرتا ہے۔ ہر منٹ یہ HEALTH_ICMP_TARGET_IPS میں موجود addresses کو ICMP echo (ping) بھیجتا ہے، جن کی default قدر 1.1.1.1,8.8.8.8 ہے۔ ہر پانچ منٹ بعد یہ HEALTH_TARGET_ADDRESSES تک مکمل TCP اور TLS (transport layer security) connection بناتا ہے؛ اس کی default قدر cloudflare.com:443,github.com:443 ہے۔ یہ checks ناکام ہوں تو یہ 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 dead tunnel کے نتائج ہیں، وجوہات نہیں۔ Gluetun کی documentation اس بات کو واضح طور پر بیان کرتی ہے، کیونکہ لوگ نتیجے کی اطلاع دے کر کئی گھنٹے اس کی تلاش میں ضائع کر دیتے ہیں۔

HEALTH_RESTART_VPN=on default طور پر enabled ہے اور اسے enabled رہنا چاہیے۔ اسے صرف کسی ایک مخصوص failure کی debugging کے دوران عارضی طور پر off کریں، کیونکہ off ہونے کی صورت میں dead tunnel بدستور dead رہتا ہے۔

ترتیب: 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/ پر چل رہے gluetun کے health server سے query کرتی ہے۔ فعال tunnel 200 OK کے ساتھ جواب دیتا ہے۔ خراب tunnel error string کے ساتھ 500 Internal server error کا جواب دیتا ہے، اور ایک ہی failure کے بعد container کو unhealthy قرار دے دیا جاتا ہے۔

condition: service_healthy اسی کا انتظار کرتا ہے۔ سادہ depends_on: [gluetun] صرف container کے start ہونے کا انتظار کرتا ہے۔ یہ handshake مکمل ہونے سے کئی seconds پہلے ہو جاتا ہے، اس لیے app ایسے network میں start ہوتی ہے جو فعال نہیں ہوتا، اور اکثر اپنی پہلی connection attempt ترک کر دیتی ہے۔ Docker Compose میں healthchecks syntax اور timing fields کی وضاحت کرتا ہے۔

ایک حد اکثر صارفین کی نظر سے رہ جاتی ہے۔ Compose container بناتے وقت اس condition کا صرف ایک بار جائزہ لیتا ہے۔ اگر بعد میں gluetun unhealthy ہو جائے تو یہ app کو stop یا restart نہیں کرتا۔ اس صورت میں gluetun کی internal auto-healing کام کرتی ہے۔ اسی لیے یہ container کے بجائے VPN process کو restart کرتا ہے۔

setup پر اعتماد کرنے سے پہلے DNS leak کی جانچ کریں

DNS (domain name system) وہ leak ہے جو درست tunnel کے باوجود برقرار رہتا ہے۔ Gluetun namespace کے اندر اپنا resolver چلاتا ہے اور بطور default queries کو DoT (DNS over TLS) کے ذریعے Cloudflare تک forward کرتا ہے: DNS_UPSTREAM_RESOLVER_TYPE=dot اور DNS_UPSTREAM_RESOLVERS=cloudflare۔ دونوں settings کو تبدیل نہ کریں۔ اس طرح آپ کی lookups encrypted رہتی ہیں اور tunnel کے ذریعے سفر کرتی ہیں۔

جو setting یہ راستہ توڑتی ہے وہ DNS_UPSTREAM_PLAIN_ADDRESSES ہے۔ لوگ اسے اس وقت استعمال کرتے ہیں جب کوئی name resolve نہ ہو اور وہ چاہتے ہوں کہ ان کا router یا provider کا resolver جواب دے۔ Gluetun documentation اس کا نقصان واضح طور پر بیان کرتی ہے: تمام DNS traffic VPN tunnel سے نہیں گزرے گا اور tunnel سے باہر leak ہو جائے گا۔ آپ کا traffic private رہتا ہے۔ آپ کے hostnames کی فہرست private نہیں رہتی۔ اسی غلطی کے WireGuard ورژن کی وضاحت WireGuard tunnel پر DNS resolution رک جائے میں کی گئی ہے۔

جانچ کے لیے gluetun پر HTTPPROXY=on set کریں اور 8888:8888/tcp publish کریں۔ پھر کسی browser کو اس proxy کی طرف point کریں اور DNS leak test کھولیں۔ نتیجے میں آپ کے provider یا Cloudflare کا نام آنا چاہیے، آپ کے home router کا نہیں۔ Gluetun کی اپنی documentation خبردار کرتی ہے کہ بعض leak tests غیر معمولی نتائج دکھاتے ہیں، کیونکہ namespace کے اندر موجود resolver ایک local caching intermediary ہے، نہ کہ وہ server جو آخر میں جواب دیتا ہے۔ غلط country یا آپ کے اپنے ISP کے resolver کو حقیقی signal سمجھیں۔

VPN sidecar کے ساتھ Tailscale شامل کرنا، اور یہ طے کرنا کہ کون سا route غالب رہے گا

Tailscale، WireGuard پر مبنی ایک overlay network ہے جو اپنی مشینوں تک رسائی کے لیے استعمال ہوتا ہے۔ لوگ اسے provider VPN کے ساتھ چلاتے ہیں تاکہ stack تک انتظامی رسائی کا راستہ برقرار رہے۔ دونوں عموماً ایک دوسرے سے متصادم نہیں ہوتے، اور اس کی ایک اہم وجہ ہے۔ Tailscale کی documentation کے مطابق default رویہ یہ ہے کہ یہ overlay network کے طور پر کام کرتا ہے، صرف Tailscale چلانے والے devices کے درمیان traffic route کرتا ہے، اور public internet traffic کو نہیں چھیڑتا۔

اس لیے جواب ایک setting پر منحصر ہے۔

• Tailscale اپنے الگ container میں ہو اور default configuration استعمال کرے: اسے app کا outbound traffic کبھی نظر نہیں آتا۔ تمام traffic Gluetun کے ذریعے جاتا ہے۔ Tailscale app تک gluetun:8080 پر اسی طرح پہنچتا ہے جیسے کوئی بھی دوسرا بیرونی container۔
• Tailscale کو network_mode: "service:gluetun" کے ساتھ gluetun کے namespace سے attach کیا جائے: اسے net_admin اور net_raw کی اپنی cap_add درکار ہوتی ہے، کیونکہ namespace کے ساتھ capabilities خود بخود منتقل نہیں ہوتیں۔ default userspace networking mode میں TS_USERSPACE فعال ہوتا ہے، tailscaled کوئی interface نہیں بناتا اور SOCKS5 یا HTTP proxy کے طور پر کام کرتا ہے، اس لیے یہ routing تبدیل نہیں کر سکتا۔ تمام traffic پھر بھی Gluetun کے ذریعے جاتا ہے۔
• یہی configuration TS_USERSPACE=false کے ساتھ ہو: tailscaled ایک tunnel device بناتا ہے اور routes نصب کرتا ہے، لیکن صرف tailnet range 100.64.0.0/10 کے لیے، نیز ان subnet routes کے لیے جو آپ TS_ROUTES کے ذریعے advertise کرتے ہیں۔ Public traffic پھر بھی gluetun کے ذریعے باہر جاتا ہے۔
• اوپر دی گئی configurations میں سے کسی کے ساتھ exit node منتخب کیا جائے، sudo tailscale set --exit-node=<exit-node-ip>: Tailscale default route سنبھال لیتا ہے اور غالب آتا ہے۔ اسے gluetun کے ساتھ استعمال نہ کریں۔ ایک default route کا صرف ایک مالک ہونا چاہیے۔

جب Tailscale tunnel کے اندر چلتا ہے تو ایک ضمنی اثر نظر آتا ہے۔ اس کے peers کو VPN provider کا address دکھائی دیتا ہے، اس لیے توقع کریں کہ یہ زیادہ مرتبہ relays پر واپس جائے گا۔ ایسا ہونے پر tailscale status میں peer کے ساتھ direct کے بجائے relay "..." دکھائی دیتا ہے۔ connection کام کرتا ہے، لیکن اس کی رفتار کم ہوتی ہے۔ اگر آپ کو دراصل صرف overlay درکار تھا تو plain WireGuard اور Tailscale کے درمیان فرق بہتر نقطۂ آغاز ہے۔

کیا خراب ہوتا ہے، اور آپ کو کون سا پیغام نظر آئے گا

Docker ایپ container بنانے سے انکار کرتا ہے۔ Error response from daemon: conflicting options: port publishing and the container type network mode کا مطلب ہے کہ ایک ports: block ابھی تک منسلک service پر موجود ہے۔ اسے gluetun میں منتقل کریں۔

Compose پوری file قبول نہیں کرتا۔ کوئی service بیک وقت network_mode اور networks مقرر نہیں کر سکتی۔ networks کو gluetun پر رکھیں۔

دوسرا container ایپ کو resolve نہیں کر سکتا۔ curl: (6) Could not resolve host: qbittorrent درست رویہ ہے، کیونکہ منسلک container کسی network میں شامل نہیں ہوا اور اس نے کوئی name register نہیں کیا۔ gluetun اور port استعمال کریں۔

دوسرا منسلک container start نہیں ہوتا۔ ایک ہی namespace میں دو processes ایک ہی port پر bind نہیں ہو سکتے۔ ناکام process بتاتا ہے کہ address پہلے ہی استعمال میں ہے۔ ایپ کا داخلی port تبدیل کریں، یا دوسرا gluetun چلائیں۔

gluetun میں تبدیلی کے بعد ایپ کا network نہیں ہے۔ gluetun کو restart یا recreate کرنے سے اس سے منسلک تمام containers کی connectivity ختم ہو جاتی ہے۔ ان containers کو restart کریں۔

چھوٹے pages load ہو جاتے ہیں، لیکن بڑے pages رک جاتے ہیں۔ یہ MTU (maximum transmission unit) کا مسئلہ ہے۔ tunnel اضافی overhead شامل کرتا ہے، اور راستے میں کوئی جزو error واپس بھیجے بغیر حد سے بڑے packets گرا دیتا ہے۔ WIREGUARD_MTU کم کریں، 1400 آزمائیں، پھر 1320 آزمائیں۔

Gluetun کبھی healthy نہیں ہوتا۔ startup check پہلے مشتبہ عوامل بتاتا ہے: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout۔ پہلے دیکھیں کہ key expire تو نہیں ہو گئی، پھر جانچیں کہ server list پرانی تو نہیں، اور آخر میں تصدیق کریں کہ host firewall outbound UDP کو block تو نہیں کر رہا۔

FAQ

میرے container کے published ports نے Gluetun کے پیچھے کام کرنا کیوں بند کر دیا؟

کیونکہ network_mode: "service:gluetun" container کو gluetun کے network namespace میں رکھتا ہے، اور ایک namespace میں ایک IP address اور listening ports کا ایک ہی مجموعہ ہوتا ہے۔ app بدستور listening کرتی رہتی ہے، لیکن publish rule اسی container میں ہونی چاہیے جو namespace کا مالک ہے۔ ports: فہرست کو gluetun service میں منتقل کریں۔ اگر یہ فہرست attached service پر رہ گئی ہو تو Docker اسے بنائے گا بھی نہیں: Error response from daemon: conflicting options: port publishing and the container type network mode۔

VPN tunnel کے اندر موجود container تک اس container سے کیسے پہنچوں جو tunnel کے باہر ہے؟

gluetun کا service name اور وہ port استعمال کریں جس پر app listening کرتی ہے، مثلاً gluetun:8080۔ attached container کا اپنا کوئی Docker network نہیں ہوتا، اس لیے اس کا اپنا name resolve نہیں ہوتا۔ container سے container traffic کے لیے کسی چیز کو publish کرنے کی ضرورت نہیں۔ دوسری سمت میں، namespace کے اندر موجود container Gluetun v3.41 اور بعد کے versions پر باہر موجود container تک اس کے service name، مثلاً postgres:5432، کے ذریعے پہنچ سکتا ہے۔ مختلف subnet پر موجود client، مثلاً آپ کے LAN کا laptop، gluetun firewall کے ذریعے روک دیا جاتا ہے، جب تک آپ اس subnet کو FIREWALL_OUTBOUND_SUBNETS میں شامل نہ کریں۔

کیا VPN کے منقطع ہونے پر Gluetun kill switch کے طور پر کام کرتا ہے؟

ہاں، اور بیک وقت دو وجوہات کی بنا پر۔ attached container کے پاس shared namespace میں موجود route کے علاوہ کوئی route نہیں ہوتا، اس لیے tunnel کے بند ہونے پر اس کے پاس machine سے باہر جانے کا کوئی راستہ نہیں رہتا۔ Gluetun کا firewall بھی outbound traffic کو صرف tunnel اور VPN server endpoint تک جانے کی اجازت دیتا ہے۔ Gluetun VPN کو اندرونی طور پر دوبارہ start کرتا ہے اور WARN [vpn] restarting VPN because it failed to pass the healthcheck log کرتا ہے، exit نہیں کرتا، کیونکہ gluetun خود restart ہونے پر ہر attached container اپنا network کھو دیتا ہے۔

ایک ہی stack میں Tailscale اور Gluetun: outbound traffic کون لے کر جائے گا؟

ایک configuration کے سوا ہر configuration میں Gluetun۔ Tailscale بطور default صرف آپ کے tailnet میں موجود devices کے درمیان traffic route کرتا ہے اور public traffic کو متاثر نہیں کرتا۔ container image کے default userspace mode میں یہ کوئی interface بناتا ہی نہیں، اس لیے routing پر اثر انداز نہیں ہو سکتا۔ TS_USERSPACE=false کے ساتھ یہ صرف 100.64.0.0/10 اور آپ کے advertised subnets کے لیے routes install کرتا ہے۔ استثنا exit node ہے: sudo tailscale set --exit-node=<exit-node-ip> Tailscale کو default route بنا دیتا ہے، اور پھر وہی ترجیح پاتا ہے۔ default route کی ملکیت کے لیے ایک product منتخب کریں؛ دونوں کو بیک وقت stack نہ کریں۔