Gluetun में Port Forwarding कैसे सेटअप करें

पोर्ट फॉरवर्डिंग के बिना कनेक्शन क्यों नहीं बनते

Gluetun port forwarding आपके VPN प्रदाता से उसके exit address पर मौजूद एक public port को आपके container से map करने के लिए कहता है। यही एकमात्र तरीका है जिससे कोई अन्य peer आपके torrent client के साथ कनेक्शन शुरू कर सकता है। इस मैपिंग के बिना tunnel तो ठीक काम करती है और downloads भी चलते हैं, लेकिन बाहर से कोई भी कनेक्शन अपने आप नहीं आता। हर सफल कनेक्शन वही होता है जिसे आपके client ने पहले शुरू किया हो।

यह प्रक्रिया NAT (network address translation) है। आपका container प्रदाता के exit address को कई अन्य ग्राहकों के साथ साझा करता है। जब आपका client बाहर की ओर कनेक्शन खोलता है, तो प्रदाता उस flow को record कर लेता है और जवाबों को आपकी tunnel के जरिए वापस भेज देता है। किसी अनजान peer का अंदर की ओर कनेक्शन किसी भी record किए गए flow से मेल नहीं खाता, इसलिए packet exit address तक पहुँचकर वहीं drop हो जाता है। आपका client अभी भी उन सभी peers तक पहुँच सकता है जो खुद connectable हैं, इसलिए downloads पूरे हो जाते हैं और समस्या दिखाई नहीं देती। Seeding के दौरान यह समस्या सामने आती है, क्योंकि seeder एक ऐसी मशीन है जिससे दूसरे लोग जुड़ते हैं।

एक open inbound port दो चीजें बदलता है। आप swarm में तेजी से शामिल होते हैं, क्योंकि जो peers खुद कनेक्शन स्वीकार नहीं कर सकते, वे अब आप तक पहुँच सकते हैं, और आप उन peers को upload भी कर पाते हैं।

अधिकांश VPN प्रदाता पोर्ट फॉरवर्डिंग की सुविधा क्यों नहीं देते हैं

पोर्ट फॉरवर्डिंग एक साझा IP पते पर एक दुर्लभ संसाधन है। प्रदाता एक ग्राहक के लिए एक एग्जिट IP पर एक पोर्ट नंबर आरक्षित करता है, और फिर उस पोर्ट के माध्यम से ग्राहक द्वारा की गई किसी भी गतिविधि के लिए जवाबदेह होता है। कई बड़े प्रदाताओं ने इस सुविधा को हटा दिया है और इसका कारण दुरुपयोग (abuse) को नियंत्रित करने में आने वाली कठिनाई को बताया है। सपोर्ट को केवल एक चेकबॉक्स के रूप में न देखें, बल्कि इसे एक श्रेणी के प्रश्न के रूप में लें: प्रदाता से पूछें कि क्या वे आज, आपके प्लान पर, और उन सर्वरों पर पोर्ट फॉरवर्डिंग की सुविधा देते हैं जिन्हें आप वास्तव में चुन सकते हैं।

जहाँ फॉरवर्डिंग मौजूद है, वहाँ पोर्ट डायनामिक होता है। यह आपके अकाउंट के बजाय VPN सत्र से संबंधित होता है, इसलिए हर बार फिर से कनेक्ट करने पर यह एक अलग नंबर हो सकता है। Private Internet Access एक साइन्ड पोर्ट जारी करता है जिसे gluetun रिफ्रेश करता है, और अपस्ट्रीम डॉक्यूमेंटेशन के अनुसार आप 60 दिनों तक उसी पोर्ट को बनाए रख सकते हैं, बशर्ते आप /gluetun डायरेक्टरी को बाइंड माउंट करें ताकि रीस्टार्ट होने पर भी स्टेट सुरक्षित रहे। ProtonVPN NAT-PMP (NAT पोर्ट मैपिंग प्रोटोकॉल) के माध्यम से एक छोटी अवधि के लिए रैंडम पोर्ट असाइन करता है जिसे लगातार रिन्यू करना पड़ता है। यही कारण है कि क्लाइंट में एक बार पोर्ट सेट करने से वह हमेशा काम नहीं करता है।

