توسط Matt Connor 2026-08-14

آموزش تنظیم Port Forwarding در Gluetun برای تورنت

Q: چرا تورنتهای من دانلود میشوند اما هیچ اتصال ورودی دریافت نمیکنند؟

بدون پورت فوروارد شده، ارائهدهنده VPN هیچ قانون NAT برای ارسال بستههای ورودی به تونل شما ندارد، بنابراین اتصالاتی که خودتان آغاز نکردهاید در آدرس خروجی مسدود میشوند. دانلودها همچنان کار میکنند زیرا کلاینت شما خودش آن اتصالات را باز میکند و میتواند به هر همتایی (peer) که قابل اتصال است دسترسی پیدا کند. سید کردن (seeding) و پیوستن به swarm دچار مشکل میشود، زیرا هر دو به این وابستهاند که دیگران بتوانند به شما متصل شوند. راهحل، استفاده از ارائهدهندهای است که port forwarding ارائه میدهد، تنظیم VPN_PORT_FORWARDING=on در gluetun و اعمال پورت حاصل روی پورت listening کلاینت است.

Q: آیا gluetun با port forwarding هر ارائهدهنده VPN کار میکند؟

خیر. نسخه gluetun v3.41.3 دارای یکپارچهسازی بومی برای چهار ارائهدهنده است: Private Internet Access، ProtonVPN، Perfect Privacy و PrivateVPN. هر چیزی خارج از این لیست در اعتبارسنجی VPN_PORT_FORWARDING_PROVIDER شکست میخورد و کانتینر در زمان راهاندازی متوقف میشود. اگر ارائهدهنده شما یک پورت ثابت از طریق پنل کنترل خود ارائه میدهد، gluetun نمیتواند آن را برای شما درخواست کند، اما FIREWALL_VPN_INPUT_PORTS اجازه میدهد آن پورت ثابت از فایروال gluetun عبور کند. سیاستهای ارائهدهندگان تغییر میکند، بنابراین پیش از خرید اشتراک، صفحه فعلی ارائهدهنده را بررسی کنید.

Q: آیا باید پورت را بعد از هر بار اتصال مجدد بهروزرسانی کنم؟

بله، و این بهروزرسانی باید خودکار باشد. پورت فوروارد شده متعلق به نشست (session) VPN است، بنابراین راهاندازی مجدد کانتینر، تغییر سرور یا شکست در تمدید اجاره (lease) میتواند منجر به ایجاد یک شماره جدید شود، در حالی که کلاینت پورت قبلی را در پیکربندی خود ذخیره کرده است. یا اجازه دهید gluetun آن را با VPN_PORT_FORWARDING_UP_COMMAND ارسال کند که بلافاصله پس از برقراری فورواردینگ اجرا میشود، یا یک پردازش کوچک اجرا کنید که GET /v1/portforward را از سرور کنترل بخواند و مقدار را از طریق API در کلاینت بنویسد.

اگر دانلودها انجام می‌شوند اما هیچ اتصالی دریافت نمی‌کنید، مشکل از نبود پورت باز است. با تنظیم Gluetun، پورت جدید را به کلاینت تورنت منتقل و اتصال را تست کنید.

چرا بدون پورت فوروارد شده، هیچ اتصالی برقرار نمی‌شود

قابلیت port forwarding در Gluetun از ارائه‌دهنده VPN شما می‌خواهد که یک پورت عمومی روی آدرس خروجی خود را به کانتینر شما نگاشت (map) کند؛ این تنها راهی است که یک همتا (peer) دیگر می‌تواند اتصالی را به کلاینت تورنت شما آغاز کند. بدون این نگاشت، تونل سالم است و دانلودها انجام می‌شوند، اما هیچ داده‌ای به صورت خودکار وارد نمی‌شود. هر اتصال فعالی، اتصالی است که کلاینت شما ابتدا آن را باز کرده است.

