Gluetun లో పోర్ట్ ఫార్వార్డింగ్ సెటప్ చేయడం ఎలా?

పోర్ట్ ఫార్వార్డింగ్ లేనప్పుడు కనెక్షన్లు ఎందుకు రావు

Gluetun పోర్ట్ ఫార్వార్డింగ్ మీ VPN ప్రొవైడర్‌ను దాని ఎగ్జిట్ అడ్రస్‌పై ఉన్న ఒక పబ్లిక్ పోర్ట్‌ను మీ కంటైనర్‌కు మ్యాప్ చేయమని అడుగుతుంది. వేరొక పీర్ మీ టొరెంట్ క్లయింట్‌కు కనెక్షన్‌ను ప్రారంభించాలంటే ఇదే ఏకైక మార్గం. ఆ మ్యాపింగ్ లేకపోతే, టన్నెల్ ఆరోగ్యంగానే ఉంటుంది, డౌన్‌లోడ్‌లు జరుగుతాయి, కానీ బయటి నుంచి ఏ కనెక్షనూ రాదు. ప్రతి పని చేసే కనెక్షన్ మీ క్లయింట్ మొదట ప్రారంభించినదే అయి ఉంటుంది.

దీని వెనుక ఉన్న విధానం NAT (network address translation). మీ కంటైనర్, ప్రొవైడర్ యొక్క ఎగ్జిట్ అడ్రస్‌ను ఇతర వినియోగదారులతో పంచుకుంటుంది. మీ క్లయింట్ బయటకు కనెక్షన్‌ను తెరిచినప్పుడు, ప్రొవైడర్ ఆ ప్రవాహాన్ని (flow) నమోదు చేసుకుని, సమాధానాలను మీ టన్నెల్ ద్వారా తిరిగి పంపుతుంది. ఒక అపరిచిత పీర్ లోపలికి కనెక్ట్ అవ్వడానికి ప్రయత్నిస్తే, అది ఏ రికార్డ్ చేయబడిన ప్రవాహంతోనూ సరిపోలదు. కాబట్టి, ఆ ప్యాకెట్ ఎగ్జిట్ అడ్రస్‌కు చేరుకుని అక్కడే నిలిపివేయబడుతుంది (dropped). మీ క్లయింట్ కనెక్ట్ అవ్వగలిగే ప్రతి పీర్‌ను చేరుకోగలదు కాబట్టి, డౌన్‌లోడ్‌లు పూర్తవుతాయి మరియు ఈ సమస్య బయటకు కనిపించదు. సీడింగ్ (seeding) చేసేటప్పుడు మాత్రమే ఇది స్పష్టంగా తెలుస్తుంది, ఎందుకంటే సీడర్ అనేది ఇతర వ్యక్తులు కనెక్ట్ అయ్యే యంత్రం.

ఒక ఓపెన్ ఇన్‌బౌండ్ పోర్ట్ రెండు విషయాలను మారుస్తుంది. మీరు స్వయంగా కనెక్షన్లను స్వీకరించలేని పీర్లు ఇప్పుడు మిమ్మల్ని చేరుకోగలవు కాబట్టి, మీరు త్వరగా స్వార్మ్ (swarm) లో చేరగలరు మరియు ఆ పీర్లకు మీరు అప్‌లోడ్ చేయగలరు.

చాలా మంది VPN ప్రొవైడర్లు పోర్ట్ ఫార్వార్డింగ్‌ను ఎందుకు అందించరు

షేర్డ్ అడ్రస్‌పై ఫార్వర్డ్ చేసిన పోర్ట్ అనేది ఒక అరుదైన వనరు. ప్రొవైడర్ ఒక ఎగ్జిట్ IPపై ఒక పోర్ట్ నంబర్‌ను ఒక కస్టమర్ కోసం కేటాయిస్తుంది, ఆ తర్వాత ఆ కస్టమర్ దానితో చేసే పనులకు ప్రొవైడర్ బాధ్యత వహించాల్సి ఉంటుంది. దుర్వినియోగం (abuse) జరగడాన్ని కారణంగా చూపుతూ పలువురు పెద్ద ప్రొవైడర్లు ఈ ఫీచర్‌ను తొలగించారు. సపోర్ట్ గురించి అడిగేటప్పుడు అది ఒక చెక్‌బాక్స్ లాగా కాకుండా, ఒక కేటగిరీ ప్రశ్నగా పరిగణించండి: మీ ప్లాన్‌లో మరియు మీరు ఎంచుకోగల సర్వర్లలో ప్రస్తుతం పోర్ట్ ఫార్వార్డింగ్ అందుబాటులో ఉందా అని ప్రొవైడర్‌ను అడగండి.