वे प्रदाता जिनसे gluetun पोर्ट मांग सकता है

gluetun v3.41.3 (जो 30 July 2026 को जारी हुआ) के अनुसार, नेटिव इंटीग्रेशन चार प्रदाता नामों को मान्य करता है: Private Internet Access, ProtonVPN, Perfect Privacy और PrivateVPN। इसे VPN_PORT_FORWARDING=on के साथ सक्षम करें, जो डिफ़ॉल्ट रूप से off होता है। पुराने गाइड PORT_FORWARDING या PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING का उपयोग करते हैं। इस संस्करण में दोनों अभी भी रेट्रो-कम्पैटिबल नामों के रूप में काम करते हैं, और दोनों को भविष्य में हटा दिया जाएगा।

दो प्रदाता विवरण यह तय करते हैं कि क्या अनुरोध सफल हो सकता है। ProtonVPN के लिए एक पेड प्लान की आवश्यकता होती है, और NAT-PMP को चालू होना चाहिए: WireGuard कॉन्फ़िगरेशन जनरेट करते समय VPN विकल्पों के अंतर्गत NAT-PMP (Port Forwarding) को सक्षम करें, या OpenVPN का उपयोग करते समय अपने यूजरनेम में +pmp जोड़ें। OpenVPN पर Private Internet Access में PORT_FORWARD_ONLY होता है, जो सर्वर चयन को केवल उन सर्वरों तक सीमित करता है जो फॉरवर्डिंग का समर्थन करते हैं, ताकि आप ऐसे सर्वर पर न पहुँचें जहाँ यह सुविधा उपलब्ध ही नहीं है। WireGuard और OpenVPN पोर्ट अनुरोध करने के तरीके में भिन्न हैं, इसलिए चुनने से पहले अपने प्रदाता का पेज पढ़ें।

जब gluetun इन-बिल्ट प्रदाता के बजाय कस्टम कॉन्फ़िगरेशन चलाता है, तो VPN_PORT_FORWARDING_PROVIDER उस API का नाम बताता है जिसे gluetun को कॉल करना चाहिए। अपस्ट्रीम Private Internet Access पेज उस वेरिएबल को VPN_PORT_FORWARDING_USERNAME और VPN_PORT_FORWARDING_PASSWORD के साथ जोड़ता है, जिनमें वे अकाउंट क्रेडेंशियल्स होते हैं जिनकी पोर्ट अनुरोध के लिए आवश्यकता होती है।

Docker compose में gluetun port forwarding को सक्षम करना

यह मानकर चला गया है कि tunnel पहले से काम कर रही है। यदि ऐसा नहीं है, तो Docker container traffic को gluetun के माध्यम से रूट करने से शुरुआत करें और 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 पर व्यवहार बदल सकती है। compose secrets के लिए एक env file का उपयोग करके private key को compose file से बाहर रखें।

Gluetun forwarded port को कहाँ लिखता है

Gluetun पोर्ट को तीन स्थानों पर expose करता है, और उन सभी में एक ही मान होता है।

यह प्रति अधिग्रहण (acquisition) एक बार पोर्ट को लॉग करता है। लाइन 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 पर chown किया जाता है। जब फ़ॉरवर्डिंग रुकती है, तो gluetun फ़ाइल को हटाने के बजाय उसे खाली कर देता है, ताकि कोई consumer गायब फ़ाइल के बजाय एक खाली फ़ाइल पढ़ सके।

docker exec gluetun cat /tmp/gluetun/forwarded_port

यह मान को control server पर सर्व करता है, जो डिफ़ॉल्ट रूप से :8000 पर listen करता है और इसे HTTP_CONTROL_SERVER_ADDRESS द्वारा सेट किया जाता है।

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

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