مکانیسم این فرآیند NAT (ترجمه آدرس شبکه) است. کانتینر شما آدرس خروجی ارائه‌دهنده را با بسیاری از مشتریان دیگر به اشتراک می‌گذارد. هنگامی که کلاینت شما اتصالی را به سمت بیرون باز می‌کند، ارائه‌دهنده آن جریان را ثبت کرده و پاسخ‌ها را به داخل تونل شما می‌فرستد. اتصال ورودی یک غریبه با هیچ جریان ثبت‌شده‌ای مطابقت ندارد، بنابراین بسته به آدرس خروجی می‌رسد و در همان‌جا دور ریخته می‌شود. کلاینت شما همچنان به هر همتایی که خودش قابلیت اتصال دارد دسترسی پیدا می‌کند، بنابراین دانلودها کامل می‌شوند و مشکل پنهان می‌ماند. مشکل در مرحله Seeding نمایان می‌شود، زیرا یک Seeder ماشینی است که دیگران به آن متصل می‌شوند.

یک پورت ورودی باز، دو چیز را تغییر می‌دهد. شما سریع‌تر به یک swarm ملحق می‌شوید، زیرا همتایانی که خودشان نمی‌توانند اتصال بپذیرند، اکنون می‌توانند به شما دسترسی پیدا کنند و شما می‌توانید برای آن همتایان آپلود انجام دهید.

چرا اکثر ارائه‌دهندگان VPN پورت فوروارد شده ارائه نمی‌دهند

پورت فوروارد شده یک منبع کمیاب روی یک آدرس IP اشتراکی است. ارائه‌دهنده، یک شماره پورت را روی یک IP خروجی برای یک مشتری رزرو می‌کند و سپس در قبال هر کاری که آن مشتری با پورت انجام می‌دهد، مسئول است. چندین ارائه‌دهنده بزرگ این قابلیت را حذف کرده‌اند و دلیل آن را مدیریت سوءاستفاده‌ها عنوان کرده‌اند. به پشتیبانی به عنوان یک پرسش دسته‌بندی نگاه کنید، نه یک گزینه ساده: بپرسید که آیا ارائه‌دهنده در حال حاضر، در طرح اشتراک شما و روی سرورهایی که واقعاً می‌توانید انتخاب کنید، قابلیت port forwarding ارائه می‌دهد یا خیر.

در مواردی که forwarding وجود دارد، پورت پویا (dynamic) است. این پورت متعلق به نشست VPN است و نه حساب کاربری شما، بنابراین ممکن است پس از هر بار اتصال مجدد، شماره آن تغییر کند. Private Internet Access یک پورت امضا شده صادر می‌کند که gluetun آن را به‌روزرسانی می‌کند. مستندات بالادستی می‌گوید تا زمانی که دایرکتوری /gluetun را bind mount کنید تا وضعیت (state) پس از راه‌اندازی مجدد باقی بماند، همان پورت را تا 60 روز حفظ خواهید کرد. ProtonVPN یک پورت تصادفی را از طریق NAT-PMP (پروتکل نگاشت پورت NAT) با اجاره‌نامه کوتاه اختصاص می‌دهد که باید به‌طور مداوم تمدید شود. به همین دلیل است که تنظیم پورت در کلاینت برای یک بار، هرگز به صورت دائمی کار نمی‌کند.

ارائه‌دهندگانی که gluetun می‌تواند از آن‌ها درخواست پورت کند

از نسخه gluetun v3.41.3 که در تاریخ 30 July 2026 منتشر شد، یکپارچه‌سازی بومی (native) بر اساس چهار نام ارائه‌دهنده اعتبارسنجی می‌شود: Private Internet Access، ProtonVPN، Perfect Privacy و PrivateVPN. این قابلیت را با VPN_PORT_FORWARDING=on فعال کنید که به‌صورت پیش‌فرض off است. راهنماهای قدیمی‌تر از PORT_FORWARDING یا PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING استفاده می‌کنند. هر دو نام در این نسخه همچنان به عنوان نام‌های سازگار با نسخه‌های پیشین کار می‌کنند، اما در حال منسوخ شدن هستند.

دو جزئیات مربوط به ارائه‌دهنده تعیین می‌کند که آیا درخواست اصلاً می‌تواند موفقیت‌آمیز باشد یا خیر. ProtonVPN به یک طرح اشتراک پولی نیاز دارد و NAT-PMP باید روشن باشد: هنگام تولید پیکربندی WireGuard، گزینه NAT-PMP (Port Forwarding) را در بخش تنظیمات VPN فعال کنید، یا هنگام استفاده از OpenVPN، عبارت +pmp را به نام کاربری خود اضافه کنید. Private Internet Access در OpenVPN دارای PORT_FORWARD_ONLY است که انتخاب سرور را به سرورهایی محدود می‌کند که از قابلیت forwarding پشتیبانی می‌کنند، تا به سروری که هرگز این قابلیت را نداشته است متصل نشوید. نحوه درخواست پورت در WireGuard و OpenVPN متفاوت است، بنابراین پیش از انتخاب، صفحه مربوط به ارائه‌دهنده خود را مطالعه کنید.

