Gluetun-ல் Port Forwarding அமைப்பது எப்படி?

Forwarded port இல்லாமல் ஏன் எந்த இணைப்பும் உள்ளே வருவதில்லை

Gluetun port forwarding, உங்கள் VPN provider-ன் exit address-ல் உள்ள ஒரு public port-ஐ உங்கள் container-க்கு map செய்யுமாறு கோருகிறது. பிற peer-கள் உங்கள் torrent client-க்கு இணைப்பைத் தொடங்க இதுவே ஒரே வழியாகும். இந்த mapping இல்லையென்றால், tunnel சரியாக இயங்கும், downloads நடக்கும், ஆனால் வெளியிலிருந்து எந்த இணைப்பும் உள்ளே வராது. ஒவ்வொரு வெற்றிகரமான இணைப்பும் உங்கள் client முதலில் தொடங்கியதாக மட்டுமே இருக்கும்.

இதன் பின்னணியில் உள்ள நுட்பம் NAT (network address translation) ஆகும். உங்கள் container, provider-ன் exit address-ஐ பல வாடிக்கையாளர்களுடன் பகிர்ந்து கொள்கிறது. உங்கள் client வெளிநோக்கிய இணைப்பைத் தொடங்கும்போது, provider அந்த ஓட்டத்தைப் பதிவு செய்து, பதில்களை உங்கள் tunnel வழியாகத் திருப்பி அனுப்புகிறது. ஒரு அந்நிய peer உள்ளே நுழைய முயற்சிக்கும்போது, அது எந்தப் பதிவு செய்யப்பட்ட ஓட்டத்துடனும் பொருந்தாது. எனவே, அந்த packet exit address-ஐ அடைந்து அங்கேயே நிராகரிக்கப்படும். உங்கள் client, இணைக்கக்கூடிய நிலையில் உள்ள அனைத்து peer-களையும் சென்றடைய முடியும் என்பதால், downloads முடிவடையும், இந்தச் சிக்கல் வெளியே தெரியாது. Seeding-ன் போதுதான் இது வெளிப்படும், ஏனெனில் seeder என்பது மற்றவர்கள் இணைக்கும் ஒரு machine ஆகும்.

திறந்த நிலையில் உள்ள inbound port இரண்டு மாற்றங்களைச் செய்கிறது. நீங்கள் swarm-ல் வேகமாக இணையலாம், ஏனெனில் தாங்களாகவே இணைப்புகளை ஏற்க முடியாத peer-கள் இப்போது உங்களை அடைய முடியும், மேலும் அந்த peer-களுக்கு உங்களால் upload செய்ய முடியும்.

ஏன் பெரும்பாலான VPN நிறுவனங்கள் port forwarding வசதியை வழங்குவதில்லை

பகிரப்பட்ட IP முகவரியில் (shared address) ஒரு forwarded port என்பது அரிதான வளமாகும். ஒரு குறிப்பிட்ட exit IP-ல் ஒரு port எண்ணை ஒரு வாடிக்கையாளருக்காக அந்த நிறுவனம் ஒதுக்குகிறது; அந்த வாடிக்கையாளர் அந்த port-ஐ வைத்துச் செய்யும் அனைத்துச் செயல்களுக்கும் அந்த நிறுவனமே பொறுப்பேற்க வேண்டியுள்ளது. பல பெரிய நிறுவனங்கள் இந்த வசதியை நீக்கிவிட்டன; இதற்குத் துஷ்பிரயோகம் (abuse) தொடர்பான சிக்கல்களே காரணம் என்று கூறுகின்றன. ஆதரவு (support) என்பதை ஒரு சரிபார்ப்புப் பட்டியலாகப் பார்க்காமல், ஒரு வகைப்பாடாகக் கருதுங்கள்: உங்கள் திட்டத்தில் (plan), நீங்கள் தேர்ந்தெடுக்கக்கூடிய server-களில் தற்போது port forwarding வசதி உள்ளதா என்று கேட்டு உறுதிப்படுத்திக் கொள்ளுங்கள்.

