Gluetun port forwarding: torrent app साठी सेटअप

पोर्ट forward केल्याशिवाय कोणतेही कनेक्शन का येत नाही

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 ची नोंद ठेवतो आणि replies तुमच्या tunnel मधून परत पाठवतो. एखाद्या अपरिचित peer कडून आत येणारे connection नोंदवलेल्या कोणत्याही flow शी जुळत नाही. त्यामुळे packet exit address पर्यंत पोहोचतो आणि तिथेच drop होतो. तुमचा client स्वतः connectable असलेल्या प्रत्येक peer पर्यंत तरी पोहोचू शकतो. त्यामुळे downloads पूर्ण होतात आणि ही समस्या दिसून येत नाही. Seeding करताना समस्या स्पष्ट होते, कारण seeder म्हणजे इतर लोक ज्या machine शी connect होतात ती machine.

Inbound port उघडल्याने दोन गोष्टी बदलतात. तुम्ही swarm मध्ये अधिक जलद सामील होता, कारण स्वतः connections स्वीकारू न शकणारे peers आता तुमच्यापर्यंत पोहोचू शकतात. तसेच तुम्ही त्या peers ना upload करू शकता.

बहुतेक VPN प्रदाते forwarded port का देत नाहीत

Forwarded port हे shared address वरील मर्यादित resource असते. प्रदाता एका ग्राहकासाठी एका exit IP वर एक port number राखून ठेवतो आणि त्या ग्राहकाने त्याचा केलेला वापर हाताळण्याची जबाबदारी घेतो. अनेक मोठ्या प्रदात्यांनी ही सुविधा काढून टाकली आणि त्यामागे abuse handling हे कारण दिले. Support ला केवळ checkbox म्हणून न पाहता category question म्हणून विचारा: प्रदाता सध्या port forwarding देतो का, तुमच्या plan मध्ये ते उपलब्ध आहे का आणि तुम्ही प्रत्यक्ष निवडू शकता अशा servers वर ते चालते का.

Forwarding उपलब्ध असेल, तर port dynamic असतो. तो तुमच्या account शी नव्हे, तर VPN session शी संबंधित असतो. त्यामुळे प्रत्येक reconnect नंतर वेगळा number मिळू शकतो. Private Internet Access signed port देते आणि gluetun तो refresh करते. Upstream documentation नुसार, state restart नंतर टिकवण्यासाठी /gluetun directory bind mount केल्यास तोच port 60 दिवस ठेवला जातो. ProtonVPN NAT-PMP (NAT port mapping protocol) द्वारे random port देते. हा port short lease वर असतो आणि त्याचे सतत renewal करावे लागते. म्हणून client मध्ये port एकदाच set केल्याने तो कायम कार्यरत राहत नाही.

gluetun कोणत्या providers कडे port ची विनंती करू शकते

gluetun v3.41.3, 30 July 2026 रोजी released झाल्यापासून, native integration चार provider names पडताळते: Private Internet Access, ProtonVPN, Perfect Privacy आणि PrivateVPN. हे VPN_PORT_FORWARDING=on ने enable करा. हे default म्हणून off आहे. जुन्या मार्गदर्शकांमध्ये PORT_FORWARDING किंवा PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING वापरलेले आढळतात. या आवृत्तीत दोन्ही retro-compatible names म्हणून अजूनही कार्य करतात; मात्र दोन्ही हळूहळू काढून टाकले जात आहेत.

Request यशस्वी होईल की नाही हे दोन provider details ठरवतात. ProtonVPN साठी paid plan आवश्यक आहे आणि NAT-PMP enable केलेले असणे आवश्यक आहे. WireGuard configuration generate करताना VPN options अंतर्गत NAT-PMP (Port Forwarding) enable करा. OpenVPN वापरताना username मध्ये +pmp जोडा. Private Internet Access वरील OpenVPN मध्ये PORT_FORWARD_ONLY आहे. यामुळे server selection फक्त port forwarding समर्थित असलेल्या servers पर्यंत मर्यादित राहते. त्यामुळे forwarding कधीही समर्थित नसलेल्या server वर connection होत नाही. WireGuard आणि OpenVPN मध्ये port ची विनंती करण्याची पद्धत वेगळी आहे, म्हणून निवड करण्यापूर्वी provider चे पृष्ठ वाचा.

