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 পাঠায়

VPN_PORT_FORWARDING_UP_COMMAND port forwarding চালু হলে চলে, আর VPN_PORT_FORWARDING_DOWN_COMMAND port forwarding বন্ধ হলে চলে। 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 করার চেষ্টা বন্ধ হয়।

এই পদ্ধতিতে দুটি শর্ত আছে। 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 কোনো credential পাঠায় না। disconnect-এর পরে qBittorrent সব সময় port পুনঃস্থাপন করে না বলে down command-টি রাখা হয়েছে।

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

Option 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 ফাইলটি দেখতে পারলে সেটি পড়ুন। /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 ছাড়াই উত্তর দেয়। gluetun route GET /v1/portforward is unprotected by default, please set up authentication দিয়ে শুরু হওয়া একটি warning log করে। পরবর্তী release-এ upstream এই পথ বন্ধ করছে। এখনই /gluetun/auth/config.toml-এ bind mounted ফাইলে একটি role সংজ্ঞায়িত করুন:

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 ছাড়া প্রকাশিত Port 8000-এ পৌঁছাতে পারে এমন যে কেউ VPN state নিয়ন্ত্রণ করতে পারবে। তাই host এবং অন্যান্য container থেকে gluetun-এ কীভাবে পৌঁছাবেন নির্ধারণ করার সময় এটি কত দূর পর্যন্ত পৌঁছাবে, তা ইচ্ছাকৃতভাবে ঠিক করুন।

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-এ পৌঁছানো যাচ্ছে কীভাবে প্রমাণ করবেন

Client-এর নিজস্ব 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 এবং address-টি public_ip field-এ রয়েছে।

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

একই VPN-এ না থাকা কোনো device থেকে http://<that address>:4567 খুলুন। Mobile data ব্যবহার করা phone এ জন্য উপযুক্ত। যদি এমন একটি page দেখা যায় যেখানে আপনার browser-এর IP address ও user agent রয়েছে এবং port-checker-এ matching request log হয়, তাহলে inbound TCP namespace-এ পৌঁছেছে। Timeout হলে inbound connection পৌঁছায়নি। কারণটি 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 চারটি সমর্থিত নামের বিপরীতে validation করা হয়। তাই বানানভুল হলে container নীরবে forwarding ছাড়া চলার পরিবর্তে বন্ধ হয়ে যায়।

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

একটি port পাওয়া যাচ্ছে, কিন্তু কোনো connection আসছে না। উপরের দুটি command ব্যবহার করে forwarded port এবং client-এর listening port তুলনা করুন। দুটো মিলে গেলে দেখুন client-টি tunnel interface-এ bind করা আছে কি না এবং 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 সংজ্ঞায়িত করেছেন, কিন্তু role-এ আপনি যে route call করছেন সেটি তালিকাভুক্ত নেই। Route-গুলো method এবং path—এই জোড়া হিসেবে মেলানো হয়। তাই কোনো role-এ শুধু /v1/portforward থাকলে তা GET /v1/portforward-কে অন্তর্ভুক্ত করে না।

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

FAQ

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

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

প্রতিবার reconnect-এর পরে কি port update করতে হবে?

হ্যাঁ। এই update স্বয়ংক্রিয় হওয়া উচিত। forwarded port VPN session-এর সঙ্গে যুক্ত থাকে। তাই container restart, server পরিবর্তন বা lease renewal ব্যর্থ হলে নতুন port number পাওয়া যেতে পারে, কিন্তু client তার নিজস্ব configuration-এ আগের port সংরক্ষণ করে রাখতে পারে। forwarding চালু হওয়ার সঙ্গে সঙ্গে VPN_PORT_FORWARDING_UP_COMMAND ব্যবহার করে gluetun-কে port পাঠাতে দিন। অথবা এমন একটি ছোট 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 নিন এবং mobile data ব্যবহার করা একটি phone থেকে http://<address>:<port> খুলুন। port-checker log-এ request দেখা গেলে inbound TCP পৌঁছেছে বলে নিশ্চিত হওয়া যায়। timeout হলে inbound connection পৌঁছায়নি, client-এর নিজস্ব status icon যা-ই দেখাক।