Gluetun उस पोर्ट को VPN इंटरफ़ेस पर अपने स्वयं के फ़ायरवॉल में भी खोलता है, इसलिए FIREWALL_VPN_INPUT_PORTS की आवश्यकता नहीं होती है जब native integration काम कर रहा हो। वह वेरिएबल दूसरे मामले को कवर करता है: एक ऐसा प्रदाता जिसे gluetun query नहीं कर सकता, जहाँ आपको out-of-band एक static पोर्ट जारी किया गया था और आपको इसे मैन्युअल रूप से allow करना होगा।

इन तीनों में से एक durable है और दो नहीं हैं। अपस्ट्रीम दस्तावेज़ीकरण status फ़ाइल को v4.0.0 में deprecated चिह्नित करता है, और GET /v1/openvpn/portforwarded पहले से ही 301 Moved Permanently के साथ उत्तर देता है जो /v1/portforward की ओर इशारा करता है। नए काम के लिए control server को पढ़ना चाहिए।

हर बार reconnect करने पर client को port के बारे में बताना क्यों आवश्यक है

एक torrent client अपने listening port को अपनी configuration में store करता है और restart के बाद भी उस नंबर को बनाए रखता है। Forwarded port, VPN session की एक विशेषता होती है। Reconnect के बाद दोनों नंबर मेल नहीं खाते, इसलिए provider एक ऐसे port को map करता है जिस पर कोई service listen नहीं कर रही होती, और client एक ऐसे port पर listen करता है जिसे कहीं भी map नहीं किया गया होता। Reconnect अक्सर होते रहते हैं: जैसे container का restart होना, server बदलना, tunnel का drop होना जिसे gluetun का health check restart करता है, या फिर lease का renew न हो पाना। इसका परिणाम यह होता है कि जो setup कल reachable था, वह आज चुपचाप unreachable हो जाता है, और दोनों में से किसी भी log में कोई error नहीं दिखता।

इसलिए, जिस क्षण gluetun port प्राप्त करता है, उसे apply करना आवश्यक है। इसे लागू करने के दो तरीके हैं, और वे इस बात में भिन्न हैं कि कौन सी process यह कार्य करती है।

विकल्प 1: gluetun एक up कमांड के साथ पोर्ट को पुश करता है

VPN_PORT_FORWARDING_UP_COMMAND तब चलता है जब पोर्ट फॉरवर्डिंग शुरू होती है, और VPN_PORT_FORWARDING_DOWN_COMMAND तब चलता है जब यह बंद हो जाती है। कमांड चलाने से पहले Gluetun {{PORT}} (पहला पोर्ट), {{PORTS}} (सभी पोर्ट, अल्पविराम से अलग किए गए) और {{VPN_INTERFACE}} (टनल इंटरफ़ेस का नाम, डिफ़ॉल्ट रूप से tun0) को प्रतिस्थापित करता है। शेल सिंटैक्स के लिए एक स्पष्ट /bin/sh -c रैपर की आवश्यकता होती है। यह अपस्ट्रीम qBittorrent का उदाहरण है, जिसे दो 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 को टनल से बाइंड करता है। random_port को false पर सेट करने से qBittorrent अगली बार स्टार्ट होने पर अपना पोर्ट खुद चुनने से रुक जाता है। upnp को false पर सेट करने से यह ऐसे राउटर के माध्यम से पोर्ट मैप करने की कोशिश करना बंद कर देता है जो वहां मौजूद ही नहीं है।

इस दृष्टिकोण के साथ दो आवश्यकताएं जुड़ी हैं। qBittorrent का वेब UI gluetun कंटेनर के अंदर से 127.0.0.1:8080 पर जवाब देना चाहिए, जो तब स्वचालित होता है जब क्लाइंट gluetun के नेटवर्क नेमस्पेस को साझा करता है। और Bypass authentication for clients on localhost (bypass_local_auth) सक्षम होना चाहिए, क्योंकि कमांड कोई क्रेडेंशियल नहीं भेजता है। डाउन कमांड इसलिए है क्योंकि qBittorrent डिस्कनेक्ट होने के बाद हमेशा पोर्ट को फिर से स्थापित नहीं करता है।