gluetun built-in provider ऐवजी custom configuration वापरत असल्यास, gluetun ने कोणत्या API ला call करायचे हे VPN_PORT_FORWARDING_PROVIDER निर्दिष्ट करते. Upstream Private Internet Access पृष्ठ या variable सोबत VPN_PORT_FORWARDING_USERNAME आणि VPN_PORT_FORWARDING_PASSWORD देते. या दोन्हीमध्ये port request साठी आवश्यक account credentials असतात.

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 निश्चित करा. qmcgaw/gluetun:latest master branch चे अनुसरण करते. त्या branch मध्ये v4 साठी port forwarding ची अंतर्गत रचना बदलत आहे. त्यामुळे unpinned image मुळे पुढील docker compose pull वेळी वर्तन बदलू शकते. compose secrets साठी env file वापरून private key compose file बाहेर ठेवा.

Gluetun forwarded port कुठे लिहितो

Gluetun हा पोर्ट तीन ठिकाणी उपलब्ध करून देतो आणि तिन्ही ठिकाणी समान मूल्य असते.

प्रत्येक acquisition वेळी तो पोर्ट एकदा log मध्ये लिहितो. ओळ port forwarded is 45678 अशी असते; request मुळे काहीही मिळाले नाही तर ती no port forwarded असते.

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

VPN_PORT_FORWARDING_STATUS_FILE ने निर्दिष्ट केलेल्या फाइलमध्ये तो संख्या लिहितो. या फाइलचा default /tmp/gluetun/forwarded_port असतो. फाइलमध्ये प्रत्येक ओळीवर एक पोर्ट असतो. ती 0644 mode ने लिहिली जाते आणि container मधील PUID व PGID ला chown केली जाते. Forwarding थांबल्यावर gluetun फाइल delete करण्याऐवजी ती रिकामी करतो. त्यामुळे consumer ला missing file error ऐवजी रिकामी फाइल वाचता येते.

docker exec gluetun cat /tmp/gluetun/forwarded_port

तो 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 मध्येही हा पोर्ट उघडतो. त्यामुळे native integration हे काम करत असताना FIREWALL_VPN_INPUT_PORTS ची आवश्यकता नसते. दुसऱ्या परिस्थितीसाठी हे variable वापरले जाते: provider असा असेल की ज्याची चौकशी gluetun करू शकत नाही, आणि तुम्हाला out-of-band पद्धतीने static port दिला असेल, तर तो पोर्ट manually allow करावा लागतो.

या तीनपैकी एक पद्धत टिकाऊ आहे आणि दोन टिकाऊ नाहीत. Upstream documentation मध्ये status file ला v4.0.0 पासून deprecated म्हणून नमूद केले आहे. तसेच GET /v1/openvpn/portforwarded आधीच 301 Moved Permanently असा प्रतिसाद देते आणि /v1/portforward कडे निर्देश करते. नवीन कामासाठी control server मधून मूल्य वाचावे.

प्रत्येक reconnect वेळी client ला port का सांगावा लागतो

torrent client स्वतःच्या configuration मध्ये listening port साठवतो आणि restart नंतरही तोच port ठेवतो. Forward केलेला port हा VPN session चा गुणधर्म असतो. Reconnect नंतर हे दोन port वेगवेगळे असतात. त्यामुळे provider अशा port वर mapping करतो ज्यावर काहीही listen करत नाही, आणि client अशा port वर listen करतो ज्याचे mapping केलेले नसते. Reconnect क्वचितच होत नाहीत: container restart, server बदल, gluetun च्या health check मुळे restart झालेला dropped tunnel किंवा renew न करता आलेली lease यांपैकी कोणत्याही कारणाने ते होऊ शकते. परिणामी काल reachable असलेली setup आज कोणत्याही log मध्ये error नोंदला न जाता शांतपणे unreachable होते.

म्हणून gluetun ला port मिळताच तो 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 चे नाव; default म्हणून tun0) यांची मूल्ये भरतो. 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 वर सेट केल्यास पुढील start वेळी qBittorrent स्वतःचा port निवडत नाही. upnp false वर सेट केल्यास उपलब्ध नसलेल्या router द्वारे port map करण्याचा प्रयत्न qBittorrent करत नाही.

या पद्धतीसाठी दोन आवश्यकता आहेत. 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 पाठवत नाही. disconnect झाल्यानंतर qBittorrent port नेहमी पुन्हा स्थापित करत नाही. त्यामुळे down command आवश्यक आहे.

हा command gluetun container मध्ये चालतो. हे container Alpine वर आधारित आहे आणि त्यात wget उपलब्ध आहे. त्या image मध्ये curl नाही. image मध्ये नसलेल्या binary चे नाव देणारा command forwarding सुरू झाल्यावर प्रत्येक वेळी fail होतो.