ఫార్వార్డింగ్ ఉన్న చోట, ఆ పోర్ట్ డైనమిక్‌గా ఉంటుంది. ఇది మీ ఖాతాకు కాకుండా VPN సెషన్‌కు చెందుతుంది, కాబట్టి ప్రతిసారి రీకనెక్ట్ అయినప్పుడు అది వేరే నంబర్ కావచ్చు. Private Internet Access ఒక సైన్డ్ పోర్ట్‌ను జారీ చేస్తుంది, దీనిని gluetun రిఫ్రెష్ చేస్తుంది. మీరు /gluetun డైరెక్టరీని bind mount చేసినంత కాలం, ఆ స్టేట్ రీస్టార్ట్ తర్వాత కూడా అలాగే ఉంటుందని, తద్వారా మీరు 60 రోజుల పాటు అదే పోర్ట్‌ను కలిగి ఉండవచ్చని అప్‌స్ట్రీమ్ డాక్యుమెంటేషన్ చెబుతోంది. ProtonVPN అనేది NAT-PMP (NAT port mapping protocol) ద్వారా స్వల్పకాలిక లీజుపై ఒక రాండమ్ పోర్ట్‌ను కేటాయిస్తుంది, దీనిని నిరంతరం రెన్యూ చేయాల్సి ఉంటుంది. అందుకే క్లయింట్‌లో పోర్ట్‌ను ఒక్కసారి సెట్ చేయడం వల్ల అది శాశ్వతంగా పనిచేయదు.

gluetun ఏ ప్రొవైడర్ల కోసం పోర్ట్‌ను అడగగలదు

30 జూలై 2026న విడుదలైన gluetun v3.41.3 నాటికి, నేటివ్ ఇంటిగ్రేషన్ నాలుగు ప్రొవైడర్ పేర్లను ధృవీకరిస్తుంది: 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 అంతర్నిర్మిత ప్రొవైడర్‌కు బదులుగా కస్టమ్ కాన్ఫిగరేషన్‌ను రన్ చేసినప్పుడు, gluetun పిలవాల్సిన APIని VPN_PORT_FORWARDING_PROVIDER పేర్కొంటుంది. అప్‌స్ట్రీమ్ Private Internet Access పేజీ ఆ వేరియబుల్‌ను VPN_PORT_FORWARDING_USERNAME మరియు VPN_PORT_FORWARDING_PASSWORDలతో జత చేస్తుంది, ఇవి పోర్ట్ అభ్యర్థనకు అవసరమైన ఖాతా ఆధారాలను (credentials) కలిగి ఉంటాయి.

Docker compose లో gluetun port forwarding ను ఆన్ చేయడం

దీని కోసం మీ టన్నెల్ ఇప్పటికే పనిచేస్తూ ఉండాలి. ఒకవేళ పనిచేయకపోతే, ముందుగా 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

ట్యాగ్‌ను పిన్ చేయండి. qmcgaw/gluetun:latest అనేది master బ్రాంచ్‌ను అనుసరిస్తుంది, ఇందులో v4 కోసం port forwarding అంతర్గత అంశాలు మారుతున్నాయి, కాబట్టి పిన్ చేయని image తదుపరి docker compose pull వద్ద ప్రవర్తనను మార్చవచ్చు. compose secrets కోసం env ఫైల్ ఉపయోగించి private key ని 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 కి chown చేయబడుతుంది. ఫార్వార్డింగ్ ఆగిపోయినప్పుడు, 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 ఇంటర్‌ఫేస్‌లోని దాని స్వంత ఫైర్‌వాల్‌లో కూడా తెరుస్తుంది, కాబట్టి నేటివ్ ఇంటిగ్రేషన్ పని చేస్తున్నప్పుడు FIREWALL_VPN_INPUT_PORTS అవసరం లేదు. ఆ వేరియబుల్ మరొక సందర్భాన్ని కవర్ చేస్తుంది: gluetun క్వెరీ చేయలేని ప్రొవైడర్ ఉన్నప్పుడు, మీకు స్టాటిక్ పోర్ట్ కేటాయించబడితే మరియు మీరు దానిని మాన్యువల్‌గా అనుమతించాల్సి వస్తే ఇది ఉపయోగపడుతుంది.