कमांड gluetun कंटेनर के अंदर चलता है, जो Alpine पर बना है और wget के साथ आता है। उस इमेज में कोई curl नहीं है। जो कमांड किसी ऐसी बाइनरी का नाम लेता है जो इमेज में नहीं है, वह हर बार फॉरवर्डिंग शुरू होने पर विफल हो जाता है।

विकल्प 2: gluetun के बाहर एक प्रक्रिया पोर्ट को पढ़ती है

दूसरा पैटर्न gluetun के साथ एक छोटी प्रक्रिया चलाता है जो पोर्ट को प्राप्त करती है और उसे client के अपने API के माध्यम से client में भेजती है। इसे control server से पढ़ें:

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

या यदि प्रक्रिया इसे देख सकती है, तो फ़ाइल को पढ़ें। /tmp/gluetun/forwarded_port, gluetun container के अंदर रहता है, इसलिए एक sidecar को दोनों containers में /tmp/gluetun पर एक shared volume mount करने की आवश्यकता होती है, या आप VPN_PORT_FORWARDING_STATUS_FILE को उस volume के अंतर्गत किसी path पर point करते हैं जिसे आप पहले से mount कर चुके हैं।

यहाँ Authentication मायने रखती है। v3.41.3 में route GET /v1/portforward, auth = "none" के साथ public नामक एक default role से संबंधित है, इसलिए यह बिना credentials के उत्तर देता है, और gluetun, route GET /v1/portforward is unprotected by default, please set up authentication से शुरू होने वाली एक चेतावनी log करता है। Upstream इसे बाद के release में बंद कर रहा है। अभी एक role परिभाषित करें, उस फ़ाइल में जिसे /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 के साथ एक key generate करें और इसे X-API-Key header में भेजें। जब आप फ़ाइल mount नहीं करना चाहते हैं, तो HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE वही काम करता है जो एक JSON-encoded environment variable करता है। बिना role के publish किया गया port 8000 इसे access कर सकने वाले किसी भी व्यक्ति को VPN state पर नियंत्रण देता है, इसलिए जब आप gluetun तक host और अन्य containers से पहुँचने का तरीका तय करें, तो सोच-समझकर निर्णय लें कि यह कहाँ तक पहुँचता है।

जब client एक ऐसा API expose करता है जिसे एक wget call चला सकती है, तो up command चुनें, क्योंकि यह प्रति event ठीक एक बार चलती है और चलते रहने के लिए कुछ भी अतिरिक्त नहीं जोड़ती। जब client को login flow, config फ़ाइल को फिर से लिखने, या restart की आवश्यकता हो, तो एक external process चुनें। एक gluetun container के पीछे arr stack में यह आमतौर पर एक छोटे poller के रूप में समाप्त होता है, क्योंकि केवल torrent client को ही पोर्ट की परवाह होती है।

जाल: namespace साझा करने से listening port सेट नहीं होता है

यह विफलता सबसे अधिक समय बर्बाद करती है। network_mode: "service:gluetun" क्लाइंट को gluetun के network namespace में डाल देता है, जिससे उसे VPN एड्रेस, टनल रूट्स और gluetun के firewall रूल्स मिल जाते हैं। इनमें से कोई भी क्लाइंट का listening port सेट नहीं करता है। Gluetun VPN इंटरफ़ेस पर फॉरवर्ड किए गए पोर्ट को खोलता है, पैकेट namespace में पहुँच जाते हैं, लेकिन यदि क्लाइंट किसी अलग पोर्ट पर listen कर रहा है, तो kernel के पास उन्हें भेजने के लिए कोई गंतव्य नहीं होता है। कनेक्शन रिफ्यूज हो जाता है या टाइम आउट हो जाता है, जबकि हर आउटबाउंड चेक सही दिखता है। फॉरवर्ड किया गया पोर्ट और क्लाइंट का listening port दो अलग-अलग नंबर हैं, और उन्हें समान रखना ही मुख्य कार्य है।

