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 اس کے بند ہونے پر چلتا ہے۔ command چلانے سے پہلے Gluetun {{PORT}} (پہلا port)، {{PORTS}} (تمام ports، comma-separated) اور {{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 کرنے کی کوشش نہیں کرتا جو موجود نہیں ہے۔

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

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

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

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

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

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

یہاں 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 میں یہ راستہ بند کر رہا ہے۔ ابھی ایک role بنائیں، اس فائل میں جو /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 میں بھیجیں۔ جب آپ فائل mount نہیں کرنا چاہتے تو HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE، ایک JSON-encoded environment variable کے برابر کام کرتا ہے۔ کسی role کے بغیر published port 8000 ہر اس شخص کو VPN state control کرنے دیتا ہے جو اس تک پہنچ سکتا ہو۔ اس لیے طے کریں کہ gluetun سے host اور دوسرے containers تک رسائی کیسے دینی ہے، جیسا کہ gluetun تک host اور دوسرے containers سے پہنچنے کا طریقہ میں بیان کیا گیا ہے۔

جب client ایسا API فراہم کرے جسے ایک wget call چلا سکے تو up command منتخب کریں، کیونکہ یہ ہر event پر عین ایک مرتبہ چلتا ہے اور مسلسل چلتے رہنے کے لیے کسی process کی ضرورت نہیں ہوتی۔ جب client کو login flow، config file rewrite یا restart درکار ہو تو external process منتخب کریں۔ ایک gluetun container کے پیچھے arr 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 کی رسائی ثابت کرنے کا طریقہ

Client کا اپنا connection indicator باہر کی طرف tracker connections کو ظاہر کرتا ہے۔ اس لیے جب کوئی بھی بیرونی connection آپ تک نہ پہنچ رہا ہو، تب بھی indicator سبز دکھائی دے سکتا ہے۔ اس کی جانچ ایسے 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"

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

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

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

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

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

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

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

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

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

Control server سے 401 Unauthorized۔ آپ نے auth config تعریف کی ہے، لیکن role میں وہ route شامل نہیں جسے آپ call کر رہے ہیں۔ Routes کو method اور path کے مجموعے کے طور پر match کیا جاتا ہے۔ اس لیے صرف /v1/portforward درج کرنے والا role، GET /v1/portforward کو cover نہیں کرتا۔

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

FAQ

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

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

کیا 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 آپ کی طرف سے اس کی درخواست نہیں کر سکتا، لیکن FIREWALL_VPN_INPUT_PORTS اس fixed port کو gluetun کے firewall سے گزرنے دے گا۔ Provider policies تبدیل ہوتی رہتی ہیں، اس لیے اس مقصد کے لیے plan خریدنے سے پہلے موجودہ provider page دیکھیں۔

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

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

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

gluetun کے network namespace کے اندر اسی port پر listener چلائیں اور VPN کے باہر سے اس سے connect کریں۔ پہلے torrent client بند کریں تاکہ port خالی ہو، پھر --listening-address=":<port>" کے ذریعے upstream port-checker binary کو gluetun container کے اندر چلائیں۔ curl -s http://127.0.0.1:8000/v1/publicip/ip سے exit address حاصل کریں اور mobile data استعمال کرنے والے phone سے http://<address>:<port> کھولیں۔ port-checker log میں request ظاہر ہونا ثابت کرتا ہے کہ inbound TCP پہنچ رہا ہے۔ Timeout کا مطلب ہے کہ inbound connection نہیں پہنچ رہا، چاہے client کا اپنا status icon کچھ بھی دکھائے۔