ఈ మూడింటిలో ఒకటి శాశ్వతమైనది మరియు రెండు కావు. అప్‌స్ట్రీమ్ డాక్యుమెంటేషన్ స్టేటస్ ఫైల్‌ను v4.0.0 లో నిలిపివేయబడినట్లుగా (deprecated) పేర్కొంది, మరియు GET /v1/openvpn/portforwarded ఇప్పటికే 301 Moved Permanently తో సమాధానమిస్తూ /v1/portforward ని సూచిస్తోంది. కొత్త పనుల కోసం కంట్రోల్ సర్వర్‌ను చదవడం మంచిది.

ప్రతిసారీ reconnect అయినప్పుడు client కు port ఎందుకు తెలియజేయాలి

ఒక torrent client తన listening port ను సొంత configuration లో భద్రపరుచుకుంటుంది మరియు restart అయిన తర్వాత కూడా అదే నంబర్‌ను ఉంచుకుంటుంది. కానీ forwarded port అనేది VPN session కు సంబంధించిన ఒక లక్షణం. Reconnect అయిన తర్వాత ఈ రెండు నంబర్లు వేర్వేరుగా ఉంటాయి. దీనివల్ల, ఏ సేవ వినని (listen చేయని) port కు provider మ్యాపింగ్ చేస్తుంది, అలాగే ఏ మ్యాపింగ్ లేని port లో client వింటుంది. Reconnect లు తరచుగా జరుగుతుంటాయి: container restart అవ్వడం, server మారడం, gluetun యొక్క health check ద్వారా tunnel పడిపోయి మళ్ళీ restart అవ్వడం, లేదా lease renew అవ్వకపోవడం వంటివి కారణాలు కావచ్చు. దీని ఫలితంగా, నిన్న అందుబాటులో ఉన్న setup ఈరోజు నిశ్శబ్దంగా అందుబాటులో లేకుండా పోతుంది, కానీ ఏ log లోనూ ఎటువంటి error కనిపించదు.

కాబట్టి, gluetun ఆ port ను పొందిన వెంటనే దానిని వర్తింపజేయాలి. దీనిని అమలు చేయడానికి రెండు మార్గాలు ఉన్నాయి, ఏ process ఈ పనిని చేస్తుందనే దానిపై అవి ఆధారపడి ఉంటాయి.

Option 1: gluetun ఒక up కమాండ్‌తో పోర్ట్‌ను పుష్ చేస్తుంది

VPN_PORT_FORWARDING_UP_COMMAND పోర్ట్ ఫార్వార్డింగ్ ప్రారంభమైనప్పుడు రన్ అవుతుంది, మరియు VPN_PORT_FORWARDING_DOWN_COMMAND అది ఆగిపోయినప్పుడు రన్ అవుతుంది. కమాండ్‌ను రన్ చేసే ముందు Gluetun {{PORT}} (మొదటి పోర్ట్), {{PORTS}} (అన్నీ, కామాతో వేరు చేయబడినవి) మరియు {{VPN_INTERFACE}} (టన్నెల్ ఇంటర్‌ఫేస్ పేరు, డిఫాల్ట్‌గా tun0) లను ప్రతిక్షేపిస్తుంది. షెల్ సింటాక్స్‌కు స్పష్టమైన /bin/sh -c వ్రాపర్ అవసరం. ఇది అప్‌స్ట్రీమ్ qBittorrent ఉదాహరణ, దీనిని రెండు compose environment ఎంట్రీలుగా వ్రాయబడింది:

      - 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 యొక్క web UI, gluetun కంటైనర్ లోపలి నుండి 127.0.0.1:8080 పై స్పందించాలి, క్లయింట్ gluetun యొక్క network namespace ను షేర్ చేసుకున్నప్పుడు ఇది ఆటోమేటిక్‌గా జరుగుతుంది. మరియు Bypass authentication for clients on localhost (bypass_local_auth) ఎనేబుల్ చేయబడాలి, ఎందుకంటే ఈ కమాండ్ ఎటువంటి క్రెడెన్షియల్స్‌ను పంపదు. డిస్‌కనెక్ట్ అయిన తర్వాత qBittorrent ఎల్లప్పుడూ పోర్ట్‌ను తిరిగి ఏర్పాటు చేయదు కాబట్టి down కమాండ్ అక్కడ ఉంటుంది.