هنگامی که gluetun به جای استفاده از یک ارائه‌دهنده داخلی، از یک پیکربندی سفارشی استفاده می‌کند، VPN_PORT_FORWARDING_PROVIDER نام API که gluetun باید فراخوانی کند را مشخص می‌نماید. صفحه بالادستی Private Internet Access این متغیر را با VPN_PORT_FORWARDING_USERNAME و VPN_PORT_FORWARDING_PASSWORD جفت می‌کند که حامل اعتبارنامه‌های حساب کاربری مورد نیاز برای درخواست پورت هستند.

فعال‌سازی port forwarding در gluetun با استفاده از docker compose

این راهنما فرض می‌کند که تونل در حال حاضر کار می‌کند. اگر چنین نیست، ابتدا هدایت ترافیک کانتینر Docker از طریق gluetun را انجام دهید و پس از اطمینان از عملکرد دانلودها، به اینجا بازگردید.

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 پیروی می‌کند، جایی که ساختار داخلی port forwarding برای نسخه v4 در حال تغییر است؛ بنابراین یک ایمیج بدون نسخه ثابت ممکن است در docker compose pull بعدی رفتار متفاوتی داشته باشد. کلید خصوصی را با استفاده از یک فایل env برای اسرار compose خارج از فایل compose نگه دارید.

محل ذخیره پورت فوروارد شده توسط gluetun

برنامه gluetun پورت را در سه مکان مختلف ارائه می‌دهد که مقدار همگی آن‌ها یکسان است.

این برنامه پورت را در هر بار دریافت، در لاگ ثبت می‌کند. خط مربوطه به صورت port forwarded is 45678 است و در صورتی که درخواست نتیجه‌ای نداشته باشد، no port forwarded نمایش داده می‌شود.

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

این برنامه شماره پورت را در فایلی که توسط VPN_PORT_FORWARDING_STATUS_FILE تعیین شده می‌نویسد که مقدار پیش‌فرض آن /tmp/gluetun/forwarded_port است. این فایل در هر خط یک پورت را نگه می‌دارد، با مجوز 0644 نوشته می‌شود و مالکیت آن به PUID و PGID کانتینر تغییر می‌یابد. هنگامی که عملیات فوروارد متوقف می‌شود، gluetun به جای حذف فایل، محتوای آن را پاک می‌کند تا مصرف‌کننده به جای مواجهه با خطای فایل موجود نبودن، یک فایل خالی را بخواند.

docker exec gluetun cat /tmp/gluetun/forwarded_port

این برنامه مقدار پورت را از طریق سرور کنترلی ارائه می‌دهد که به‌طور پیش‌فرض روی :8000 گوش می‌دهد و توسط HTTP_CONTROL_SERVER_ADDRESS تنظیم می‌شود.

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

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

برنامه gluetun همچنین آن پورت را در فایروال داخلی خود روی رابط VPN باز می‌کند، بنابراین در زمانی که یکپارچه‌سازی بومی (native integration) در حال انجام کار است، نیازی به FIREWALL_VPN_INPUT_PORTS نیست. آن متغیر برای حالت دیگری کاربرد دارد: زمانی که gluetun نمی‌تواند از ارائه‌دهنده پرس‌وجو کند و شما یک پورت ثابت را خارج از سیستم دریافت کرده‌اید و باید آن را به‌صورت دستی مجاز کنید.

از این سه روش، یکی پایدار است و دو مورد دیگر نیستند. مستندات بالادستی، فایل وضعیت را در نسخه v4.0.0 منسوخ اعلام کرده‌اند و GET /v1/openvpn/portforwarded هم‌اکنون با 301 Moved Permanently پاسخ می‌دهد که به /v1/portforward اشاره دارد. در پیاده‌سازی‌های جدید، باید از سرور کنترلی استفاده کرد.

چرا کلاینت باید در هر اتصال مجدد از پورت مطلع شود