port forwarding வசதி இருக்கும் இடங்களில், அந்த port நிலையானதாக இருக்காது (dynamic). அது உங்கள் கணக்கிற்குச் சொந்தமானதல்ல, மாறாக அந்த VPN session-க்கு உரியது. எனவே, ஒவ்வொரு முறை reconnect செய்யும்போதும் அந்த port எண் மாறக்கூடும். Private Internet Access ஒரு signed port-ஐ வழங்குகிறது, அதை gluetun புதுப்பித்துக்கொள்ளும். /gluetun directory-ஐ bind mount செய்வதன் மூலம், restart செய்த பிறகும் அந்த state நீடிக்கும் என்றும், 60 நாட்கள் வரை அதே port-ஐப் பயன்படுத்தலாம் என்றும் அதன் upstream ஆவணங்கள் தெரிவிக்கின்றன. ProtonVPN, NAT-PMP (NAT port mapping protocol) மூலம் ஒரு random port-ஐக் குறுகிய காலத்திற்கு ஒதுக்குகிறது; அதைத் தொடர்ந்து புதுப்பித்துக்கொண்டே இருக்க வேண்டும். இதனால்தான், client-ல் ஒருமுறை port-ஐ அமைப்பது நிரந்தரமாகச் செயல்படுவதில்லை.

எந்தெந்த providers-இடம் gluetun port கோர முடியும்

30 ஜூலை 2026 அன்று வெளியிடப்பட்ட gluetun v3.41.3 பதிப்பின்படி, இதன் native integration நான்கு provider பெயர்களைச் சரிபார்க்கிறது: Private Internet Access, ProtonVPN, Perfect Privacy மற்றும் PrivateVPN. இதை VPN_PORT_FORWARDING=on மூலம் இயக்கலாம், இது இயல்பாகவே off நிலையில் இருக்கும். பழைய வழிகாட்டிகள் PORT_FORWARDING அல்லது PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING-ஐப் பயன்படுத்துகின்றன. இந்த பதிப்பிலும் இவை retro-compatible பெயர்களாகச் செயல்படுகின்றன, ஆனால் இவை விரைவில் நீக்கப்படவுள்ளன.

இரண்டு provider விவரங்கள், கோரிக்கை வெற்றி பெறுமா என்பதைத் தீர்மானிக்கின்றன. ProtonVPN-க்கு கட்டணத் திட்டம் (paid plan) தேவை, மேலும் NAT-PMP இயக்கப்பட்டிருக்க வேண்டும்: நீங்கள் WireGuard configuration-ஐ உருவாக்கும்போது VPN விருப்பங்களின் கீழ் NAT-PMP (Port Forwarding)-ஐ இயக்கவும், அல்லது OpenVPN பயன்படுத்தும்போது உங்கள் username-உடன் +pmp-ஐச் சேர்க்கவும். OpenVPN-ல் Private Internet Access-க்கு PORT_FORWARD_ONLY உள்ளது, இது port forwarding-ஐ ஆதரிக்கும் servers-ஐ மட்டுமே தேர்ந்தெடுக்க அனுமதிக்கிறது; இதனால் இவசதி இல்லாத server-களில் நீங்கள் சிக்க மாட்டீர்கள். WireGuard மற்றும் OpenVPN-ல் port கோரும் முறை மாறுபடும், எனவே நீங்கள் தேர்ந்தெடுக்கும் முன் உங்கள் provider-ன் பக்கத்தைப் படிக்கவும்.

built-in provider-க்கு பதிலாக gluetun ஒரு custom configuration-ல் இயங்கும்போது, gluetun அழைக்க வேண்டிய API-ஐ VPN_PORT_FORWARDING_PROVIDER குறிப்பிடுகிறது. upstream Private Internet Access பக்கம், அந்த variable-ஐ VPN_PORT_FORWARDING_USERNAME மற்றும் VPN_PORT_FORWARDING_PASSWORD ஆகியவற்றுடன் இணைக்கிறது; இவை port கோரிக்கைக்குத் தேவையான account credentials-ஐக் கொண்டுள்ளன.