ఈ కమాండ్ gluetun కంటైనర్ లోపల రన్ అవుతుంది, ఇది Alpine పై నిర్మించబడింది మరియు wget ను కలిగి ఉంటుంది. ఆ ఇమేజ్‌లో curl ఉండదు. ఇమేజ్‌లో లేని బైనరీ పేరును పేర్కొనే కమాండ్, ఫార్వార్డింగ్ ప్రారంభమైన ప్రతిసారీ విఫలమవుతుంది.

Option 2: gluetun వెలుపల ఉన్న ఒక ప్రాసెస్ పోర్ట్‌ను చదవడం

మరొక పద్ధతిలో gluetun పక్కన ఒక చిన్న ప్రాసెస్‌ను రన్ చేస్తారు. ఇది పోర్ట్‌ను సేకరించి, క్లయింట్ యొక్క API ద్వారా దానిని క్లయింట్‌కు పంపుతుంది. కంట్రోల్ సర్వర్ నుండి దీనిని చదవండి:

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

లేదా, ఆ ప్రాసెస్‌కు ఫైల్ కనిపించే అవకాశం ఉంటే దానిని చదవండి. /tmp/gluetun/forwarded_port అనేది gluetun కంటైనర్ లోపల ఉంటుంది, కాబట్టి సైడ్‌కార్ (sidecar) కోసం /tmp/gluetun వద్ద రెండు కంటైనర్లలో షేర్డ్ వాల్యూమ్ మౌంట్ చేయాలి, లేదా మీరు ఇప్పటికే మౌంట్ చేసిన వాల్యూమ్ కింద ఉన్న పాత్‌కు VPN_PORT_FORWARDING_STATUS_FILE ని పాయింట్ చేయాలి.

ఇక్కడ అథెంటికేషన్ (Authentication) ముఖ్యం. v3.41.3 వెర్షన్‌లో GET /v1/portforward రూట్, auth = "none" కలిగిన public అనే డిఫాల్ట్ రోల్‌కు చెందుతుంది. కాబట్టి ఇది క్రెడెన్షియల్స్ లేకుండానే సమాధానం ఇస్తుంది మరియు gluetun, route GET /v1/portforward is unprotected by default, please set up authentication తో మొదలయ్యే హెచ్చరికను లాగ్ చేస్తుంది. అప్‌స్ట్రీమ్ దీనిని తదుపరి వెర్షన్‌లో నిలిపివేస్తోంది. కాబట్టి, /gluetun/auth/config.toml వద్ద బైండ్ మౌంట్ చేసిన ఫైల్‌లో ఇప్పుడే ఒక రోల్‌ను డిఫైన్ చేయండి:

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

docker run --rm qmcgaw/gluetun:v3.41.3 genkey తో ఒక కీని జనరేట్ చేసి, దానిని X-API-Key హెడర్‌లో పంపండి. మీరు ఫైల్‌ను మౌంట్ చేయకూడదనుకున్నప్పుడు, JSON-encoded ఎన్విరాన్‌మెంట్ వేరియబుల్ చేసే పనినే HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE కూడా చేస్తుంది. రోల్ లేకుండా పోర్ట్ 8000 ను పబ్లిష్ చేస్తే, దానిని యాక్సెస్ చేయగల ఎవరైనా VPN స్థితిని నియంత్రించగలరు. కాబట్టి, gluetun ను హోస్ట్ మరియు ఇతర కంటైనర్ల నుండి ఎలా చేరుకోవాలో నిర్ణయించుకునేటప్పుడు, అది ఎంతవరకు అందుబాటులో ఉండాలో జాగ్రత్తగా ఆలోచించండి.