یک کلاینت تورنت، پورت شنود (listening port) خود را در پیکربندی داخلی‌اش ذخیره کرده و آن شماره را در طول راه‌اندازی‌های مجدد حفظ می‌کند. پورت فوروارد شده، ویژگیِ نشست VPN است. پس از اتصال مجدد، این دو شماره با هم مطابقت ندارند؛ در نتیجه، ارائه‌دهنده پورتی را نگاشت می‌کند که هیچ سرویسی روی آن گوش نمی‌دهد و کلاینت روی پورتی گوش می‌دهد که هیچ نگاشتی برای آن وجود ندارد. اتصال‌های مجدد نادر نیستند: راه‌اندازی مجدد کانتینر، تغییر سرور، قطع شدن تونل که توسط بررسی سلامت gluetun مجدداً برقرار می‌شود، یا اجاره‌ای (lease) که تمدید نشده است. نتیجه، تنظیماتی است که دیروز در دسترس بود اما امروز بدون هیچ خطایی در لاگ‌ها، به‌طور خاموش غیرقابل‌دسترس شده است.

بنابراین، پورت باید دقیقاً در لحظه‌ای که gluetun آن را دریافت می‌کند، اعمال شود. دو روش برای پیاده‌سازی این موضوع وجود دارد که تفاوت آن‌ها در فرآیندی است که این کار را انجام می‌دهد.

گزینه 1: gluetun پورت را با یک دستور up ارسال می‌کند

VPN_PORT_FORWARDING_UP_COMMAND زمانی اجرا می‌شود که port forwarding برقرار شود و VPN_PORT_FORWARDING_DOWN_COMMAND زمانی که قطع گردد. برنامه Gluetun پیش از اجرای دستور، {{PORT}} (اولین پورت)، {{PORTS}} (همه پورت‌ها با جداکننده کاما) و {{VPN_INTERFACE}} (نام رابط تونل، که به‌صورت پیش‌فرض tun0 است) را جایگذاری می‌کند. سینتکس Shell به یک wrapper صریح به صورت /bin/sh -c نیاز دارد. این نمونه بالادستی (upstream) برای qBittorrent است که به عنوان دو ورودی environment در compose نوشته شده است:

      - 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'

هر فیلد در این فراخوانی وظیفه‌ای دارد. listen_port پورت جدید است. current_network_interface برنامه qBittorrent را به تونل متصل (bind) می‌کند. تنظیم random_port روی false باعث می‌شود qBittorrent در شروع بعدی، پورت اختصاصی خود را انتخاب نکند. تنظیم upnp روی false مانع از تلاش آن برای نگاشت (map) پورت از طریق روتری می‌شود که وجود خارجی ندارد.

این رویکرد دو پیش‌نیاز دارد. رابط کاربری وب qBittorrent باید از داخل کانتینر gluetun به 127.0.0.1:8080 پاسخ دهد، که وقتی کانتینر کلاینت از network namespace کانتینر gluetun استفاده می‌کند، به‌صورت خودکار انجام می‌شود. همچنین Bypass authentication for clients on localhost (bypass_local_auth) باید فعال باشد، زیرا این دستور هیچ اعتبارنامه‌ای (credentials) ارسال نمی‌کند. دستور down به این دلیل قرار داده شده که qBittorrent همیشه پس از قطع اتصال، پورت را دوباره برقرار نمی‌کند.

این دستور در داخل کانتینر gluetun اجرا می‌شود که بر پایه Alpine ساخته شده و شامل wget است. در آن ایمیج هیچ curl وجود ندارد. دستوری که نام یک باینری موجود در ایمیج را نداشته باشد، هر بار که forwarding برقرار می‌شود، با شکست مواجه خواهد شد.

گزینه 2: یک پردازش خارج از gluetun پورت را می‌خواند

الگوی دیگر، اجرای یک پردازش کوچک در کنار gluetun است که پورت را دریافت کرده و از طریق API خودِ کلاینت، آن را به کلاینت تزریق می‌کند. آن را از سرور کنترل بخوانید:

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

یا اگر پردازش به فایل دسترسی دارد، آن را بخوانید. /tmp/gluetun/forwarded_port درون کانتینر gluetun قرار دارد، بنابراین یک sidecar نیاز به یک volume مشترک دارد که در /tmp/gluetun در هر دو کانتینر mount شده باشد، یا اینکه VPN_PORT_FORWARDING_STATUS_FILE را به مسیری زیر یک volume که از قبل mount کرده‌اید، اشاره دهید.

