Gluetun Port Forwarding: Torrent Client সেটআপ

ফরওয়ার্ড করা port ছাড়া কোনো inbound connection কেন আসে না

Gluetun-এর port forwarding আপনার VPN provider-কে তার exit address-এ একটি public port বরাদ্দ করতে বলে, যাতে সেই port থেকে আসা connection আপনার container-এ পাঠানো যায়। আপনার torrent client-এর দিকে অন্য কোনো peer connection শুরু করার এটিই একমাত্র উপায়। এই mapping না থাকলে tunnel সচল থাকে, download চলতে থাকে, কিন্তু কোনো connection নিজে থেকে আপনার কাছে আসে না। কার্যকর প্রতিটি connection আপনার client-ই প্রথমে শুরু করে।

এর পেছনে কাজ করে NAT (network address translation)। আপনার container একই provider exit address অনেক অন্য গ্রাহকের সঙ্গে ভাগ করে। আপনার client বাইরে একটি connection খুললে provider সেই flow-এর তথ্য সংরক্ষণ করে এবং reply-গুলো আপনার tunnel দিয়ে ফেরত পাঠায়। কোনো অপরিচিত peer ভেতরে connection শুরু করলে তার সঙ্গে সংরক্ষিত কোনো flow মেলে না। তাই packet exit address-এ পৌঁছে সেখানেই বাতিল হয়। আপনার client নিজে connectable থাকা প্রতিটি peer-এ পৌঁছাতে পারে। ফলে download শেষ হয় এবং সমস্যাটি চোখে পড়ে না। Seeding-এর সময় সমস্যাটি স্পষ্ট হয়, কারণ seeder হলো এমন একটি machine যার সঙ্গে অন্যরা connection স্থাপন করে।

একটি open inbound port দুটি পরিবর্তন আনে। আপনি swarm-এ দ্রুত যুক্ত হন, কারণ যারা নিজেরা connection গ্রহণ করতে পারে না তারাও তখন আপনার কাছে পৌঁছাতে পারে। একই কারণে আপনি সেই peer-গুলোকে upload-ও করতে পারেন।

শেয়ার করা address-এ forwarded port একটি সীমিত resource। Provider একটি customer-এর জন্য একটি exit IP-তে একটি port number বরাদ্দ করে এবং ওই customer সেটি দিয়ে যা করে, তার দায় provider-কে নিতে হয়। কয়েকটি বড় provider এই feature সরিয়ে দিয়েছে এবং abuse handling-কে কারণ হিসেবে উল্লেখ করেছে। Support-কে শুধু checkbox হিসেবে যাচাই করবেন না; বরং জিজ্ঞাসা করুন, provider বর্তমানে port forwarding দেয় কি না, আপনার plan-এ এটি আছে কি না, এবং আপনি বাস্তবে যে server নির্বাচন করতে পারেন সেগুলোতে এটি ব্যবহার করা যায় কি না।

যেখানে forwarding আছে, সেখানে port-টি dynamic। এটি আপনার account-এর নয়, VPN session-এর সঙ্গে যুক্ত। তাই প্রতিবার reconnect করার পরে port 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)-এর মাধ্যমে একটি short lease-এ random port বরাদ্দ করে, যা নিয়মিত renew করতে হয়। তাই client-এ একবার port সেট করলেই সেটি সব সময় কাজ করে না।

যে provider-গুলোর কাছে gluetun port চাইতে পারে

gluetun v3.41.3 অনুযায়ী, যা 30 July 2026-এ released হয়েছে, native integration চারটি provider name যাচাই করে: Private Internet Access, ProtonVPN, Perfect Privacy এবং PrivateVPN। এটি চালু করতে VPN_PORT_FORWARDING=on ব্যবহার করুন; এর default মান off। পুরোনো guide-গুলোতে PORT_FORWARDING বা PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING ব্যবহার করা হয়। retro-compatible name হিসেবে এই version-এ দুটিই এখনও কাজ করে, তবে দুটিই ধীরে ধীরে বাদ দেওয়া হচ্ছে।