पर्याय 2: gluetun च्या बाहेरील process पोर्ट वाचतो

या पद्धतीत gluetun च्या बाजूला एक छोटा process चालतो. तो पोर्ट मिळवतो आणि client च्या स्वतःच्या API द्वारे तो client मध्ये पाठवतो. तो control server कडून वाचा:

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

किंवा process ला ती file दिसत असल्यास file वाचा. /tmp/gluetun/forwarded_port ही gluetun container च्या आत असते. त्यामुळे sidecar साठी दोन्ही containers मध्ये /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 logs मध्ये route GET /v1/portforward is unprotected by default, please set up authentication ने सुरू होणारी warning नोंदवतो. पुढील release मध्ये upstream हा मार्ग बंद करणार आहे. त्यामुळे /gluetun/auth/config.toml येथे bind mounted केलेल्या file मध्ये आत्ताच 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 मध्ये पाठवा. File mount करायची नसल्यास HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE हे एका JSON-encoded environment variable सारखेच काम करते. role शिवाय प्रकाशित केलेला port 8000 ज्याला पोहोचता येतो अशा कोणालाही VPN state नियंत्रित करण्याची क्षमता देतो. त्यामुळे host आणि इतर containers मधून gluetun पर्यंत कसे पोहोचायचे हे ठरवताना तो किती दूरपर्यंत उपलब्ध असेल याचा जाणीवपूर्वक निर्णय घ्या.

जेव्हा client कडे एका wget call ने चालवता येणारी API उपलब्ध असेल, तेव्हा up command निवडा. तो प्रत्येक event साठी नेमका एकदाच चालतो आणि सतत सुरू ठेवण्यासाठी अतिरिक्त process लागत नाही. Client ला login flow, config file rewrite किंवा restart आवश्यक असल्यास external process निवडा. एका gluetun container मागे arr stack मध्ये हे सहसा एका छोट्या poller पर्यंत मर्यादित राहते, कारण पोर्टची आवश्यकता फक्त torrent client ला असते.

सापळा: namespace share केल्याने listening port सेट होत नाही

ही समस्या सर्वाधिक वेळ वाया घालवते. network_mode: "service:gluetun" क्लायंटला gluetun च्या network namespace मध्ये ठेवते. त्यामुळे क्लायंटला VPN address, tunnel routes आणि gluetun चे firewall rules मिळतात. मात्र यापैकी कशानेही क्लायंटचा listening port सेट होत नाही. gluetun VPN interface वर forwarded port उघडते. त्या port साठीचे packets namespace मध्ये पोहोचतात. क्लायंट वेगळ्या port वर listen करत असल्यास kernel कडे ते packets पोहोचवण्यासाठी कोणतेही socket नसते. त्यामुळे प्रत्येक outbound check यशस्वी दिसत असतानाही connection नाकारले जाते किंवा timeout होते. 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 एका fixed local port कडे redirect करते. Upstream कडील सूचनेनुसार torrent clients सोबत ही setting वापरू नका. कारण क्लायंट trackers आणि peers ना स्वतःचा listening port जाहीर करते. त्यामुळे swarm ला चुकीचा number कळतो.

पुढे पाठवलेला पोर्ट पोहोचण्यायोग्य आहे हे कसे सिद्ध करावे

क्लायंटचे स्वतःचे connection indicator बाहेर जाणाऱ्या 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 आणि पुढे पाठवलेल्या 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 यासाठी योग्य आहे. तुमचा browser IP address आणि user agent दाखवणारे page दिसले आणि port-checker मध्ये त्याच request ची नोंद झाली, तर inbound TCP namespace पर्यंत पोहोचत आहे. Timeout आल्यास ते पोहोचत नाही. त्याचे कारण client च्या वरच्या स्तरावर आहे. Tool थांबवण्यासाठी CTRL+C दाबा, exit ने shell मधून बाहेर पडा आणि client पुन्हा सुरू करा. ही तपासणी फक्त TCP तपासते. DHT (distributed hash table) आणि uTP traffic त्याच port number वर UDP वापरतात. या चाचणीत त्यांची तपासणी होत नाही.

अपयशाच्या स्थिती आणि दिसणारे संदेश

लॉगमध्ये पोर्टची कोणतीही ओळ नाही. पोर्टसाठी कोणतीही विनंती करण्यात आलेली नाही. docker exec gluetun printenv | grep PORT_FORWARDING वापरून चलाचे मूल्य प्रत्यक्षात कंटेनरपर्यंत पोहोचले आहे का ते तपासा. चुकीच्या compose service मध्ये चल सेट करणे हे याचे सामान्य कारण आहे.