Docker compose-ல் gluetun port forwarding-ஐ இயக்குதல்

இது ஏற்கனவே VPN tunnel சரியாக இயங்குகிறது என்ற அனுமானத்தில் எழுதப்பட்டுள்ளது. அது இயங்கவில்லை என்றால், முதலில் Docker container traffic-ஐ gluetun வழியாக routing செய்தல் என்பதைச் செய்துவிட்டு, 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

Image tag-ஐ pin செய்யவும். qmcgaw/gluetun:latest என்பது master branch-ஐப் பின்பற்றுகிறது; இதில் port forwarding-ன் உட்புற அமைப்புகள் v4 பதிப்பிற்காக மாற்றப்பட்டு வருகின்றன. எனவே, tag pin செய்யப்படாவிட்டால், அடுத்த docker compose pull-ன் போது செயல்பாட்டில் மாற்றம் ஏற்படலாம். compose secrets-க்கான env file-ஐப் பயன்படுத்தி, private key-ஐ compose file-க்கு வெளியே வைத்திருக்கவும்.

Gluetun forwarded port-ஐ எங்கே எழுதுகிறது

Gluetun, port-ன் மதிப்பை மூன்று இடங்களில் வெளிப்படுத்துகிறது; இவை அனைத்தும் ஒரே மதிப்பையே கொண்டிருக்கும்.

ஒவ்வொரு முறை கையகப்படுத்தும்போதும் (acquisition) அது port-ஐ log செய்கிறது. அந்த வரி 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 என அமையும். இந்தக் கோப்பு ஒரு வரியொன்றுக்கு ஒரு port-ஐக் கொண்டிருக்கும், 0644 பயன்முறையில் எழுதப்படும், மேலும் container-ன் PUID மற்றும் PGID உரிமையாளராக மாற்றப்படும் (chown). Forwarding நிறுத்தப்படும்போது, 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 அந்த port-ஐ VPN interface-ல் உள்ள தனது சொந்த firewall-ல் திறக்கிறது, எனவே native integration அந்த வேலையைச் செய்யும்போது FIREWALL_VPN_INPUT_PORTS தேவையில்லை. அந்த variable மற்றொன்றைக் குறிக்கிறது: gluetun-ஆல் வினவ முடியாத ஒரு provider, அங்கு உங்களுக்கு static port வழங்கப்பட்டிருந்தால், அதை நீங்கள் கைமுறையாக அனுமதிக்க வேண்டும்.

இந்த மூன்றில் ஒன்று நீடித்தது (durable), மற்ற இரண்டும் இல்லை. Upstream ஆவணங்கள் status கோப்பை v4.0.0-ல் deprecated என அடையாளப்படுத்துகின்றன, மேலும் GET /v1/openvpn/portforwarded ஏற்கனவே 301 Moved Permanently-ஐக் கொண்டு பதிலளிக்கிறது, அது /v1/portforward-ஐச் சுட்டிக்காட்டுகிறது. புதிய உருவாக்கங்கள் control server-ஐப் படிக்க வேண்டும்.

ஒவ்வொரு முறை reconnect செய்யும்போதும் client-க்கு ஏன் port-ஐ தெரிவிக்க வேண்டும்

ஒரு torrent client தனது listening port-ஐ அதன் சொந்த configuration-ல் சேமித்து வைத்து, மறுதொடக்கம் (restart) செய்தாலும் அதே எண்ணைத் தக்கவைத்துக் கொள்கிறது. ஆனால், forwarded port என்பது VPN session-ன் ஒரு பண்பாகும். Reconnect செய்த பிறகு, இந்த இரண்டு எண்களும் ஒத்துப்போகாது. இதனால், எந்த service-ம் listen செய்யாத ஒரு port-ஐ provider map செய்கிறது; அதேசமயம் client எந்த mapping-ம் இல்லாத ஒரு port-ல் listen செய்கிறது. Reconnect நிகழ்வுகள் அடிக்கடி நடக்கக்கூடியவை: ஒரு container restart, server மாற்றம், gluetun-ன் health check மூலம் restart செய்யப்படும் dropped tunnel, அல்லது புதுப்பிக்க முடியாத lease போன்றவை இதற்கு காரணமாகலாம். இதன் விளைவாக, நேற்று reachable-ஆக இருந்த setup, இன்று எந்த error-ம் காட்டாமல் அமைதியாக unreachable ஆகிவிடுகிறது.