দুটি provider-specific বিষয় নির্ধারণ করে request আদৌ সফল হবে কি না। ProtonVPN-এর জন্য paid plan প্রয়োজন এবং NAT-PMP চালু থাকতে হবে: WireGuard configuration তৈরি করার সময় VPN options-এর অধীনে NAT-PMP (Port Forwarding) চালু করুন, অথবা OpenVPN ব্যবহার করলে username-এর শেষে +pmp যোগ করুন। OpenVPN-এ Private Internet Access-এর জন্য PORT_FORWARD_ONLY রয়েছে। এটি server selection এমন server-এ সীমাবদ্ধ করে যেগুলো port forwarding সমর্থন করে, ফলে যেসব server-এ এই সুবিধা কখনও ছিল না সেগুলো নির্বাচিত হয় না। WireGuard এবং OpenVPN-এ port request করার পদ্ধতি ভিন্ন, তাই provider-এর page পড়ে তারপর সিদ্ধান্ত নিন।

built-in provider-এর বদলে gluetun custom configuration ব্যবহার করলে, gluetun যে API-তে call করবে তার নাম VPN_PORT_FORWARDING_PROVIDER নির্ধারণ করে। upstream Private Internet Access page-এ এই variable-এর সঙ্গে VPN_PORT_FORWARDING_USERNAME এবং VPN_PORT_FORWARDING_PASSWORD দেওয়া থাকে। এগুলো port request-এর জন্য প্রয়োজনীয় account credential বহন করে।

Docker Compose-এ gluetun port forwarding চালু করুন

এখানে ধরে নেওয়া হচ্ছে যে tunnel ইতিমধ্যে কাজ করছে। কাজ না করলে প্রথমে Docker container-এর traffic gluetun-এর মাধ্যমে route করুন অনুসরণ করুন। Download চলা শুরু হলে এই অংশে ফিরে আসুন।

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 নির্দিষ্ট করে দিন। qmcgaw/gluetun:latest master branch অনুসরণ করে। সেখানে v4-এর জন্য port forwarding-এর অভ্যন্তরীণ ব্যবস্থা পরিবর্তন করা হচ্ছে। তাই image-এর tag নির্দিষ্ট না করলে পরবর্তী docker compose pull-এ আচরণ বদলে যেতে পারে। compose secret-এর জন্য env file ব্যবহার করে private key-টি compose file-এর বাইরে রাখুন।

Gluetun forwarded port কোথায় লেখে

Gluetun তিনটি জায়গায় port প্রকাশ করে, এবং প্রতিটিতেই একই value থাকে।

প্রতিটি port acquisition-এর সময় এটি একবার log লেখে। লাইনটি port forwarded is 45678 হয়, আর request থেকে কোনো ফল না এলে no port forwarded হয়।

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

এটি VPN_PORT_FORWARDING_STATUS_FILE দ্বারা নির্ধারিত file-এ number লেখে। এর default হলো /tmp/gluetun/forwarded_port। File-এ প্রতি line-এ একটি করে port থাকে, এটি 0644 mode-এ লেখা হয় এবং container-এর PUID ও PGID-এর মালিকানায় chown করা হয়। Forwarding বন্ধ হলে gluetun file-টি মুছে না দিয়ে খালি করে। ফলে consumer missing file-এর error পাওয়ার বদলে একটি empty file পড়তে পারে।

docker exec gluetun cat /tmp/gluetun/forwarded_port

এটি control server-এ value পরিবেশন করে। Control server-এর default listen port হলো :8000, এবং এটি 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 করতে হবে।

এই তিনটির মধ্যে একটি durable, আর দুটি durable নয়। Upstream documentation status file-টিকে v4.0.0-এ deprecated হিসেবে চিহ্নিত করেছে। এছাড়া GET /v1/openvpn/portforwarded ইতিমধ্যে 301 Moved Permanently দিয়ে উত্তর দেয়, যেখানে /v1/portforward-এর দিকে নির্দেশ করা থাকে। নতুন কাজের ক্ষেত্রে control server থেকে value পড়া উচিত।