احراز هویت در اینجا اهمیت دارد. در نسخه v3.41.3، مسیر GET /v1/portforward متعلق به یک نقش پیش‌فرض به نام public با auth = "none" است، بنابراین بدون اعتبارنامه پاسخ می‌دهد و gluetun هشداری که با route GET /v1/portforward is unprotected by default, please set up authentication شروع می‌شود را لاگ می‌کند. توسعه‌دهندگان در نسخه‌های بعدی این دسترسی را محدود خواهند کرد. اکنون یک نقش در فایلی که در /gluetun/auth/config.toml bind mount شده است، تعریف کنید:

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

یک کلید با docker run --rm qmcgaw/gluetun:v3.41.3 genkey تولید کنید و آن را در هدر X-API-Key ارسال کنید. HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE همان کار یک متغیر محیطی با انکود JSON را انجام می‌دهد، زمانی که ترجیح می‌دهید فایلی را mount نکنید. پورت 8000 که بدون نقش منتشر شده باشد، به هر کسی که به آن دسترسی داشته باشد اجازه کنترل وضعیت VPN را می‌دهد؛ بنابراین هنگام بررسی نحوه دسترسی به gluetun از میزبان و سایر کانتینرها، آگاهانه تصمیم بگیرید که این دسترسی تا چه حد گسترده باشد.

زمانی که کلاینت یک API ارائه می‌دهد که با یک فراخوانی wget هدایت می‌شود، از دستور up استفاده کنید، زیرا دقیقاً یک بار در هر رویداد اجرا می‌شود و سربار اجرایی ندارد. زمانی که کلاینت نیاز به فرآیند ورود، بازنویسی فایل پیکربندی یا راه‌اندازی مجدد دارد، یک پردازش خارجی انتخاب کنید. در یک stack از نوع arr پشت یک کانتینر gluetun، این معمولاً به یک poller کوچک ختم می‌شود، زیرا فقط کلاینت تورنت به پورت اهمیت می‌دهد.

دام: اشتراک‌گذاری فضای نام (namespace) پورت شنود را تنظیم نمی‌کند

این خطا بیشترین زمان را هدر می‌دهد. network_mode: "service:gluetun" کلاینت را در فضای نام شبکه gluetun قرار می‌دهد، بنابراین کلاینت از آدرس VPN، مسیرهای تونل و قوانین فایروال gluetun استفاده می‌کند. هیچ‌کدام از این موارد پورت شنود (listening port) کلاینت را تنظیم نمی‌کنند. gluetun پورت فوروارد شده را روی رابط VPN باز می‌کند و بسته‌های مربوط به آن وارد فضای نام می‌شوند؛ اگر کلاینت روی پورت متفاوتی گوش دهد، هسته سیستم‌عامل مقصدی برای تحویل بسته‌ها ندارد. در نتیجه اتصال رد شده یا با timeout مواجه می‌شود، در حالی که تمام بررسی‌های خروجی سالم به نظر می‌رسند. پورت فوروارد شده و پورت شنود کلاینت دو عدد مجزا هستند و وظیفه اصلی شما یکسان نگه‌داشتن آن‌هاست.

به‌جای حدس زدن، آن‌ها را با هم مقایسه کنید. هر دو دستور زیر در فضای نام یکسانی اجرا می‌شوند:

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]*'

یک تنظیم دیگر نیز کاربران را به مسیر اشتباه می‌برد. VPN_PORT_FORWARDING_LISTENING_PORT ترافیک ورودی از پورت فوروارد شده را با استفاده از iptables به یک پورت محلی ثابت هدایت می‌کند. ارائه‌دهنده سرویس به شما توصیه می‌کند از این قابلیت با کلاینت‌های تورنت استفاده نکنید، زیرا کلاینت پورت شنود خود را به ترکرها و همتایان (peers) اعلام می‌کند و در نتیجه، شبکه (swarm) عدد اشتباهی را دریافت می‌کند.

نحوه اثبات در دسترس بودن پورت فوروارد شده

