VPN کے ذریعے Docker containers route کرنے کا طریقہ

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 کے ذریعے app تک پہنچیں گے۔

منسلک 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 میں فراہم کرتا ہے۔

اصل میں network_mode: "service:gluetun" کیا کرتا ہے

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

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

gluetun کو restart کرنے سے اس سے attached تمام چیزوں کا connection ختم ہو جاتا ہے۔ یہ documented behaviour ہے، اور اسی وجہ سے connection fail ہونے پر gluetun container سے exit ہونے کے بجائے VPN process کو container کے اندر restart کرتا ہے۔ gluetun کو خود restart یا recreate کرنے کے بعد اس سے attached 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 ہے، اس لیے ایسے machine پر :v3 pin کریں جس پر آپ منگل کے دن debugging نہیں کرنا چاہتے۔

WEBUI_PORT=8080 کو published port سے match ہونا ضروری ہے، کیونکہ qBittorrent، gluetun کے namespace کے اندر bind ہوتا ہے اور publish rule، host traffic کو وہاں port 8080 پر بھیجتا ہے۔ ایک number کو دوسرے کے بغیر تبدیل کرنے سے port کسی request کا جواب نہیں دے گا۔ 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 فائل میں keys شامل نہ کریں

gluetun.env credentials محفوظ رکھتا ہے اور git سے باہر رہتا ہے:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

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

کنٹینر کے باہر سے اندر موجود کنٹینر سے رابطہ کیسے کیا جائے

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

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

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

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

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

اس configuration کا documented مطلب واضح ہے: comma-separated subnets جنہیں Gluetun اور اس کے network stack کو share کرنے والے کنٹینرز تک رسائی کی اجازت ہے۔

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 میں اکثر درست نہیں کیا جاتا۔

ٹنل ختم ہونے پر کیا ہوتا ہے: kill switch

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

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

Attached 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 بحال نہیں ہوتا۔

ترتیب: tunnel فعال ہونے سے پہلے stack کو start ہونے سے روکنا

image میں Docker healthcheck شامل ہے:

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

یہ command gluetun کی ایک دوسری، مختصر مدت کے لیے چلنے والی copy شروع کرتی ہے۔ یہ 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 ہوتی ہے جو ابھی dead ہوتا ہے، اور اکثر اپنی پہلی connection attempt ترک کر دیتی ہے۔ Docker Compose میں healthchecks syntax اور timing fields کی وضاحت کرتا ہے۔

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

VPN configuration پر بھروسا کرنے سے پہلے DNS leak چیک کریں

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

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

اسے test کرنے کے لیے 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 شامل کرنا، اور دونوں میں سے کون غالب رہتا ہے

Tailscale، WireGuard پر مبنی overlay network ہے جو اپنی مشینوں تک رسائی کے لیے استعمال ہوتا ہے۔ لوگ اسے provider VPN کے ساتھ چلاتے ہیں تاکہ stack میں انتظامی رسائی کا راستہ برقرار رہے۔ دونوں عموماً متصادم نہیں ہوتے، اور اس کی ایک اہم وجہ ہے۔ Tailscale کی documentation کے مطابق default رویہ یہ ہے: یہ overlay network کے طور پر کام کرتا ہے، صرف Tailscale چلانے والی ڈیوائسز کے درمیان 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 کے cap_add اور net_raw کی اپنی ضرورت ہوتی ہے، کیونکہ namespace کے ساتھ capabilities منتقل نہیں ہوتیں۔ default userspace networking mode میں TS_USERSPACE فعال ہوتا ہے۔ tailscaled کوئی interface نہیں بناتا اور SOCKS5 یا HTTP proxy کے طور پر کام کرتا ہے، اس لیے یہ routing تبدیل نہیں کر سکتا۔ تمام traffic اب بھی Gluetun کے ذریعے جاتا ہے۔
• یہی configuration، TS_USERSPACE=false کے ساتھ: tailscaled ایک tunnel device بناتا ہے اور routes install کرتا ہے، لیکن صرف tailnet range 100.64.0.0/10 اور ان subnet routes کے لیے جنہیں آپ TS_ROUTES کے ذریعے advertise کرتے ہیں۔ Public traffic اب بھی gluetun کے ذریعے باہر جاتا ہے۔
• اوپر دی گئی کسی بھی configuration میں exit node منتخب ہو، sudo tailscale set --exit-node=<exit-node-ip>: Tailscale default route سنبھال لیتا ہے اور غالب آ جاتا ہے۔ اسے gluetun کے ساتھ نہ ملائیں۔ ایک default route کا صرف ایک مالک ہونا چاہیے۔

اگر ان advertised routes کا مقصد یہ ہے کہ صرف box نہیں بلکہ اس کے پیچھے موجود پورا private network قابلِ رسائی ہو، تو VPS پر Tailscale subnet router چلانا route approval، IP forwarding، اور client-side flag کا احاطہ کرتا ہے۔ یہ وہ کام ہے جو TS_ROUTES اکیلے نہیں کرتا۔

اگر Tailscale کا مقصد route کے بجائے آپ کو admin URL فراہم کرنا ہے، تو tailscale serve اور tailscale funnel آپ کے tailnet کے لیے gluetun:8080 کے سامنے HTTPS رکھتے ہیں۔ اسے public internet پر صرف funnel کے ذریعے کھولا جاتا ہے۔

Tailscale کو tunnel کے اندر چلانے کا ایک ضمنی اثر بھی ہوتا ہے۔ اس کے peers کو VPN provider کا address نظر آتا ہے، اس لیے یہ زیادہ کثرت سے relays پر fallback کرتا ہے۔ ایسا ہونے پر 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 میں شامل نہیں ہوا اور اس نے کوئی نام 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 شامل کرتا ہے، اور راستے میں کوئی جزو بڑے packets کو اس error کے بغیر drop کر دیتا ہے کہ sender کو مسئلے کی اطلاع ملے۔ 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 کا ایک ہی set ہوتا ہے۔ ایپ listening جاری رکھتی ہے، لیکن publish rule اس container میں ہونی چاہیے جو namespace کا مالک ہے۔ ports: list کو gluetun service میں منتقل کریں۔ اگر یہ list attached service پر موجود ہو تو Docker اسے بنائے گا بھی نہیں: Error response from daemon: conflicting options: port publishing and the container type network mode۔

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

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

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

ہاں، اور بیک وقت 2 وجوہات کی بنا پر۔ attached container کے پاس shared namespace میں موجود route کے علاوہ کوئی route نہیں ہوتا، اس لیے tunnel بند ہونے پر اس کے پاس machine سے باہر جانے کا کوئی path نہیں رہتا۔ 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 کے سوا ہر 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 بنا دیتا ہے، اور پھر وہ routing سنبھالتا ہے۔ دونوں کو stack کرنے کے بجائے default route کا انتظام صرف ایک product کے سپرد کریں۔