अनुमान लगाने के बजाय उनकी तुलना करें। दोनों कमांड एक ही 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]*'

एक और सेटिंग लोगों को गलत दिशा में ले जाती है। VPN_PORT_FORWARDING_LISTENING_PORT iptables का उपयोग करके इनबाउंड ट्रैफ़िक को फॉरवर्ड किए गए पोर्ट से एक फिक्स्ड लोकल पोर्ट पर रीडायरेक्ट करता है। अपस्ट्रीम आपको इसे torrent क्लाइंट्स के साथ उपयोग न करने की सलाह देता है, क्योंकि क्लाइंट ट्रैकर्स और पीयर्स को अपना खुद का listening port बताता है, जिससे स्वार्म को गलत नंबर पता चल जाता है।

Forwarded port तक पहुँचा जा सकता है, यह कैसे सिद्ध करें

Client का अपना connection indicator केवल outbound tracker connections को दर्शाता है, इसलिए यह हरा दिख सकता है जबकि बाहर से कोई भी आप तक नहीं पहुँच पा रहा हो। tunnel के बाहर के किसी network से, अपने नियंत्रण वाले listener के साथ परीक्षण करें। Upstream इसके लिए एक छोटा tool प्रदान करता है। सबसे पहले torrent client को बंद करें, क्योंकि दो processes एक ही 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"

अब वह exit address ढूँढें जिसका उपयोग gluetun कर रहा है। प्रतिक्रिया JSON में है और address public_ip field में है।

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

किसी ऐसे device से http://<that address>:4567 खोलें जो उसी VPN पर न हो। mobile data पर चल रहा phone इसके लिए उपयुक्त है। यदि कोई page आपके browser का IP address और user agent दिखाता है, और port-checker द्वारा एक matching request log की जाती है, तो इसका अर्थ है कि inbound TCP namespace तक पहुँच रहा है। Timeout का अर्थ है कि यह नहीं पहुँच रहा है, और समस्या client के ऊपर (network layer पर) है। Tool को CTRL+C के साथ रोकें, exit के साथ shell से बाहर निकलें, और client को फिर से start करें। यह जाँच केवल TCP का परीक्षण करती है। DHT (distributed hash table) और uTP traffic उसी port number पर UDP का उपयोग करते हैं, जिसे यह परीक्षण कवर नहीं करता है।

विफलता के प्रकार और वे स्ट्रिंग्स जो आपको दिखाई देंगी

लॉग में पोर्ट लाइन का बिल्कुल न होना। किसी भी चीज़ ने पोर्ट के लिए अनुरोध नहीं किया। पुष्टि करें कि वेरिएबल वास्तव में docker exec gluetun printenv | grep PORT_FORWARDING के साथ कंटेनर तक पहुँच गया है, क्योंकि गलत compose सर्विस में सेट किया गया वेरिएबल एक सामान्य कारण है।

Gluetun शुरू होने से मना कर देता है और प्रदाता के बारे में शिकायत करता है। VPN_PORT_FORWARDING_PROVIDER को चार समर्थित नामों के विरुद्ध मान्य किया जाता है, इसलिए कोई भी टाइपो कंटेनर को रोक देता है, बजाय इसके कि वह बिना फॉरवर्डिंग के चुपचाप चलता रहे।

लॉग में no port forwarded लिखा है। Gluetun ने अनुरोध किया और प्रदाता ने कोई उत्तर नहीं दिया। ProtonVPN पर इसका आमतौर पर मतलब है कि आपके द्वारा जनरेट किए गए कॉन्फ़िगरेशन पर NAT-PMP सक्षम नहीं था, या आपके प्लान में फॉरवर्डिंग शामिल नहीं है। Private Internet Access पर इसका आमतौर पर मतलब है कि चयनित सर्वर इसे प्रदान नहीं करता है।