প্রতিবার পুনরায় সংযোগের সময় client-কে port জানাতে হবে কেন

একটি torrent client তার নিজস্ব configuration-এ listening port সংরক্ষণ করে এবং restart-এর পরেও সেই port নম্বর ব্যবহার করে। Forwarded port হলো VPN session-এর একটি বৈশিষ্ট্য। পুনরায় সংযোগের পর এই দুই নম্বরের মধ্যে অমিল হয়। ফলে provider এমন একটি port map করে, যেখানে কোনো process listen করছে না; client-ও এমন একটি port-এ listen করে, যেটি কোনো mapping-এর সঙ্গে যুক্ত নয়। Reconnect বিরল ঘটনা নয়। Container restart, server পরিবর্তন, gluetun-এর health check দ্বারা restart হওয়া বিচ্ছিন্ন tunnel, অথবা renew করা যায়নি এমন lease—এসব কারণে reconnect হতে পারে। এর ফল হলো, setup-টি গতকাল reachable থাকলেও আজ নীরবে unreachable হয়ে যায়; কোনো log-এই error দেখা যায় না।

তাই gluetun port সংগ্রহ করার সঙ্গে সঙ্গেই সেটি প্রয়োগ করতে হবে। এটি সংযুক্ত করার দুটি উপায় আছে। কোন process কাজটি করবে, তার ওপর এই দুই পদ্ধতির পার্থক্য নির্ভর করে।

বিকল্প 1: gluetun up command ব্যবহার করে port পাঠায়

Port forwarding চালু হলে VPN_PORT_FORWARDING_UP_COMMAND চলে, আর বন্ধ হলে VPN_PORT_FORWARDING_DOWN_COMMAND চলে। Command চালানোর আগে Gluetun {{PORT}} (প্রথম port), {{PORTS}} (সব port, comma দিয়ে আলাদা করা) এবং {{VPN_INTERFACE}} (tunnel interface-এর নাম, ডিফল্টভাবে tun0) বসিয়ে দেয়। Shell syntax-এর জন্য স্পষ্টভাবে /bin/sh -c wrapper প্রয়োজন। এটি upstream qBittorrent example, যা compose-এর দুটি environment entry হিসেবে লেখা হয়েছে:

      - 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 সেট করলে পরবর্তী start-এর সময় qBittorrent নিজে port বেছে নেয় না। upnp-এর মান false সেট করলে উপস্থিত নয় এমন router-এর মাধ্যমে port map করার চেষ্টা বন্ধ হয়।

এই পদ্ধতিতে দুটি শর্ত আছে। qBittorrent-এর web UI enabled থাকতে হবে এবং port 8080-এ listening করতে হবে। gluetun-এর network namespace share করলেই qBittorrent gluetun container-এর ভেতর থেকে 127.0.0.1:8080-এ সাড়া দিতে পারে। এছাড়া Bypass authentication for clients on localhost (bypass_local_auth) enabled থাকতে হবে, কারণ command কোনো credential পাঠায় না। Disconnect-এর পরে qBittorrent সব সময় port পুনঃপ্রতিষ্ঠা করে না বলে down command-টিও রাখা হয়েছে।

Command-টি gluetun container-এর ভেতরে চলে। Container-টি Alpine-এর ওপর তৈরি এবং এতে wget রয়েছে। ওই image-এ curl নেই। Image-এ অনুপস্থিত কোনো binary-এর নাম command-এ দিলে forwarding চালু হওয়ার প্রতিবারই command ব্যর্থ হবে।

বিকল্প 2: gluetun-এর বাইরে একটি process port পড়ে

অন্য পদ্ধতিতে gluetun-এর পাশে একটি ছোট process চালানো হয়। এটি port সংগ্রহ করে এবং client-এর নিজস্ব API ব্যবহার করে সেই port client-এ পাঠায়। control server থেকে port পড়ুন:

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

