Gluetun port forwarding: torrent connections کیسے لائیں؟

فاروَرڈ کیے گئے port کے بغیر کوئی connection اندر کیوں نہیں آتا

Gluetun کا port forwarding آپ کے VPN provider سے کہتا ہے کہ وہ اپنے exit address پر موجود ایک public port کو واپس آپ کے container تک map کرے۔ یہی واحد طریقہ ہے جس سے کوئی دوسرا peer آپ کے torrent client کے ساتھ connection شروع کر سکتا ہے۔ اس mapping کے بغیر tunnel درست رہتا ہے، downloads چلتے رہتے ہیں، لیکن خود سے کوئی connection اندر نہیں آتا۔ ہر کامیاب connection وہ ہوتا ہے جسے آپ کے client نے پہلے شروع کیا ہو۔

یہ طریقہ NAT (network address translation) پر مبنی ہے۔ آپ کا container اسی provider کے exit address کو بہت سے دوسرے customers کے ساتھ share کرتا ہے۔ جب آپ کا client باہر کی طرف connection کھولتا ہے تو provider اس flow کو record کرتا ہے اور replies کو آپ کے tunnel کے ذریعے واپس بھیجتا ہے۔ کسی اجنبی peer کی طرف سے اندر آنے والی connection کسی recorded flow سے match نہیں ہوتی، اس لیے packet exit address تک پہنچ کر وہیں drop ہو جاتا ہے۔ آپ کا client پھر بھی ہر ایسے peer تک پہنچ سکتا ہے جو خود connectable ہو۔ اس لیے downloads مکمل ہو جاتے ہیں اور مسئلہ ظاہر نہیں ہوتا۔ یہ مسئلہ seeding کے دوران نمایاں ہوتا ہے، کیونکہ seeder وہ machine ہے جس سے دوسرے لوگ connect کرتے ہیں۔

کھلا inbound port دو چیزیں تبدیل کرتا ہے۔ آپ swarm میں زیادہ تیزی سے شامل ہوتے ہیں، کیونکہ جو peers خود connections قبول نہیں کر سکتے وہ اب آپ تک پہنچ سکتے ہیں۔ اس کے علاوہ آپ ان peers کو upload بھی کر سکتے ہیں۔

زیادہ تر VPN فراہم کنندگان forwarded port کیوں فراہم نہیں کرتے

Forwarded port مشترکہ address پر ایک محدود resource ہوتا ہے۔ فراہم کنندہ ایک exit IP پر ایک port number ایک صارف کے لیے reserve کرتا ہے، اور پھر اس port کے ذریعے صارف کی ہر سرگرمی کی ذمہ داری لیتا ہے۔ کئی بڑے فراہم کنندگان نے یہ feature ختم کر دیا اور اس کی وجہ abuse handling بتائی۔ Support کو صرف checkbox کے طور پر نہ دیکھیں؛ یہ ایک category question ہے۔ پوچھیں کہ آیا فراہم کنندہ آج port forwarding دیتا ہے، آپ کے plan میں یہ شامل ہے، اور ان servers پر دستیاب ہے جنہیں آپ واقعی select کر سکتے ہیں۔

جہاں forwarding دستیاب ہو، وہاں port dynamic ہوتا ہے۔ یہ VPN session سے منسلک ہوتا ہے، آپ کے account سے نہیں۔ اس لیے ہر reconnect کے بعد number مختلف ہو سکتا ہے۔ Private Internet Access ایک signed port جاری کرتا ہے جسے gluetun refresh کرتا ہے۔ upstream documentation کے مطابق، اگر آپ /gluetun directory کو bind mount کریں تو restart کے بعد state برقرار رہتی ہے اور آپ 60 دن تک وہی port استعمال کرتے رہتے ہیں۔ ProtonVPN NAT-PMP (NAT port mapping protocol) کے ذریعے ایک random port assign کرتا ہے۔ یہ port مختصر lease پر ہوتا ہے، جسے مسلسل renew کرنا ضروری ہے۔ اسی لیے client میں port ایک بار set کرنے سے یہ ہمیشہ کام نہیں کرتا۔

gluetun کن providers سے port طلب کر سکتا ہے