క్లయింట్ ఒక APIని ఎక్స్‌పోజ్ చేసినప్పుడు, ఒకే wget కాల్‌తో పని పూర్తవుతుందంటే 'up' కమాండ్‌ను ఎంచుకోండి, ఎందుకంటే ఇది ప్రతి ఈవెంట్‌కు ఒకసారి మాత్రమే రన్ అవుతుంది మరియు అదనపు ప్రాసెస్‌లను రన్ చేయదు. క్లయింట్‌కు లాగిన్ ఫ్లో, కాన్ఫిగరేషన్ ఫైల్ రీరైట్ లేదా రీస్టార్ట్ అవసరమైనప్పుడు ఎక్స్‌టర్నల్ ప్రాసెస్‌ను ఎంచుకోండి. ఒక gluetun కంటైనర్ వెనుక ఉన్న arr stack లో, టొరెంట్ క్లయింట్‌కు మాత్రమే పోర్ట్ అవసరం కాబట్టి, ఇది సాధారణంగా ఒక చిన్న పోలర్‌గా ముగుస్తుంది.

చిక్కుముడి: నెట్‌వర్క్ నేమ్‌స్పేస్‌ను పంచుకున్నంత మాత్రాన లిజనింగ్ పోర్ట్ సెట్ అవ్వదు

ఈ వైఫల్యం వల్ల ఎక్కువ సమయం వృథా అవుతుంది. network_mode: "service:gluetun" క్లయింట్‌ను gluetun యొక్క నెట్‌వర్క్ నేమ్‌స్పేస్‌లోకి చేరుస్తుంది, దీనివల్ల దానికి VPN అడ్రస్, టన్నెల్ రూట్లు మరియు gluetun యొక్క ఫైర్‌వాల్ నియమాలు వర్తిస్తాయి. అయితే, ఇవేవీ క్లయింట్ యొక్క లిజనింగ్ పోర్ట్‌ను సెట్ చేయవు. Gluetun ఫార్వర్డ్ చేసిన పోర్ట్‌ను VPN ఇంటర్‌ఫేస్‌పై తెరుస్తుంది, ఆ పోర్ట్‌కు వచ్చే ప్యాకెట్లు నేమ్‌స్పేస్‌లోకి చేరుతాయి. ఒకవేళ క్లయింట్ వేరే పోర్ట్‌పై వింటుంటే (listen), వాటిని పంపడానికి కెర్నల్‌కు సరైన గమ్యం ఉండదు. అవుట్‌బౌండ్ చెక్‌లు అన్నీ సక్రమంగా ఉన్నట్లు కనిపిస్తున్నప్పటికీ, కనెక్షన్ తిరస్కరించబడుతుంది లేదా టైమ్ అవుట్ అవుతుంది. ఫార్వర్డ్ చేసిన పోర్ట్ మరియు క్లయింట్ యొక్క లిజనింగ్ పోర్ట్ అనేవి రెండు వేర్వేరు సంఖ్యలు; వాటిని సమానంగా ఉంచడమే అసలైన పని.

ఊహించడం కంటే వాటిని సరిపోల్చడం ఉత్తమం. ఈ రెండు కమాండ్లను ఒకే నేమ్‌స్పేస్‌పై రన్ చేయాలి:

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 ఉపయోగించి ఫార్వర్డ్ చేసిన పోర్ట్ నుండి ఇన్‌బౌండ్ ట్రాఫిక్‌ను ఒక స్థిరమైన లోకల్ పోర్ట్‌కు మళ్ళిస్తుంది. టొరెంట్ క్లయింట్‌లతో దీన్ని వాడవద్దని అప్‌స్ట్రీమ్ సూచిస్తుంది, ఎందుకంటే క్లయింట్ తన సొంత లిజనింగ్ పోర్ట్‌ను ట్రాకర్లకు మరియు పీర్లకు తెలియజేస్తుంది, దీనివల్ల స్వార్మ్ (swarm) తప్పుడు సంఖ్యను నేర్చుకుంటుంది.