অথবা process সেটি দেখতে পারলে file পড়ুন। /tmp/gluetun/forwarded_port gluetun container-এর ভিতরে থাকে। তাই sidecar-এর জন্য উভয় container-এ /tmp/gluetun-এ একটি shared volume mount করতে হবে। অথবা ইতিমধ্যে mount করা কোনো volume-এর অধীনে থাকা path-এ VPN_PORT_FORWARDING_STATUS_FILE নির্দেশ করুন।

এখানে authentication গুরুত্বপূর্ণ। v3.41.3-এ GET /v1/portforward route-টি public নামের একটি default role-এর অন্তর্ভুক্ত এবং এতে auth = "none" আছে। তাই credentials ছাড়াই এটি response দেয়। gluetun তখন route GET /v1/portforward is unprotected by default, please set up authentication দিয়ে শুরু হওয়া একটি warning log করে। পরবর্তী release-এ upstream এই access বন্ধ করছে। বর্তমান control server documentation-এও প্রতিটি route-কে default হিসেবে private বলা হয়েছে। এখনই একটি role define করুন। এটি /gluetun/auth/config.toml-এ bind mounted file-এ লিখুন:

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

docker run --rm qmcgaw/gluetun:v3.41.3 genkey দিয়ে একটি key generate করুন এবং সেটি X-API-Key header-এ পাঠান। কোনো file mount করতে না চাইলে HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE একটি JSON-encoded environment variable-এর মতো একই কাজ করে। কোনো role define করলে v3.41.3 আর built-in public role প্রয়োগ করে না। তাই এরপর call করা প্রতিটি route-এর তালিকায় সেই route থাকা একটি role প্রয়োজন। কোনো role না থাকলে built-in public role-টি PUT /v1/vpn/status-এর ক্ষেত্রেও প্রযোজ্য হয়। ফলে কোনো auth config ছাড়াই publish করা port 8000-এ যেকেউ পৌঁছাতে পারলে VPN state নিয়ন্ত্রণ করতে পারে। host এবং অন্যান্য container থেকে gluetun-এ কীভাবে পৌঁছাবেন তা নির্ধারণ করার সময় access কত দূর পর্যন্ত যাবে, সেটি ইচ্ছাকৃতভাবে ঠিক করুন।

client এমন API প্রকাশ করলে up command বেছে নিন, যেখানে একটি wget call-এই কাজটি করা যায়। কারণ এটি প্রতিটি event-এ ঠিক একবার চলে এবং চলমান রাখার জন্য অতিরিক্ত কিছু যোগ করে না। client-এর login flow, config file rewrite বা restart প্রয়োজন হলে external process বেছে নিন। একটি gluetun container-এর পেছনে একটি arr stack ব্যবহার করলে সাধারণত একটি ছোট poller-ই যথেষ্ট। কারণ port-টির প্রয়োজন শুধু torrent client-এর।

ফাঁদ: namespace শেয়ার করলেই listening port নির্ধারিত হয় না

এই সমস্যাটি সমাধান করতে সবচেয়ে বেশি সময় লাগে। network_mode: "service:gluetun" client-কে gluetun-এর network namespace-এ যুক্ত করে। তাই client-টি VPN address, tunnel route এবং gluetun-এর firewall rule পায়। কিন্তু এর কোনোটিই client-এর listening port নির্ধারণ করে না। Gluetun VPN interface-এ forwarded port খুলে দেয়। সেই port-এর packet namespace-এ পৌঁছায়। client অন্য port-এ listen করলে kernel সেগুলো কোনো process-এ পাঠাতে পারে না। ফলে outbound check-গুলো স্বাভাবিক দেখালেও connection refused হয় অথবা timeout হয়। forwarded port এবং client-এর listening port দুটি আলাদা number। দুটি একই রাখা পুরো কাজের মূল বিষয়।