Gluetun सुरू होण्यास नकार देतो आणि provider बद्दल त्रुटी दाखवतो. VPN_PORT_FORWARDING_PROVIDER चे मूल्य समर्थित चार नावांशी पडताळले जाते. त्यामुळे नावात टंकलेखनाची चूक असल्यास forwarding शिवाय शांतपणे सुरू होण्याऐवजी कंटेनर थांबतो.

लॉगमध्ये no port forwarded असे दिसते. Gluetun ने विनंती केली, पण provider ने कोणतेही मूल्य परत केले नाही. ProtonVPN मध्ये याचा अर्थ सामान्यतः तयार केलेल्या configuration मध्ये NAT-PMP सक्षम केलेले नाही किंवा तुमच्या plan मध्ये forwarding समाविष्ट नाही. Private Internet Access मध्ये याचा अर्थ सामान्यतः निवडलेल्या server वर ते उपलब्ध नाही.

पोर्ट मिळतो, पण कोणतेही connection येत नाही. वरील दोन commands वापरून forwarded port आणि client चा listening port यांची तुलना करा. दोन्ही समान असल्यास client tunnel interface वर bind आहे का आणि त्याचा random-port पर्याय बंद आहे का ते तपासा. हा पर्याय प्रत्येक सुरूवातीला listening port पुन्हा बदलतो.

up command काहीच करत नाही असे दिसते. त्रुटी पाहण्यासाठी कंटेनरमध्ये अचूक command चालवा: docker exec gluetun /bin/sh -c '<your command>'. सामान्यतः curl: not found परिणाम मिळतो, कारण image मध्ये फक्त wget उपलब्ध असते.

control server कडून 401 Unauthorized. तुम्ही auth config परिभाषित केले आहे, पण role मध्ये तुम्ही कॉल करत असलेला route नमूद केलेला नाही. Routes ची जुळवणी method आणि path यांच्या आधारे होते. त्यामुळे role मध्ये फक्त /v1/portforward नमूद असल्यास ते GET /v1/portforward समाविष्ट करत नाही.

प्रत्येक restart नंतर Private Internet Access वर वेगळा पोर्ट मिळतो. जतन केलेली port state restart नंतरही टिकण्यासाठी /gluetun bind mount करा. हा volume नसल्यास gluetun प्रत्येक वेळी नवीन पोर्टची विनंती करतो.

FAQ

माझे torrents download होतात, पण incoming connections कधीच का येत नाहीत?

forwarded port नसल्यास VPN provider कडे कोणत्याही port वरील inbound packets तुमच्या tunnel कडे पाठवणारा NAT rule नसतो. त्यामुळे तुम्ही सुरू न केलेली connections exit address वरच drop होतात. Downloads तरीही चालतात, कारण तुमचा client त्या connections स्वतः उघडतो आणि connectable असलेल्या कोणत्याही peer पर्यंत पोहोचू शकतो. Seeding आणि swarm मध्ये सहभागी होण्यावर याचा परिणाम होतो, कारण दोन्हींसाठी इतर लोकांनी तुमच्यापर्यंत पोहोचणे आवश्यक असते. यासाठी port forwarding देणारा provider वापरा, VPN_PORT_FORWARDING=on in gluetun सक्षम करा आणि मिळालेला 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 तो port तुमच्यासाठी request करू शकत नाही. मात्र FIREWALL_VPN_INPUT_PORTS तो fixed port gluetun च्या firewall मधून allow करेल. Provider policies बदलू शकतात. त्यामुळे यासाठी plan खरेदी करण्यापूर्वी सध्याचे provider page तपासा.

प्रत्येक reconnect नंतर port update करणे आवश्यक आहे का?

होय. हे update automatic असावे. Forwarded port हा VPN session शी संबंधित असतो. त्यामुळे container restart, server change किंवा अयशस्वी lease renewal यामुळे नवीन number मिळू शकतो. दरम्यान, client स्वतःच्या configuration मध्ये जुना port ठेवू शकतो. Forwarding सुरू होताच चालणाऱ्या VPN_PORT_FORWARDING_UP_COMMAND द्वारे gluetun ने तो port लागू करू द्या. किंवा control server कडून GET /v1/portforward वाचून API द्वारे ती value client मध्ये लिहिणारी छोटी process चालवा.

forwarded port खरोखर open आहे का हे कसे तपासावे?

gluetun च्या network namespace मध्ये त्याच exact 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 TCP पोहोचत नाही, client च्या स्वतःच्या status icon मध्ये काहीही दिसत असले तरी.