ఫార్వర్డ్ చేసిన పోర్ట్ అందుబాటులో ఉందని ఎలా నిర్ధారించాలి

క్లయింట్ యొక్క సొంత కనెక్షన్ సూచిక అవుట్‌బౌండ్ ట్రాకర్ కనెక్షన్‌లను మాత్రమే ప్రతిబింబిస్తుంది, కాబట్టి ఏదీ మిమ్మల్ని చేరుకోలేకపోయినా అది ఆకుపచ్చ రంగులో కనిపించవచ్చు. టన్నెల్ వెలుపల ఉన్న నెట్‌వర్క్ నుండి, మీ నియంత్రణలో ఉన్న లిజనర్‌తో పరీక్షించండి. అప్‌స్ట్రీమ్ దీని కోసం ఒక చిన్న సాధనాన్ని అందిస్తుంది. ముందుగా టొరెంట్ క్లయింట్‌ను ఆపివేయండి, ఎందుకంటే రెండు ప్రాసెస్‌లు ఒకే పోర్ట్‌ను బైండ్ చేయలేవు.

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

కంటైనర్ లోపల, మీ CPU ఆర్కిటెక్చర్ కోసం amd64 ని మరియు మీరు ఫార్వర్డ్ చేసిన పోర్ట్ కోసం 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 అడ్రస్ మరియు యూజర్ ఏజెంట్‌ను చూపే పేజీ, port-checker ద్వారా లాగ్ చేయబడిన మ్యాచింగ్ అభ్యర్థనతో ఉంటే, ఇన్‌బౌండ్ TCP నేమ్‌స్పేస్‌ను చేరుకుంటుందని అర్థం. టైమ్-అవుట్ వస్తే అది చేరుకోవడం లేదని అర్థం, మరియు దీనికి కారణం క్లయింట్‌కు పైన ఉంటుంది. CTRL+C తో సాధనాన్ని ఆపివేయండి, exit తో షెల్ నుండి బయటకు రండి, ఆపై క్లయింట్‌ను మళ్ళీ ప్రారంభించండి. ఈ పరీక్ష TCPని మాత్రమే తనిఖీ చేస్తుంది. DHT (distributed hash table) మరియు uTP ట్రాఫిక్ అదే పోర్ట్ నంబర్‌పై UDPని ఉపయోగిస్తాయి, ఇది ఈ పరీక్ష పరిధిలోకి రాదు.

వైఫల్య రీతులు మరియు మీకు కనిపించే స్ట్రింగ్‌లు

లాగ్‌లో పోర్ట్ లైన్ అస్సలు లేకపోవడం. ఏదీ పోర్ట్ కోసం అడగలేదు. docker exec gluetun printenv | grep PORT_FORWARDING తో వేరియబుల్ కంటైనర్‌కు చేరిందో లేదో నిర్ధారించుకోండి, ఎందుకంటే తప్పు compose సర్వీస్‌లో సెట్ చేసిన వేరియబుల్ సాధారణంగా ఇలా జరగడానికి కారణమవుతుంది.

Gluetun ప్రారంభం కాకుండా ప్రొవైడర్ గురించి ఫిర్యాదు చేయడం. VPN_PORT_FORWARDING_PROVIDER నాలుగు మద్దతు ఉన్న పేర్లతో సరిచూసుకోబడుతుంది, కాబట్టి ఏదైనా అక్షర దోషం ఉంటే కంటైనర్ ఫార్వార్డింగ్ లేకుండా నిశ్శబ్దంగా నడవకుండా ఆగిపోతుంది.

లాగ్‌లో no port forwarded అని ఉండటం. Gluetun అడిగింది, కానీ ప్రొవైడర్ ఏమీ ఇవ్వలేదు. ProtonVPNలో సాధారణంగా మీరు రూపొందించిన కాన్ఫిగరేషన్‌లో NAT-PMP ఎనేబుల్ చేయబడలేదని లేదా మీ ప్లాన్‌లో ఫార్వార్డింగ్ లేదని అర్థం. Private Internet Accessలో సాధారణంగా ఎంచుకున్న సర్వర్ దీనిని అందించడం లేదని అర్థం.