எனவே, gluetun ஒரு port-ஐப் பெறும் அதே தருணத்தில் அதை apply செய்ய வேண்டும். இதைச் செய்வதற்கு இரண்டு வழிகள் உள்ளன, எந்த process இந்த வேலையைச் செய்கிறது என்பதில் அவை வேறுபடுகின்றன.

விருப்பம் 1: gluetun ஒரு up command மூலம் port-ஐ push செய்தல்

VPN_PORT_FORWARDING_UP_COMMAND என்பது port forwarding செயல்பாட்டுக்கு வரும்போது இயங்கும், VPN_PORT_FORWARDING_DOWN_COMMAND என்பது அது துண்டிக்கப்படும்போது இயங்கும். கட்டளையை இயக்குவதற்கு முன்பு, {{PORT}} (முதல் port), {{PORTS}} (அனைத்து port-களும், கமாவால் பிரிக்கப்பட்டது) மற்றும் {{VPN_INTERFACE}} (tunnel interface பெயர், இயல்பாக tun0) ஆகியவற்றை gluetun மாற்றீடு செய்கிறது. Shell syntax-க்கு ஒரு தெளிவான /bin/sh -c wrapper தேவைப்படுகிறது. இது qBittorrent-க்கான upstream உதாரணம், இது இரண்டு 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 என்பது புதிய port ஆகும். current_network_interface என்பது qBittorrent-ஐ tunnel-உடன் இணைக்கிறது. random_port என்பதை false என அமைப்பது, அடுத்த முறை தொடங்கும் போது qBittorrent தானாகவே ஒரு port-ஐத் தேர்ந்தெடுப்பதைத் தடுக்கிறது. upnp என்பதை false என அமைப்பது, இல்லாத ஒரு router வழியாக port-ஐ map செய்ய முயற்சிப்பதைத் தடுக்கிறது.

இந்த அணுகுமுறைக்கு இரண்டு தேவைகள் உள்ளன. qBittorrent-ன் web UI, gluetun container-க்குள் இருந்து 127.0.0.1:8080-ல் பதிலளிக்க வேண்டும்; client, gluetun-ன் network namespace-ஐப் பகிரும்போது இது தானாகவே நடக்கும். மேலும், Bypass authentication for clients on localhost (bypass_local_auth) செயல்படுத்தப்பட வேண்டும், ஏனெனில் இந்த கட்டளை எந்த நற்சான்றிதழ்களையும் (credentials) அனுப்பாது. இணைப்பு துண்டிக்கப்பட்ட பிறகு qBittorrent எப்போதும் port-ஐ மீண்டும் ஏற்படுத்தாது என்பதால், down கட்டளை அங்கு உள்ளது.

இந்தக் கட்டளை Alpine-ல் கட்டமைக்கப்பட்ட gluetun container-க்குள் இயங்குகிறது மற்றும் இது wget-ஐக் கொண்டுள்ளது. அந்த image-ல் curl இல்லை. அந்த image-ல் இல்லாத ஒரு binary-ஐக் குறிப்பிடும் கட்டளை, forwarding செயல்பாட்டுக்கு வரும் ஒவ்வொரு முறையும் தோல்வியடையும்.

விருப்பம் 2: gluetun-க்கு வெளியே உள்ள ஒரு process port-ஐ வாசித்தல்