gluetun v3.41.3 کے مطابق، جو 30 July 2026 کو release ہوا، native integration چار provider names کی توثیق کرتی ہے: Private Internet Access، ProtonVPN، Perfect Privacy اور PrivateVPN۔ اسے VPN_PORT_FORWARDING=on کے ذریعے enable کریں، جو default طور پر off ہے۔ پرانی guides میں PORT_FORWARDING یا PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING استعمال ہوتے ہیں۔ یہ دونوں اس version میں retro-compatible names کے طور پر اب بھی کام کرتے ہیں، لیکن دونوں کو مرحلہ وار ختم کیا جا رہا ہے۔

دو provider details طے کرتی ہیں کہ request کامیاب ہو بھی سکتی ہے یا نہیں۔ ProtonVPN کے لیے paid plan درکار ہے، اور NAT-PMP کو enable کرنا ضروری ہے: WireGuard configuration generate کرتے وقت VPN options کے تحت NAT-PMP (Port Forwarding) enable کریں، یا OpenVPN استعمال کرتے وقت اپنے username کے آخر میں +pmp شامل کریں۔ OpenVPN پر Private Internet Access میں PORT_FORWARD_ONLY موجود ہے۔ یہ server selection کو ان servers تک محدود کرتا ہے جو port forwarding support کرتے ہیں، تاکہ آپ ایسے server سے connect نہ ہوں جہاں یہ سہولت کبھی موجود ہی نہیں تھی۔ WireGuard اور OpenVPN میں port طلب کرنے کا طریقہ مختلف ہے، اس لیے انتخاب کرنے سے پہلے اپنے provider کا صفحہ پڑھیں۔

جب gluetun built-in provider کے بجائے custom configuration چلاتا ہے تو VPN_PORT_FORWARDING_PROVIDER اس API کا نام بتاتا ہے جسے gluetun کو call کرنا چاہیے۔ upstream Private Internet Access صفحہ اس variable کو VPN_PORT_FORWARDING_USERNAME اور VPN_PORT_FORWARDING_PASSWORD کے ساتھ استعمال کرتا ہے۔ یہ دونوں account credentials فراہم کرتے ہیں جو port request کے لیے درکار ہوتے ہیں۔

Docker Compose میں gluetun کی port forwarding فعال کریں

یہ فرض کیا گیا ہے کہ tunnel پہلے سے کام کر رہا ہے۔ اگر ایسا نہیں ہے تو پہلے Docker container traffic کو gluetun کے ذریعے route کریں اور downloads چلنے کے بعد یہاں واپس آئیں۔

services:
  gluetun:
    image: qmcgaw/gluetun:v3.41.3
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8080:8080/tcp
      - 8000:8000/tcp
    volumes:
      - ./gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - VPN_PORT_FORWARDING=on
      - TZ=Etc/UTC
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:5.2.3
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent:/config
      - ./downloads:/downloads
    depends_on:
      - gluetun
    restart: unless-stopped

tag کو pin کریں۔ qmcgaw/gluetun:latest master branch کی پیروی کرتا ہے، جہاں v4 کے لیے port forwarding کے اندرونی حصے تبدیل ہو رہے ہیں۔ اس لیے unpinned image اگلے docker compose pull پر اپنا behavior تبدیل کر سکتی ہے۔ Compose secrets کے لیے env file استعمال کرکے private key کو compose file سے باہر رکھیں۔

وہ جگہ جہاں gluetun فارورڈ کیا گیا port لکھتا ہے

Gluetun یہ port تین جگہوں پر فراہم کرتا ہے، اور تینوں جگہوں پر ایک ہی value ہوتی ہے۔

یہ ہر بار port حاصل ہونے پر اسے ایک مرتبہ log کرتا ہے۔ لائن port forwarded is 45678 ہوتی ہے، اور جب request سے کوئی نتیجہ حاصل نہ ہو تو no port forwarded ہوتی ہے۔

docker logs gluetun 2>&1 | grep -i "port forwarded"