పోర్ట్ వచ్చింది, కానీ ఏదీ కనెక్ట్ అవ్వడం లేదు. పైన పేర్కొన్న రెండు కమాండ్లను ఉపయోగించి ఫార్వార్డ్ చేసిన పోర్ట్‌ను క్లయింట్ యొక్క లిజనింగ్ పోర్ట్‌తో పోల్చండి. అవి సరిపోలితే, క్లయింట్ టన్నెల్ ఇంటర్‌ఫేస్‌కు బౌండ్ అయి ఉందో లేదో మరియు దాని random-port ఆప్షన్ ఆఫ్ చేయబడిందో లేదో తనిఖీ చేయండి, ఎందుకంటే ఆ ఆప్షన్ ప్రతి స్టార్టప్‌లో లిజనింగ్ పోర్ట్‌ను మారుస్తుంది.

up కమాండ్ ఏమీ చేయనట్లు అనిపిస్తుంది. లోపమేమిటో చూడటానికి కంటైనర్ లోపల ఈ కమాండ్‌ను రన్ చేయండి: docker exec gluetun /bin/sh -c '<your command>'. సాధారణంగా curl: not found ఫలితం వస్తుంది, ఎందుకంటే ఇమేజ్ wget ను మాత్రమే కలిగి ఉంటుంది.

కంట్రోల్ సర్వర్ నుండి 401 Unauthorized. మీరు auth కాన్ఫిగరేషన్‌ను నిర్వచించారు, కానీ మీరు పిలుస్తున్న రూట్ ఆ రోల్‌లో లేదు. రూట్‌లు మెథడ్ మరియు పాత్ కలయికతో సరిపోల్చబడతాయి, కాబట్టి /v1/portforward మాత్రమే ఉన్న రోల్ GET /v1/portforward ను కవర్ చేయదు.

ప్రతి రీస్టార్ట్ తర్వాత Private Internet Accessలో వేరే పోర్ట్ రావడం. /gluetun ను bind mount చేయండి, తద్వారా సేవ్ చేయబడిన పోర్ట్ స్టేట్ రీస్టార్ట్ తర్వాత కూడా ఉంటుంది. ఆ వాల్యూమ్ లేకపోతే, gluetun ప్రతిసారీ కొత్త పోర్ట్‌ను అడుగుతుంది.

FAQ

నా టొరెంట్స్ డౌన్‌లోడ్ అవుతున్నాయి కానీ ఇన్‌కమింగ్ కనెక్షన్‌లు ఎందుకు రావడం లేదు?

పోర్ట్ ఫార్వర్డింగ్ లేకపోతే, మీ VPN ప్రొవైడర్ వద్ద మీ టన్నెల్‌కు ఏ పోర్ట్ ద్వారా ఇన్‌బౌండ్ ప్యాకెట్లను పంపాలో తెలిపే NAT రూల్ ఉండదు. కాబట్టి మీరు ప్రారంభించని కనెక్షన్‌లు అన్నీ ఎగ్జిట్ అడ్రస్ వద్దే నిలిపివేయబడతాయి. మీ క్లయింట్ స్వయంగా కనెక్షన్‌లను ఓపెన్ చేస్తుంది కాబట్టి డౌన్‌లోడ్‌లు జరుగుతాయి, అలాగే కనెక్ట్ అవ్వగలిగే ఏ పీర్‌నైనా అది చేరుకోగలదు. సీడింగ్ మరియు స్వార్మ్ జాయినింగ్ దెబ్బతింటాయి, ఎందుకంటే ఇవి రెండూ ఇతరులు మిమ్మల్ని చేరుకోవడంపై ఆధారపడి ఉంటాయి. దీనికి పరిష్కారం పోర్ట్ ఫార్వర్డింగ్‌ను అందించే ప్రొవైడర్‌ను ఎంచుకోవడం, gluetun లో VPN_PORT_FORWARDING=on ని ఉపయోగించడం మరియు వచ్చిన పోర్ట్‌ను క్లయింట్ యొక్క లిజనింగ్ పోర్ట్‌కు వర్తింపజేయడం.