অনুমান না করে port দুটি তুলনা করুন। দুটি command-ই একই 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 client-এর সঙ্গে এটি ব্যবহার না করতে বলেছে। কারণ client tracker ও peer-কে নিজের listening port জানায়। ফলে swarm ভুল number জানতে পারে।

ফরওয়ার্ড করা port-এ পৌঁছানো যায় তা কীভাবে প্রমাণ করবেন

ক্লায়েন্টের নিজস্ব connection indicator কেবল outbound tracker connection দেখায়। তাই কোনো inbound connection আপনার কাছে না পৌঁছালেও indicator সবুজ দেখাতে পারে। Tunnel-এর বাইরের একটি network থেকে আপনার নিয়ন্ত্রণাধীন listener ব্যবহার করে পরীক্ষা করুন। Upstream এ জন্য একটি ছোট tool প্রকাশ করে। প্রথমে torrent client বন্ধ করুন, কারণ দুটি process একই port-এ bind করতে পারে না।

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

Container-এর ভিতরে আপনার CPU architecture অনুযায়ী amd64 এবং forwarded port অনুযায়ী 4567 পরিবর্তন করুন:

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 format-এ আসে এবং address-টি public_ip field-এ থাকে।

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

এই সরাসরি request কেবল তখনই উত্তর দেয়, যখন v3.41.3 কোনো auth config ছাড়া চলছে। Option 2-এ দেখানো পদ্ধতিতে role সংজ্ঞায়িত করলে, একটি role-এর routes-এ GET /v1/publicip/ip যোগ করুন এবং সেই role-এর key পাঠান, যেমন curl -s -H "X-API-Key: myapikey" http://127.0.0.1:8000/v1/publicip/ip।

VPN-এ থাকা device নয়, এমন কোনো device থেকে http://<that address>:4567 খুলুন। Mobile data ব্যবহার করা একটি phone এ জন্য যথেষ্ট। এমন একটি page দেখা গেলে যেখানে আপনার browser-এর IP address ও user agent দেখানো হয় এবং port-checker-এর log-এ matching request থাকে, তাহলে inbound TCP namespace-এ পৌঁছাচ্ছে। Timeout হলে বুঝতে হবে এটি পৌঁছাচ্ছে না এবং কারণটি client-এর উপরের স্তরে রয়েছে। CTRL+C দিয়ে tool বন্ধ করুন, exit দিয়ে shell থেকে বেরিয়ে আসুন এবং client আবার চালু করুন। এই পরীক্ষা কেবল TCP যাচাই করে। DHT (distributed hash table) এবং uTP traffic একই port number-এ UDP ব্যবহার করে, যা এই পরীক্ষায় অন্তর্ভুক্ত নয়।

ব্যর্থতার ধরন এবং যে বার্তাগুলো দেখবেন

লগে কোনো port line নেই। কোনো কিছু port চায়নি। docker exec gluetun printenv | grep PORT_FORWARDING ব্যবহার করে নিশ্চিত করুন যে variable-টি সত্যিই container-এ পৌঁছেছে। ভুল compose service-এ variable সেট করা এর সাধারণ কারণ।

Gluetun start হতে অস্বীকার করে এবং provider নিয়ে error দেখায়। VPN_PORT_FORWARDING_PROVIDER চারটি সমর্থিত নামের সঙ্গে যাচাই করা হয়। তাই বানান ভুল হলে container চালু না হয়ে থেমে যায়; forwarding ছাড়া নীরবে চলতে থাকে না।

লগে no port forwarded দেখা যায়। Gluetun অনুরোধ করেছে, কিন্তু provider কোনো port ফেরত দেয়নি। ProtonVPN-এ এর সাধারণ কারণ হলো আপনার তৈরি করা configuration-এ NAT-PMP enabled না থাকা, অথবা আপনার plan-এ forwarding অন্তর্ভুক্ত না থাকা। Private Internet Access-এ সাধারণত এর অর্থ হলো নির্বাচিত server এটি সমর্থন করে না।