மற்றொரு முறையில், gluetun-க்கு அருகில் ஒரு சிறிய process-ஐ இயக்கி, அது port-ஐப் பெற்று, client-ன் சொந்த API மூலம் அதை உள்ளே செலுத்தும். இதை control server-லிருந்து வாசிக்கவும்:

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

அல்லது, அந்த process-ஆல் கோப்பை அணுக முடிந்தால், அதை வாசிக்கவும். /tmp/gluetun/forwarded_port ஆனது gluetun container-க்குள் இருப்பதால், ஒரு sidecar-க்கு /tmp/gluetun-ல் பகிரப்பட்ட volume mount செய்யப்பட வேண்டும், அல்லது நீங்கள் ஏற்கனவே mount செய்துள்ள volume-ன் கீழ் உள்ள ஒரு பாதைக்கு VPN_PORT_FORWARDING_STATUS_FILE-ஐச் சுட்டிக்காட்ட வேண்டும்.

இங்கு அங்கீகாரம் (Authentication) முக்கியமானது. v3.41.3 பதிப்பில், GET /v1/portforward route ஆனது auth = "none" உடன் public என்ற default role-க்கு உரியது. எனவே, இது credentials இல்லாமலேயே பதிலளிக்கும், மேலும் gluetun route GET /v1/portforward is unprotected by default, please set up authentication என்று தொடங்கும் எச்சரிக்கையை logs-ல் காட்டும். பிற்கால release-களில் இந்த வசதியை upstream நிறுவனம் நீக்கி வருகிறது. எனவே, /gluetun/auth/config.toml-ல் bind mount செய்யப்பட்ட கோப்பில் இப்போதே ஒரு 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 செய்ய விரும்பாதபோது, JSON-encoded environment variable செய்யும் அதே வேலையை HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE செய்கிறது. Role இல்லாமல் port 8000-ஐ வெளியிடுவது, அதை அணுகக்கூடிய எவருக்கும் VPN நிலையை மாற்றும் அதிகாரத்தை அளிக்கும். எனவே, host மற்றும் பிற container-களிலிருந்து gluetun-ஐ எவ்வாறு அணுகுவது என்பதைத் தீர்மானிக்கும்போது, அதன் அணுகல் வரம்பை கவனமாக முடிவு செய்யவும்.

Client ஒரு API-ஐ வெளிப்படுத்தும்போது up command-ஐத் தேர்ந்தெடுக்கவும், அதை ஒரு wget call மூலம் இயக்க முடியும். ஏனெனில் இது ஒவ்வொரு நிகழ்விற்கும் சரியாக ஒருமுறை மட்டுமே இயங்கும் மற்றும் பின்னணியில் எதையும் இயக்க வேண்டியதில்லை. Client-க்கு login flow, config கோப்பை மீண்டும் எழுதுதல் அல்லது restart தேவைப்படும்போது ஒரு external process-ஐத் தேர்ந்தெடுக்கவும். ஒரு gluetun container-க்கு பின்னால் உள்ள arr stack-ல், torrent client-க்கு மட்டுமே port தேவைப்படுவதால், இது பொதுவாக ஒரு சிறிய poller-ஆகவே முடிவடையும்.

பொறி: namespace-ஐப் பகிர்வது listening port-ஐ அமைக்காது

இந்தத் தவறுதான் அதிக நேரத்தை வீணடிக்கிறது. network_mode: "service:gluetun", client-ஐ gluetun-ன் network namespace-க்குள் வைக்கிறது; இதனால் அது VPN முகவரி, tunnel routes மற்றும் gluetun-ன் firewall விதிகளைப் பெறுகிறது. இது எதவும் client-ன் listening port-ஐ அமைப்பதில்லை. Gluetun, VPN interface-ல் forwarded port-ஐத் திறக்கிறது; அதற்கான packets namespace-க்கு வந்து சேரும். ஆனால், client வேறொரு port-ல் listen செய்தால், kernel-ஆல் அவற்றை எதற்கும் அனுப்ப முடியாது. அனைத்து outbound சோதனைகளும் சரியாகத் தெரிந்தாலும், இணைப்பு மறுக்கப்படும் அல்லது காலாவதியாகும் (timeout). Forwarded port மற்றும் client-ன் 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]*'