पोर्ट प्राप्त होता है, लेकिन कुछ भी कनेक्ट नहीं हो पाता। ऊपर दिए गए दो कमांड का उपयोग करके फॉरवर्ड किए गए पोर्ट की तुलना क्लाइंट के लिसनिंग पोर्ट से करें। यदि वे मेल खाते हैं, तो जांचें कि क्लाइंट टनल इंटरफ़ेस से बाउंड है और उसका रैंडम-पोर्ट विकल्प बंद है, क्योंकि वह विकल्प हर बार शुरू होने पर लिसनिंग पोर्ट को बदल देता है।

up कमांड कुछ भी करती हुई नहीं दिखती। त्रुटि देखने के लिए कंटेनर के अंदर सटीक कमांड चलाएँ: docker exec gluetun /bin/sh -c '<your command>'। curl: not found इसका सामान्य परिणाम है, क्योंकि इमेज में केवल wget ही शिप होता है।

कंट्रोल सर्वर से 401 Unauthorized। आपने एक ऑथ कॉन्फ़िगरेशन परिभाषित किया है और रोल उस रूट को सूचीबद्ध नहीं करता है जिसे आप कॉल कर रहे हैं। रूट्स का मिलान मेथड और पाथ के योग के रूप में किया जाता है, इसलिए केवल /v1/portforward को सूचीबद्ध करने वाला रोल GET /v1/portforward को कवर नहीं करता है।

हर रीस्टार्ट के बाद Private Internet Access पर एक अलग पोर्ट। /gluetun को बाइंड माउंट करें ताकि सहेजी गई पोर्ट स्थिति रीस्टार्ट के बाद भी बनी रहे। उस वॉल्यूम के बिना, gluetun हर बार एक नए पोर्ट का अनुरोध करता है।

FAQ

मेरे torrents download तो हो जाते हैं, लेकिन incoming connections क्यों नहीं मिलते?

बिना forwarded port के, VPN provider के पास कोई ऐसा NAT rule नहीं होता जो किसी भी port पर आने वाले packets को आपके tunnel तक भेजे, इसलिए जो connections आपने शुरू नहीं किए, वे exit address पर ही drop हो जाते हैं। Downloads इसलिए काम करते हैं क्योंकि आपका client उन connections को खुद शुरू करता है, और वह किसी भी ऐसे peer तक पहुँच सकता है जो connectable है। Seeding और swarm joins प्रभावित होते हैं, क्योंकि ये दोनों इस बात पर निर्भर करते हैं कि दूसरे लोग आप तक पहुँच सकें। इसका समाधान ऐसा 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 उसे आपके लिए request नहीं कर सकता, लेकिन FIREWALL_VPN_INPUT_PORTS उस fixed port को gluetun के firewall के माध्यम से अनुमति दे देगा। Provider की नीतियां बदलती रहती हैं, इसलिए इसके लिए plan खरीदने से पहले वर्तमान provider page की जाँच करें।

क्या मुझे हर reconnect के बाद port update करना होगा?

हाँ, और यह update automatic होना चाहिए। Forwarded port VPN session का हिस्सा होता है, इसलिए container restart, server change या failed lease renewal के कारण एक नया number मिल सकता है, जबकि client पुराने port को ही अपनी configuration में रखता है। या तो gluetun को VPN_PORT_FORWARDING_UP_COMMAND के साथ इसे push करने दें, जो forwarding शुरू होते ही चलता है, या एक छोटी process चलाएं जो control server से GET /v1/portforward को read करे और उसकी API के माध्यम से value को client में लिख दे।

मैं यह कैसे जाँचूँ कि forwarded port वास्तव में open है?

Gluetun के network namespace के अंदर उस सटीक port पर एक listener चलाएं और VPN के बाहर से उससे connect करें। पहले torrent client को बंद करें ताकि port खाली हो जाए, फिर gluetun container के अंदर --listening-address=":<port>" के साथ 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 का मतलब है कि यह नहीं पहुँच रहा है, चाहे client का अपना status icon कुछ भी दिखाए।