একটি port পাওয়া যায়, কিন্তু কোনো সংযোগ ভেতরে আসে না। উপরের দুটি command ব্যবহার করে forwarded port এবং client-এর listening port তুলনা করুন। দুটির মান এক হলে পরীক্ষা করুন যে client-টি tunnel interface-এ bind করা আছে এবং random-port option বন্ধ আছে। কারণ প্রতিবার start হওয়ার সময় ওই option 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 নির্ধারণ করেছেন, কিন্তু আপনি যে route call করছেন তার জন্য কোনো role-এ তালিকা নেই। প্রতিটি route method এবং path মিলিয়ে লেখা হয়, যেমন GET /v1/portforward। শুধু /v1/portforward হিসেবে লেখা route 401 তৈরি করে না; এর পরিবর্তে gluetun start হওয়ার সময় ব্যর্থ হয়।

প্রতিটি restart-এর পরে Private Internet Access-এ ভিন্ন port পাওয়া যায়। /gluetun bind mount করুন, যাতে সংরক্ষিত port state restart-এর পরেও থাকে। এই volume ছাড়া gluetun প্রতিবার নতুন port চায়।

FAQ

আমার torrent download হয়, কিন্তু কখনো incoming connection আসে না কেন?

Port forward করা না থাকলে VPN provider-এর কোনো NAT rule থাকে না, যা কোনো port-এর inbound packet আপনার tunnel-এ পাঠাতে পারে। তাই আপনি নিজে শুরু করেননি এমন connection exit address-এ গিয়েই বাদ পড়ে। Download তবু কাজ করে, কারণ আপনার client নিজেই connection খোলে এবং connectable যেকোনো peer-এ পৌঁছাতে পারে। Seeding এবং swarm-এ যোগ দেওয়া বাধাগ্রস্ত হয়, কারণ উভয় ক্ষেত্রেই অন্য ব্যবহারকারীদের আপনার কাছে পৌঁছাতে হয়। এর সমাধান হলো এমন provider ব্যবহার করা, যা port forwarding দেয়, gluetun-এ VPN_PORT_FORWARDING=on সেট করা, এবং পাওয়া port-টি client-এর listening port হিসেবে প্রয়োগ করা।

gluetun কি যেকোনো VPN provider-এর port forwarding-এর সঙ্গে কাজ করে?

না। gluetun v3.41.3-এ চারটি provider-এর জন্য 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 ব্যবহার করলে ওই নির্দিষ্ট port-টি gluetun-এর firewall-এর মধ্য দিয়ে যেতে দেওয়া হবে। Provider-এর policy পরিবর্তিত হতে পারে। তাই এর জন্য plan কেনার আগে বর্তমান provider page পরীক্ষা করুন।

প্রতিবার reconnect হওয়ার পরে কি আমাকে port update করতে হবে?

হ্যাঁ। এই update স্বয়ংক্রিয় হওয়া উচিত। Forwarded port VPN session-এর সঙ্গে যুক্ত থাকে। তাই container restart, server পরিবর্তন বা lease renewal ব্যর্থ হলে নতুন port 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-এর বাইরে থেকে তাতে connection করুন। প্রথমে torrent client বন্ধ করুন, যাতে port-টি খালি থাকে। এরপর --listening-address=":<port>" ব্যবহার করে gluetun container-এর ভিতরে upstream port-checker binary চালান। curl -s http://127.0.0.1:8000/v1/publicip/ip থেকে exit address নিন। Control server auth সেট আপ করে থাকলে GET /v1/publicip/ip তালিকাভুক্ত করে এমন role-এর জন্য -H "X-API-Key: <key>" যোগ করুন। এরপর mobile data ব্যবহার করা একটি ফোন থেকে http://<address>:<port> খুলুন। Port-checker log-এ request দেখা গেলে প্রমাণ হয় যে inbound TCP পৌঁছেছে। Timeout হলে বোঝায় যে তা পৌঁছায়নি, client-এর নিজস্ব status icon যা-ই দেখাক না কেন।