மற்றொரு அமைப்பு (setting) பயனர்களைத் தவறான திசையில் அழைத்துச் செல்கிறது. VPN_PORT_FORWARDING_LISTENING_PORT, iptables-ஐப் பயன்படுத்தி inbound traffic-ஐ forwarded port-லிருந்து ஒரு நிலையான local port-க்கு மாற்றுகிறது. Torrent client-களுடன் இதைப் பயன்படுத்த வேண்டாம் என்று upstream அறிவுறுத்துகிறது; ஏனெனில், client தனது சொந்த listening port-ஐ trackers மற்றும் peers-க்கு அறிவிக்கும், இதனால் swarm தவறான எண்ணைப் பெற்றுவிடும்.

Forwarded port அணுகக்கூடியது என்பதை உறுதிப்படுத்துவது எப்படி

Client-ன் சொந்த இணைப்பு காட்டி (connection indicator) வெளிச்செல்லும் tracker இணைப்புகளை மட்டுமே குறிக்கும், எனவே உங்களை யாராலும் அணுக முடியாத நிலையிலும் அது பச்சை நிறத்தில் காட்டப்படலாம். உங்கள் கட்டுப்பாட்டில் உள்ள ஒரு listener-ஐப் பயன்படுத்தி, tunnel-க்கு வெளியே உள்ள ஒரு network-லிருந்து இதைச் சோதிக்கவும். இதற்காக Upstream ஒரு சிறிய கருவியை வழங்குகிறது. முதலில் torrent client-ஐ நிறுத்தவும், ஏனெனில் ஒரே port-ஐ இரண்டு process-கள் பயன்படுத்த முடியாது.

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

Container-க்குள், உங்கள் CPU architecture-க்கு ஏற்ப amd64-ஐயும், நீங்கள் forward செய்த 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-ஐக் கண்டறியவும். பதில் JSON வடிவில் இருக்கும், அந்த முகவரி public_ip என்ற field-ல் இருக்கும்.

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

அதே VPN-ல் இல்லாத ஒரு சாதனத்திலிருந்து http://<that address>:4567-ஐத் திறக்கவும். Mobile data-வில் உள்ள ஒரு phone இதற்குச் சரியாக இருக்கும். உங்கள் browser-ன் IP முகவரி மற்றும் user agent-ஐக் காட்டும் ஒரு பக்கம், port-checker மூலம் பதிவு செய்யப்பட்ட கோரிக்கையுடன் ஒத்துப்போனால், inbound TCP namespace-ஐ அடைகிறது என்று அர்த்தம். Timeout ஏற்பட்டால், அது அந்த port-ஐ அடையவில்லை என்று பொருள்; இதற்கான காரணம் client-க்கு மேலே உள்ள அமைப்பில் உள்ளது. CTRL+C மூலம் கருவியை நிறுத்தவும், exit மூலம் shell-லிருந்து வெளியேறவும், பின்னர் client-ஐ மீண்டும் தொடங்கவும். இந்தச் சோதனை TCP-ஐ மட்டுமே சரிபார்க்கும். DHT (distributed hash table) மற்றும் uTP traffic ஆகியவை அதே port எண்ணில் UDP-ஐப் பயன்படுத்துகின்றன, அவற்றை இந்தச் சோதனை உள்ளடக்குவதில்லை.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் சரங்கள் (strings)

பதிவில் (log) port வரி எதுவுமே இல்லை. எந்தவொரு செயலியும் port-ஐக் கோரவில்லை. docker exec gluetun printenv | grep PORT_FORWARDING மூலம் அந்த variable container-க்குச் சென்றதை உறுதிப்படுத்தவும், ஏனெனில் தவறான compose service-ல் variable-ஐ அமைப்பது பொதுவான காரணமாகும்.