نشانگر اتصال در کلاینت، اتصالات خروجی به ترکر را منعکس می‌کند؛ بنابراین ممکن است سبز به نظر برسد در حالی که هیچ‌کس نمی‌تواند به شما متصل شود. با استفاده از یک listener که تحت کنترل شماست و از شبکه‌ای خارج از تونل، تست را انجام دهید. ارائه‌دهنده بالادستی ابزار کوچکی برای این کار منتشر کرده است. ابتدا کلاینت تورنت را متوقف کنید، زیرا دو پردازش نمی‌توانند همزمان به یک پورت متصل (bind) شوند.

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

در داخل کانتینر، amd64 را برای معماری CPU خود و 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 از آن استفاده می‌کند را پیدا کنید. پاسخ به صورت JSON است و آدرس در فیلد public_ip قرار دارد.

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

از دستگاهی که در همان VPN نیست، http://<that address>:4567 را باز کنید. استفاده از گوشی با اینترنت موبایل مناسب است. اگر صفحه‌ای که آدرس IP و user agent مرورگر شما را نشان می‌دهد، در لاگ‌های port-checker ثبت شود، به این معنی است که ترافیک ورودی TCP به namespace می‌رسد. بروز خطای timeout به این معنی است که ترافیک نمی‌رسد و علت آن در لایه‌ای بالاتر از کلاینت قرار دارد. ابزار را با CTRL+C متوقف کنید، با exit از shell خارج شوید و کلاینت را دوباره اجرا کنید. این تست فقط پروتکل TCP را بررسی می‌کند. ترافیک DHT (جدول هش توزیع‌شده) و uTP از پروتکل UDP روی همان شماره پورت استفاده می‌کنند که این تست آن را پوشش نمی‌دهد.

حالت‌های شکست و پیام‌هایی که مشاهده خواهید کرد

هیچ خطی مربوط به پورت در لاگ وجود ندارد. هیچ درخواستی برای پورت ارسال نشده است. تأیید کنید که متغیر واقعاً به کانتینر رسیده است یا خیر؛ برای این کار از docker exec gluetun printenv | grep PORT_FORWARDING استفاده کنید، زیرا تنظیم متغیر در سرویس اشتباه در فایل compose، یک علت رایج است.

سرویس Gluetun اجرا نمی‌شود و از ارائه‌دهنده (provider) شکایت دارد. مقدار VPN_PORT_FORWARDING_PROVIDER با چهار نام پشتیبانی‌شده اعتبارسنجی می‌شود، بنابراین یک غلط تایپی باعث توقف کانتینر می‌شود تا اینکه بدون فوروارد کردن پورت، بی‌سروصدا به کار خود ادامه دهد.

لاگ پیام no port forwarded را نشان می‌دهد. Gluetun درخواست داده اما ارائه‌دهنده پاسخی نداده است. در ProtonVPN، این معمولاً به این معنی است که NAT-PMP در پیکربندی تولیدشده فعال نشده است یا طرح اشتراک شما شامل قابلیت port forwarding نیست. در Private Internet Access، معمولاً به این معنی است که سرور انتخاب‌شده این قابلیت را ارائه نمی‌دهد.

پورت دریافت می‌شود، اما هیچ اتصالی برقرار نمی‌شود. پورت فوروارد شده را با پورت listening کلاینت با استفاده از دو دستور بالا مقایسه کنید. اگر مطابقت دارند، بررسی کنید که کلاینت به رابط tunnel متصل شده باشد و گزینه random-port آن غیرفعال باشد، زیرا این گزینه پورت listening را در هر بار راه‌اندازی بازنویسی می‌کند.

دستور up به نظر می‌رسد هیچ کاری انجام نمی‌دهد. دستور دقیق را داخل کانتینر اجرا کنید تا خطا را ببینید: docker exec gluetun /bin/sh -c '<your command>'. نتیجه معمول curl: not found است، زیرا ایمیج فقط شامل wget است.

خطای 401 Unauthorized از سمت سرور کنترل. شما یک پیکربندی احراز هویت تعریف کرده‌اید و نقش (role) تعریف‌شده، مسیری که فراخوانی می‌کنید را شامل نمی‌شود. مسیرها بر اساس متد و مسیر (path) تطبیق داده می‌شوند، بنابراین نقشی که فقط /v1/portforward را لیست کرده است، GET /v1/portforward را پوشش نمی‌دهد.