ఏదైనా VPN ప్రొవైడర్ పోర్ట్ ఫార్వర్డింగ్‌తో gluetun పనిచేస్తుందా?

లేదు. Gluetun v3.41.3 లో నాలుగు ప్రొవైడర్లకు మాత్రమే నేటివ్ ఇంటిగ్రేషన్ ఉంది: Private Internet Access, ProtonVPN, Perfect Privacy మరియు PrivateVPN. ఆ జాబితాలో లేని దేనికైనా VPN_PORT_FORWARDING_PROVIDER కోసం వాలిడేషన్ విఫలమవుతుంది మరియు కంటైనర్ స్టార్టప్ వద్దే ఆగిపోతుంది. మీ ప్రొవైడర్ వారి కంట్రోల్ ప్యానెల్ ద్వారా స్టాటిక్ పోర్ట్‌ను ఇస్తే, gluetun దానిని మీ కోసం అడగలేదు, కానీ FIREWALL_VPN_INPUT_PORTS ఆ ఫిక్స్‌డ్ పోర్ట్‌ను gluetun ఫైర్‌వాల్ ద్వారా అనుమతిస్తుంది. ప్రొవైడర్ పాలసీలు మారుతుంటాయి, కాబట్టి ప్లాన్ కొనే ముందు ప్రస్తుత ప్రొవైడర్ పేజీని తనిఖీ చేయండి.

ప్రతి రీకనెక్ట్ తర్వాత నేను పోర్ట్‌ను అప్‌డేట్ చేయాలా?

అవును, ఆ అప్‌డేట్ ఆటోమేటిక్‌గా జరగాలి. ఫార్వర్డ్ చేసిన పోర్ట్ VPN సెషన్‌కు చెందుతుంది, కాబట్టి కంటైనర్ రీస్టార్ట్ అయినా, సర్వర్ మారినా లేదా లీజ్ రెన్యూవల్ విఫలమైనా కొత్త నంబర్ రావచ్చు, కానీ క్లయింట్ పాత పోర్ట్‌నే తన కాన్ఫిగరేషన్‌లో ఉంచుకుంటుంది. VPN_PORT_FORWARDING_UP_COMMAND తో gluetun ద్వారా దీన్ని పుష్ చేయనివ్వండి (ఇది ఫార్వర్డింగ్ ప్రారంభమైన వెంటనే రన్ అవుతుంది), లేదా కంట్రోల్ సర్వర్ నుండి GET /v1/portforward ని రీడ్ చేసి, దాని విలువను క్లయింట్ API ద్వారా అప్‌డేట్ చేసే ఒక చిన్న ప్రాసెస్‌ను రన్ చేయండి.

ఫార్వర్డ్ చేసిన పోర్ట్ నిజంగా ఓపెన్ అయిందో లేదో ఎలా తనిఖీ చేయాలి?

gluetun నెట్‌వర్క్ నేమ్‌స్పేస్ లోపల ఆ నిర్దిష్ట పోర్ట్‌పై ఒక లిజనర్‌ను రన్ చేసి, VPN వెలుపల నుండి దానికి కనెక్ట్ అవ్వండి. పోర్ట్ ఖాళీగా ఉండటానికి ముందుగా టొరెంట్ క్లయింట్‌ను ఆపండి, ఆపై gluetun కంటైనర్ లోపల అప్‌స్ట్రీమ్ పోర్ట్-చెకర్ బైనరీని --listening-address=":<port>" తో రన్ చేయండి. curl -s http://127.0.0.1:8000/v1/publicip/ip నుండి ఎగ్జిట్ అడ్రస్‌ను పొందండి మరియు మొబైల్ డేటాలో ఉన్న ఫోన్ నుండి http://<address>:<port> ని ఓపెన్ చేయండి. పోర్ట్-చెకర్ లాగ్‌లో ఒక అభ్యర్థన కనిపిస్తే, ఇన్‌బౌండ్ TCP అందుతోందని అర్థం. టైమ్-అవుట్ వస్తే, క్లయింట్ యొక్క స్టేటస్ ఐకాన్ ఏది చూపించినా, కనెక్షన్ అందడం లేదని అర్థం.