Gluetun தொடங்க மறுத்து, provider குறித்து புகார் அளிக்கிறது. VPN_PORT_FORWARDING_PROVIDER நான்கு ஆதரவு பெற்ற பெயர்களுடன் சரிபார்க்கப்படுகிறது, எனவே ஒரு எழுத்துப் பிழை (typo) ஏற்பட்டால், forwarding இல்லாமல் அமைதியாக இயங்குவதற்குப் பதிலாக container நின்றுவிடும்.

பதிவில் no port forwarded என்று உள்ளது. Gluetun கோரியது, ஆனால் provider எதையும் வழங்கவில்லை. ProtonVPN-ல், நீங்கள் உருவாக்கிய configuration-ல் NAT-PMP செயல்படுத்தப்படவில்லை அல்லது உங்கள் திட்டத்தில் (plan) forwarding வசதி இல்லை என்று அர்த்தம். Private Internet Access-ல், தேர்ந்தெடுக்கப்பட்ட server அந்த வசதியை வழங்கவில்லை என்று அர்த்தம்.

Port கிடைக்கிறது, ஆனால் எதுவும் இணைக்கப்படவில்லை. மேலே உள்ள இரண்டு கட்டளைகளைப் பயன்படுத்தி, forwarded port-ஐ client-ன் listening port-உடன் ஒப்பிடவும். அவை பொருந்தினால், client tunnel interface-உடன் பிணைக்கப்பட்டுள்ளதா (bound) மற்றும் அதன் random-port விருப்பம் முடக்கப்பட்டுள்ளதா என்பதைச் சரிபார்க்கவும், ஏனெனில் அந்த விருப்பம் ஒவ்வொரு தொடக்கத்திலும் listening port-ஐ மாற்றிவிடும்.

up கட்டளை எதையும் செய்யாதது போல் உள்ளது. பிழையைக் காண container-க்குள் அந்தத் துல்லியமான கட்டளையை இயக்கவும்: docker exec gluetun /bin/sh -c '<your command>'. curl: not found என்பது வழக்கமான முடிவாகும், ஏனெனில் அந்த image wget-ஐ மட்டுமே கொண்டுள்ளது.

Control server-லிருந்து 401 Unauthorized. நீங்கள் ஒரு auth config-ஐ வரையறுத்துள்ளீர்கள், ஆனால் நீங்கள் அழைக்கும் route அந்த role-ல் பட்டியலிடப்படவில்லை. Routes என்பது method மற்றும் path ஆகியவற்றின் சேர்க்கையாகப் பொருந்தும், எனவே /v1/portforward-ஐ மட்டும் கொண்ட ஒரு role, GET /v1/portforward-க்கு பொருந்தாது.

ஒவ்வொரு மறுதொடக்கத்திற்குப் பிறகும் Private Internet Access-ல் வெவ்வேறு port கிடைக்கிறது. /gluetun-ஐ bind mount செய்யவும், அப்போதுதான் சேமிக்கப்பட்ட port நிலை மறுதொடக்கத்திற்குப் பிறகும் நீடிக்கும். அந்த volume இல்லையென்றால், gluetun ஒவ்வொரு முறையும் புதிய port-ஐக் கோரும்.

FAQ

எனது torrent-கள் பதிவிறக்கம் ஆகின்றன, ஆனால் உள்வரும் இணைப்புகள் (incoming connections) ஏன் கிடைப்பதில்லை?

Port forwarding செய்யப்படாத நிலையில், உங்கள் VPN provider எந்தவொரு port-லும் உள்வரும் பாக்கெட்டுகளை உங்கள் tunnel-க்கு அனுப்பும் NAT விதியைக் கொண்டிருக்காது. எனவே, நீங்கள் தொடங்காத இணைப்புகள் exit address-லேயே நிராகரிக்கப்படும். உங்கள் client தானாகவே இணைப்புகளைத் தொடங்குவதால் பதிவிறக்கங்கள் வேலை செய்யும்; இணைக்கக்கூடிய எந்தவொரு peer-ஐயும் உங்களால் அடைய முடியும். Seeding மற்றும் swarm இணைப்புகள் பாதிக்கப்படும், ஏனெனில் இவை இரண்டும் மற்றவர்கள் உங்களை அடைவதைச் சார்ந்தே உள்ளன. Port forwarding வசதி கொண்ட ஒரு provider-ஐத் தேர்ந்தெடுப்பது, VPN_PORT_FORWARDING=on-ஐ gluetun-ல் பயன்படுத்துவது மற்றும் அந்த port-ஐ client-ன் listening port-ஆக அமைப்பதுதான் இதற்கான தீர்வு.