تغییر پورت در Private Internet Access پس از هر بار راه‌اندازی مجدد. مسیر /gluetun را به صورت bind mount متصل کنید تا وضعیت پورت ذخیره‌شده پس از راه‌اندازی مجدد باقی بماند. بدون این volume، سرویس gluetun هر بار یک پورت جدید درخواست می‌کند.

FAQ

چرا تورنت‌های من دانلود می‌شوند اما هیچ اتصال ورودی دریافت نمی‌کنند؟

بدون پورت فوروارد شده، ارائه‌دهنده VPN هیچ قانون NAT برای ارسال بسته‌های ورودی به تونل شما ندارد، بنابراین اتصالاتی که خودتان آغاز نکرده‌اید در آدرس خروجی مسدود می‌شوند. دانلودها همچنان کار می‌کنند زیرا کلاینت شما خودش آن اتصالات را باز می‌کند و می‌تواند به هر همتایی (peer) که قابل اتصال است دسترسی پیدا کند. سید کردن (seeding) و پیوستن به swarm دچار مشکل می‌شود، زیرا هر دو به این وابسته‌اند که دیگران بتوانند به شما متصل شوند. راه‌حل، استفاده از ارائه‌دهنده‌ای است که port forwarding ارائه می‌دهد، تنظیم VPN_PORT_FORWARDING=on در gluetun و اعمال پورت حاصل روی پورت listening کلاینت است.

آیا gluetun با port forwarding هر ارائه‌دهنده VPN کار می‌کند؟

خیر. نسخه gluetun v3.41.3 دارای یکپارچه‌سازی بومی برای چهار ارائه‌دهنده است: Private Internet Access، ProtonVPN، Perfect Privacy و PrivateVPN. هر چیزی خارج از این لیست در اعتبارسنجی VPN_PORT_FORWARDING_PROVIDER شکست می‌خورد و کانتینر در زمان راه‌اندازی متوقف می‌شود. اگر ارائه‌دهنده شما یک پورت ثابت از طریق پنل کنترل خود ارائه می‌دهد، gluetun نمی‌تواند آن را برای شما درخواست کند، اما FIREWALL_VPN_INPUT_PORTS اجازه می‌دهد آن پورت ثابت از فایروال gluetun عبور کند. سیاست‌های ارائه‌دهندگان تغییر می‌کند، بنابراین پیش از خرید اشتراک، صفحه فعلی ارائه‌دهنده را بررسی کنید.

آیا باید پورت را بعد از هر بار اتصال مجدد به‌روزرسانی کنم؟

بله، و این به‌روزرسانی باید خودکار باشد. پورت فوروارد شده متعلق به نشست (session) VPN است، بنابراین راه‌اندازی مجدد کانتینر، تغییر سرور یا شکست در تمدید اجاره (lease) می‌تواند منجر به ایجاد یک شماره جدید شود، در حالی که کلاینت پورت قبلی را در پیکربندی خود ذخیره کرده است. یا اجازه دهید gluetun آن را با VPN_PORT_FORWARDING_UP_COMMAND ارسال کند که بلافاصله پس از برقراری فورواردینگ اجرا می‌شود، یا یک پردازش کوچک اجرا کنید که GET /v1/portforward را از سرور کنترل بخواند و مقدار را از طریق API در کلاینت بنویسد.

چگونه بررسی کنم که پورت فوروارد شده واقعاً باز است؟

یک listener روی همان پورت دقیق در داخل فضای نام شبکه (network namespace) gluetun اجرا کنید و از خارج VPN به آن متصل شوید. ابتدا کلاینت تورنت را متوقف کنید تا پورت آزاد شود، سپس باینری port-checker بالادستی را در داخل کانتینر gluetun با --listening-address=":<port>" اجرا کنید. آدرس خروجی را از curl -s http://127.0.0.1:8000/v1/publicip/ip بگیرید و http://<address>:<port> را از طریق اینترنت موبایل گوشی خود باز کنید. ظاهر شدن یک درخواست در لاگ port-checker ثابت می‌کند که TCP ورودی دریافت می‌شود. تایم‌اوت به این معنی است که اتصال برقرار نمی‌شود، فارغ از اینکه آیکون وضعیت کلاینت چه چیزی را نشان می‌دهد.

#gluetun #vpn#port-forwarding#docker#torrenting