یہ number اس file میں لکھتا ہے جس کا نام VPN_PORT_FORWARDING_STATUS_FILE سے مقرر ہوتا ہے۔ اس کی default value /tmp/gluetun/forwarded_port ہے۔ File میں ہر line پر ایک port ہوتا ہے، اسے mode 0644 کے ساتھ لکھا جاتا ہے، اور اسے container کے PUID اور PGID کو chown کیا جاتا ہے۔ جب forwarding رک جاتی ہے تو gluetun file حذف کرنے کے بجائے اسے خالی کر دیتا ہے۔ اس طرح consumer کو missing file کے بجائے خالی file پڑھنے کو ملتی ہے۔

docker exec gluetun cat /tmp/gluetun/forwarded_port

یہ value control server پر فراہم کرتا ہے۔ یہ server default طور پر :8000 پر listen کرتا ہے اور اسے HTTP_CONTROL_SERVER_ADDRESS سے مقرر کیا جاتا ہے۔

curl -s http://127.0.0.1:8000/v1/portforward

{"port":45678,"ports":[45678]}

Gluetun VPN interface پر اپنے firewall میں بھی یہ port کھول دیتا ہے۔ اس لیے native integration کے کام کرنے کے دوران FIREWALL_VPN_INPUT_PORTS کی ضرورت نہیں ہوتی۔ یہ variable دوسرے معاملے کے لیے ہے: جب provider سے gluetun query نہیں کر سکتا، آپ کو out-of-band ایک static port دیا گیا ہو، اور آپ کو اسے خود allow کرنا پڑے۔

ان تین ذرائع میں سے ایک مستقل ہے اور دو مستقل نہیں ہیں۔ upstream documentation status file کو v4.0.0 میں deprecated قرار دیتی ہے، اور GET /v1/openvpn/portforwarded پہلے ہی 301 Moved Permanently کے ساتھ /v1/portforward کی طرف اشارہ کرتا ہے۔ نئے کام میں control server سے value پڑھنی چاہیے۔

کلائنٹ کو ہر reconnect پر port کیوں بتانا ضروری ہے

Torrent client اپنا listening port اپنی configuration میں محفوظ رکھتا ہے اور restarts کے بعد بھی یہی number استعمال کرتا ہے۔ Forwarded port، VPN session کی property ہوتا ہے۔ Reconnect کے بعد یہ دونوں numbers مختلف ہو جاتے ہیں۔ نتیجتاً provider ایسے port کو map کرتا ہے جس پر کوئی چیز listen نہیں کر رہی ہوتی، جبکہ client ایسے port پر listen کرتا ہے جسے کوئی map نہیں کرتا۔ Reconnects غیر معمولی نہیں ہیں: container restart، server change، ایسا dropped tunnel جسے gluetun کا health check restart کر دے، یا ایسا lease جس کی renewal نہ ہو سکے۔ نتیجہ یہ ہوتا ہے کہ جو setup کل reachable تھا، وہ آج خاموشی سے unreachable ہو جاتا ہے، اور کسی بھی log میں error ظاہر نہیں ہوتی۔

اس لیے gluetun کے port حاصل کرتے ہی اسے apply کرنا ضروری ہے۔ اسے جوڑنے کے دو طریقے ہیں، اور ان میں فرق یہ ہے کہ کام کون سا process انجام دیتا ہے۔

اختیار 1: gluetun، up command کے ذریعے port بھیجتا ہے

VPN_PORT_FORWARDING_UP_COMMAND اس وقت چلتا ہے جب port forwarding فعال ہوتی ہے، اور VPN_PORT_FORWARDING_DOWN_COMMAND اس وقت چلتا ہے جب یہ بند ہو جاتی ہے۔ کمانڈ چلانے سے پہلے Gluetun، {{PORT}} (پہلا port)، {{PORTS}} (تمام ports، comma سے جدا شدہ) اور {{VPN_INTERFACE}} (tunnel interface کا نام، بطور ڈیفالٹ tun0) کو ان کی متعلقہ values سے بدل دیتا ہے۔ Shell syntax کے لیے واضح /bin/sh -c wrapper درکار ہے۔ یہ upstream qBittorrent مثال ہے، جسے Compose کی دو environment entries کے طور پر لکھا گیا ہے:

      - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":{{PORT}},\"current_network_interface\":\"{{VPN_INTERFACE}}\",\"random_port\":false,\"upnp\":false}" http://127.0.0.1:8080/api/v2/app/setPreferences'
      - VPN_PORT_FORWARDING_DOWN_COMMAND=/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":0,\"current_network_interface\":\"lo\"}" http://127.0.0.1:8080/api/v2/app/setPreferences'