எந்தவொரு VPN provider-ன் port forwarding வசதியுடனும் gluetun வேலை செய்யுமா?

இல்லை. Gluetun v3.41.3-ல் நான்கு provider-களுக்கான native integration உள்ளது: Private Internet Access, ProtonVPN, Perfect Privacy மற்றும் PrivateVPN. அந்தப் பட்டியலுக்கு வெளியே உள்ள எதுவும் VPN_PORT_FORWARDING_PROVIDER-க்கான சரிபார்ப்பில் தோல்வியடையும், மேலும் container தொடக்கத்திலேயே நின்றுவிடும். உங்கள் provider அதன் control panel மூலம் static port-ஐ வழங்கினால், gluetun-ஆல் அதை உங்களுக்காகக் கோர முடியாது, ஆனால் FIREWALL_VPN_INPUT_PORTS அந்த நிலையான port-ஐ gluetun-ன் firewall வழியாக அனுமதிக்க உதவும். Provider-களின் கொள்கைகள் மாறக்கூடும் என்பதால், இதற்காக ஒரு திட்டத்தை வாங்குவதற்கு முன் தற்போதைய provider பக்கத்தைச் சரிபார்க்கவும்.

ஒவ்வொரு முறை reconnect செய்த பிறகும் நான் port-ஐ update செய்ய வேண்டுமா?

ஆம், அந்த update தானாகவே நடக்க வேண்டும். Forwarded port என்பது VPN session-க்கு உரியது. எனவே, container restart, server மாற்றம் அல்லது lease புதுப்பித்தல் தோல்வி போன்றவை புதிய எண்ணை உருவாக்கலாம், ஆனால் client பழைய port-ஐயே அதன் configuration-ல் வைத்திருக்கும். VPN_PORT_FORWARDING_UP_COMMAND மூலம் gluetun-ஐ இதைப் புதுப்பிக்க அனுமதிக்கலாம் (இது forwarding கிடைத்தவுடன் இயங்கும்), அல்லது control server-லிருந்து GET /v1/portforward-ஐப் படித்து, அதன் API மூலம் client-ல் அந்த மதிப்பை எழுதும் ஒரு சிறிய process-ஐ இயக்கலாம்.

Forwarded port உண்மையில் திறந்திருக்கிறதா என்பதை நான் எப்படிச் சரிபார்ப்பது?

Gluetun-ன் network namespace-க்குள் அந்தத் துல்லியமான port-ல் ஒரு listener-ஐ இயக்கி, VPN-க்கு வெளியிலிருந்து அதனுடன் இணையவும். Port காலியாக இருக்க முதலில் torrent client-ஐ நிறுத்தவும், பின்னர் --listening-address=":<port>"-ஐப் பயன்படுத்தி gluetun container-க்குள் upstream port-checker binary-ஐ இயக்கவும். curl -s http://127.0.0.1:8000/v1/publicip/ip-லிருந்து exit address-ஐப் பெற்று, மொபைல் டேட்டாவில் உள்ள போனில் http://<address>:<port>-ஐத் திறக்கவும். Port-checker log-ல் ஒரு கோரிக்கை (request) தோன்றினால், உள்வரும் TCP பாக்கெட்டுகள் வந்து சேருகின்றன என்று அர்த்தம். Timeout ஏற்பட்டால், client-ன் status icon என்ன காட்டினாலும், இணைப்பு வரவில்லை என்று பொருள்.