اس call کے ہر field کا الگ کام ہے۔ listen_port نیا port ہے۔ current_network_interface qBittorrent کو tunnel سے bind کرتا ہے۔ random_port کو false پر set کرنے سے qBittorrent اگلی بار start ہونے پر اپنا port منتخب نہیں کرتا۔ upnp کو false پر set کرنے سے یہ ایسے router کے ذریعے port map کرنے کی کوشش نہیں کرتا جو موجود ہی نہیں۔

اس طریقۂ کار کے ساتھ دو تقاضے پورے ہونے چاہییں۔ qBittorrent کا web UI فعال ہو اور port 8080 پر listening کر رہا ہو، جبکہ gluetun کا network namespace share کرنے سے qBittorrent، gluetun container کے اندر سے 127.0.0.1:8080 پر جواب دے سکتا ہے۔ اس کے علاوہ Bypass authentication for clients on localhost (bypass_local_auth) فعال ہونا چاہیے، کیونکہ command کوئی credentials نہیں بھیجتی۔ down command اس لیے موجود ہے کہ disconnect کے بعد qBittorrent ہمیشہ port دوبارہ فعال نہیں کرتا۔

یہ command gluetun container کے اندر چلتی ہے، جو Alpine پر مبنی ہے اور اس میں wget شامل ہے۔ اس image میں curl موجود نہیں ہے۔ ایسی binary کا نام دینے والی command جسے image میں موجود ہی نہ ہو، forwarding فعال ہونے پر ہر بار ناکام ہو جاتی ہے۔

آپشن 2: gluetun کے باہر موجود process port پڑھتا ہے

دوسرا طریقہ یہ ہے کہ gluetun کے ساتھ ایک چھوٹا process چلایا جائے جو port حاصل کر کے client کے اپنے API کے ذریعے اسے client میں بھیج دے۔ اسے control server سے پڑھیں:

port=$(curl -s http://127.0.0.1:8000/v1/portforward | jq -r .port)

اگر process یہ file دیکھ سکتا ہو تو اسے file سے پڑھیں۔ /tmp/gluetun/forwarded_port، gluetun container کے اندر موجود ہے، اس لیے sidecar کے لیے دونوں containers میں /tmp/gluetun پر mounted shared volume درکار ہے، یا VPN_PORT_FORWARDING_STATUS_FILE کو ایسے path کی طرف point کریں جو پہلے سے mounted volume کے اندر ہو۔

یہاں authentication اہم ہے۔ v3.41.3 میں GET /v1/portforward، public نامی default role سے متعلق ہے جس میں auth = "none" شامل ہے، اس لیے یہ credentials کے بغیر جواب دیتا ہے، اور gluetun ایسی warning log کرتا ہے جو route GET /v1/portforward is unprotected by default, please set up authentication سے شروع ہوتی ہے۔ Upstream بعد کی release میں اس راستے کو بند کر رہا ہے، اور موجودہ control server documentation پہلے ہی ہر route کو default طور پر private بیان کرتی ہے۔ ابھی ایک role متعین کریں، اس file میں جو /gluetun/auth/config.toml پر bind mounted ہے:

roles = [
  { name = "qbittorrent", routes = ["GET /v1/portforward"], auth = "apikey", apikey = "myapikey" }
]

docker run --rm qmcgaw/gluetun:v3.41.3 genkey سے key بنائیں اور اسے X-API-Key header میں بھیجیں۔ جب file mount نہ کرنا ہو تو HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE ایک JSON-encoded environment variable کے ذریعے یہی کام کرتا ہے۔ جیسے ہی آپ کوئی role متعین کرتے ہیں، v3.41.3 built-in public role کا اطلاق روک دیتا ہے، اس لیے اس کے بعد call کیے جانے والے ہر route کے لیے ایسا role درکار ہوگا جس میں وہ route درج ہو۔ کسی role کے بغیر built-in public role، PUT /v1/vpn/status کو بھی cover کرتا ہے، اس لیے بغیر authentication configuration کے published port 8000 ہر اس شخص کو VPN state پر control دے دیتا ہے جو اس تک پہنچ سکتا ہو۔ gluetun تک host اور دیگر containers سے کیسے پہنچنا ہے طے کرتے وقت جان بوجھ کر فیصلہ کریں کہ یہ access کہاں تک پھیلایا جائے۔

جب client ایسا API فراہم کرے جسے ایک wget call چلا سکتی ہو تو up command منتخب کریں، کیونکہ یہ ہر event پر بالکل ایک بار چلتی ہے اور اسے مسلسل running رکھنے کے لیے کچھ درکار نہیں ہوتا۔ جب client کو login flow، config file rewrite یا restart درکار ہو تو external process منتخب کریں۔ ایک gluetun container کے پیچھے موجود stack میں عموماً نتیجہ ایک چھوٹے poller کی صورت میں نکلتا ہے، کیونکہ port کی ضرورت صرف torrent client کو ہوتی ہے۔

جال: network namespace شیئر کرنے سے listening port set نہیں ہوتا

یہ خرابی سب سے زیادہ وقت ضائع کرتی ہے۔ network_mode: "service:gluetun" کلائنٹ کو gluetun کے network namespace میں شامل کرتا ہے، اس لیے اسے VPN address، tunnel routes اور gluetun کے firewall rules ملتے ہیں۔ ان میں سے کوئی بھی setting کلائنٹ کا listening port set نہیں کرتی۔ gluetun VPN interface پر forwarded port کھولتا ہے، اس کے packets namespace میں پہنچتے ہیں، اور اگر کلائنٹ کسی مختلف port پر listen کر رہا ہو تو kernel کے پاس انہیں پہنچانے کے لیے کوئی عمل نہیں ہوتا۔ اس لیے connection refuse ہو جاتا ہے یا timeout ہو جاتا ہے، جبکہ outbound checks درست نظر آتے ہیں۔ forwarded port اور کلائنٹ کا listening port دو الگ numbers ہیں، اور انہیں برابر رکھنا ہی اصل کام ہے۔

قیاس کرنے کے بجائے دونوں کا موازنہ کریں۔ دونوں commands اسی namespace کے خلاف چلائیں:

docker exec gluetun cat /tmp/gluetun/forwarded_port
docker exec gluetun wget -qO- http://127.0.0.1:8080/api/v2/app/preferences | grep -o '"listen_port":[0-9]*'

ایک اور setting لوگوں کو غلط سمت میں لے جاتی ہے۔ VPN_PORT_FORWARDING_LISTENING_PORT iptables کے ذریعے forwarded port سے آنے والی inbound traffic کو ایک مقررہ local port پر redirect کرتا ہے۔ Upstream کی ہدایت ہے کہ اسے torrent clients کے ساتھ استعمال نہ کریں، کیونکہ کلائنٹ trackers اور peers کو اپنا listening port خود بتاتا ہے، اس لیے swarm کو غلط number معلوم ہوتا ہے۔

فارورڈ کیے گئے port کے قابل رسائی ہونے کا ثبوت کیسے دیں

کلائنٹ کا اپنا connection indicator باہر جانے والے tracker connections کو ظاہر کرتا ہے، اس لیے کچھ بھی آپ تک نہ پہنچنے کے باوجود یہ سبز دکھائی دے سکتا ہے۔ اس کی جانچ ایسے listener سے کریں جس پر آپ کا کنٹرول ہو، اور اسے tunnel سے باہر موجود network سے چلائیں۔ Upstream اس مقصد کے لیے ایک چھوٹا tool فراہم کرتا ہے۔ پہلے torrent client کو روک دیں، کیونکہ دو processes ایک ہی port پر bind نہیں ہو سکتے۔

docker stop qbittorrent
docker exec -it gluetun /bin/sh

Container کے اندر اپنی CPU architecture کے مطابق amd64 تبدیل کریں، اور 4567 میں اپنا forwarded port درج کریں:

wget -qO port-checker https://github.com/qdm12/port-checker/releases/download/v0.4.0/port-checker_0.4.0_linux_amd64
chmod +x port-checker
./port-checker --listening-address=":4567"

اب وہ exit address معلوم کریں جسے gluetun استعمال کر رہا ہے۔ جواب JSON ہوگا، اور address public_ip field میں موجود ہوگا۔

curl -s http://127.0.0.1:8000/v1/publicip/ip

یہ سادہ request صرف اسی وقت جواب دیتی ہے جب v3.41.3 بغیر auth config کے چل رہا ہو۔ اگر آپ نے Option 2 کے مطابق roles متعین کیے ہیں تو کسی role کے routes میں GET /v1/publicip/ip شامل کریں، اور اس role کی key بھیجیں، مثلاً curl -s -H "X-API-Key: myapikey" http://127.0.0.1:8000/v1/publicip/ip۔

http://<that address>:4567 کو ایسے device سے کھولیں جو اسی VPN پر نہ ہو۔ mobile data استعمال کرنے والا phone کافی ہے۔ اگر صفحہ آپ کے browser کا IP address اور user agent دکھائے، اور port-checker میں اسی request کا log بھی موجود ہو، تو اس کا مطلب ہے کہ inbound TCP namespace تک پہنچ رہا ہے۔ timeout کا مطلب ہے کہ یہ نہیں پہنچ رہا، اور مسئلہ client سے اوپر کی سطح پر ہے۔ tool کو CTRL+C سے روکیں، exit کے ذریعے shell سے باہر نکلیں، اور client دوبارہ شروع کریں۔ یہ جانچ صرف TCP کو آزماتی ہے۔ DHT (distributed hash table) اور uTP traffic اسی port number پر UDP استعمال کرتے ہیں، جس کا احاطہ یہ test نہیں کرتا۔

خرابی کی صورتیں اور وہ strings جو آپ دیکھیں گے

log میں port کی کوئی line موجود نہیں۔ کسی component نے port طلب نہیں کیا۔ docker exec gluetun printenv | grep PORT_FORWARDING کے ذریعے تصدیق کریں کہ variable واقعی container تک پہنچی ہے، کیونکہ غلط compose service میں variable set ہونا اس مسئلے کی عام وجہ ہے۔

Gluetun start ہونے سے انکار کرتا ہے اور provider کے بارے میں error دیتا ہے۔ VPN_PORT_FORWARDING_PROVIDER کو supported چار names کے خلاف validate کیا جاتا ہے، اس لیے typo کی صورت میں container خاموشی سے forwarding کے بغیر چلنے کے بجائے رک جاتا ہے۔

log میں no port forwarded لکھا ہے۔ Gluetun نے درخواست بھیجی، لیکن provider نے کوئی port واپس نہیں کیا۔ ProtonVPN پر عموماً اس کا مطلب ہے کہ آپ کی generated configuration میں NAT-PMP enabled نہیں تھا، یا آپ کے plan میں port forwarding شامل نہیں ہے۔ Private Internet Access پر عموماً اس کا مطلب ہے کہ منتخب server یہ سہولت فراہم نہیں کرتا۔

port موصول ہو جاتا ہے، لیکن کوئی connection اندر نہیں آتا۔ اوپر دی گئی دونوں commands استعمال کرکے forwarded port کا client کے listening port سے موازنہ کریں۔ اگر دونوں ایک جیسے ہوں تو تصدیق کریں کہ client tunnel interface پر bound ہے اور اس کا random-port option بند ہے، کیونکہ یہ option ہر start پر listening port تبدیل کر دیتا ہے۔

up command بظاہر کچھ نہیں کرتا۔ error دیکھنے کے لیے container کے اندر یہی exact command چلائیں: docker exec gluetun /bin/sh -c '<your command>'۔ curl: not found عام نتیجہ ہے، کیونکہ image صرف wget فراہم کرتی ہے۔

control server سے 401 Unauthorized۔ آپ نے auth config define کی ہے، لیکن کسی role میں اس route کی فہرست شامل نہیں جسے آپ call کر رہے ہیں۔ ہر route کو method اور path کے مجموعے کے طور پر لکھا جاتا ہے، جیسے GET /v1/portforward۔ صرف /v1/portforward کے طور پر لکھی گئی route 401 پیدا نہیں کرتی؛ اس کے بجائے gluetun startup کے وقت fail ہو جاتا ہے۔

ہر restart کے بعد Private Internet Access پر مختلف port ملتا ہے۔ /gluetun کو bind mount کریں تاکہ saved port state restart کے بعد بھی برقرار رہے۔ اس volume کے بغیر gluetun ہر بار نیا port request کرتا ہے۔

FAQ

میرے torrents download تو ہو جاتے ہیں، لیکن incoming connections کیوں نہیں ملتیں؟

Forwarded port کے بغیر VPN provider کے پاس ایسا NAT rule نہیں ہوتا جو کسی بھی port پر آنے والے inbound packets کو آپ کے tunnel تک بھیجے۔ اس لیے وہ connections جو آپ نے خود شروع نہیں کیں، exit address پر drop ہو جاتی ہیں۔ Downloads پھر بھی کام کرتے ہیں، کیونکہ آپ کا client خود یہ connections کھولتا ہے اور ہر ایسے peer تک پہنچ سکتا ہے جس سے connect ہونا ممکن ہو۔ Seeding اور swarm میں شامل ہونے کا عمل متاثر ہوتا ہے، کیونکہ دونوں کے لیے دوسرے users کا آپ تک پہنچنا ضروری ہے۔ حل یہ ہے کہ ایسا provider استعمال کریں جو port forwarding فراہم کرتا ہو، gluetun میں VPN_PORT_FORWARDING=on استعمال کریں، اور اس کے نتیجے میں ملنے والا port client کے listening port پر apply کریں۔

کیا gluetun ہر VPN provider کی port forwarding کے ساتھ کام کرتا ہے؟

نہیں۔ gluetun v3.41.3 میں چار providers کے لیے native integration موجود ہے: Private Internet Access، ProtonVPN، Perfect Privacy اور PrivateVPN۔ اس فہرست سے باہر کا کوئی بھی provider VPN_PORT_FORWARDING_PROVIDER کے لیے validation میں ناکام ہو جاتا ہے، اور container startup کے وقت رک جاتا ہے۔ اگر آپ کا provider اپنے control panel کے ذریعے static port جاری کرتا ہے تو gluetun اسے آپ کے لیے request نہیں کر سکتا، لیکن FIREWALL_VPN_INPUT_PORTS اس fixed port کو gluetun کے firewall سے گزرنے دے گا۔ Provider کی policies تبدیل ہو سکتی ہیں، اس لیے اس مقصد کے لیے plan خریدنے سے پہلے provider کا موجودہ صفحہ دیکھیں۔

کیا ہر reconnect کے بعد port update کرنا ضروری ہے؟

ہاں، اور یہ update خودکار ہونا چاہیے۔ Forwarded port VPN session سے وابستہ ہوتا ہے۔ اس لیے container restart، server change یا ناکام lease renewal کے نتیجے میں نیا number مل سکتا ہے، جبکہ client اپنی configuration میں پرانا port محفوظ رکھتا ہے۔ یا تو gluetun کو VPN_PORT_FORWARDING_UP_COMMAND کے ذریعے یہ port client تک پہنچانے دیں؛ یہ forwarding فعال ہوتے ہی چلتا ہے۔ دوسرا طریقہ یہ ہے کہ ایک چھوٹا process چلائیں جو control server سے GET /v1/portforward پڑھ کر API کے ذریعے یہ value client میں لکھ دے۔

میں کیسے جانچوں کہ forwarded port واقعی open ہے؟

gluetun کے network namespace کے اندر اسی port پر listener چلائیں اور VPN کے باہر سے اس سے connect کریں۔ پہلے torrent client کو stop کریں تاکہ port خالی ہو۔ پھر gluetun container کے اندر upstream port-checker binary کو --listening-address=":<port>" کے ساتھ چلائیں۔ curl -s http://127.0.0.1:8000/v1/publicip/ip سے exit address حاصل کریں۔ اگر آپ نے control server auth configure کیا ہے تو GET /v1/publicip/ip درج کرنے والے role کے لیے -H "X-API-Key: <key>" شامل کریں، اور mobile data استعمال کرنے والے phone سے http://<address>:<port> کھولیں۔ Port-checker log میں request ظاہر ہونا ثابت کرتا ہے کہ inbound TCP پہنچ رہا ہے۔ Timeout کا مطلب ہے کہ inbound traffic نہیں پہنچ رہا، چاہے client کا اپنا status icon کچھ بھی دکھائے۔