Docker కంటైనర్లను VPN ద్వారా రూట్ చేయడం ఎలా?

Docker కంటైనర్లను VPN ద్వారా రూట్ చేసినప్పుడు పోర్టులు ఎందుకు కనిపించవు

Docker కంటైనర్లను VPN ద్వారా రూట్ చేయడానికి, ఒక కంటైనర్‌కు టన్నెల్‌ను కేటాయించి, మిగిలిన వాటిని network_mode: "service:gluetun" తో దాని నెట్‌వర్క్ నేమ్‌స్పేస్‌కు అనుసంధానించాలి. ఈ అనుసంధానమే చాలామందిని ఆశ్చర్యపరిచే అంశం. అనుసంధానించబడిన కంటైనర్‌కు ఇకపై సొంత నెట్‌వర్క్ ఉండదు, కాబట్టి దాని పబ్లిష్ చేసిన పోర్టులు మరియు దాని Docker సర్వీస్ పేరు కూడా తొలగిపోతాయి. దానికి బదులుగా VPN కంటైనర్‌పై పోర్టులను పబ్లిష్ చేయండి, అప్పుడు ఇతర కంటైనర్లు ఆ అప్లికేషన్‌ను VPN కంటైనర్ పేరుతో చేరుకోగలవు.

అనుసంధానించబడిన కంటైనర్‌పై ports: బ్లాక్‌ను అలాగే ఉంచితే, Docker దానిని సృష్టించడానికి నిరాకరిస్తుంది:

Error response from daemon: conflicting options: port publishing and the container type network mode

దీని కోసం ఉపయోగించే సాధనం Gluetun, ఇది WireGuard లేదా OpenVPN ద్వారా కమర్షియల్ VPN (virtual private network) ప్రొవైడర్‌కు కనెక్ట్ అయ్యే మరియు సొంత ఫైర్‌వాల్‌ను కలిగి ఉండే కంటైనర్. ఆగస్టు 2026 నాటికి v3.41.3 రిలీజ్ ప్రస్తుత వెర్షన్. ఈ ఉదాహరణలు Mullvad మరియు WireGuard ఉపయోగిస్తాయి, కాబట్టి మీకు మీ ప్రొవైడర్ నుండి ఒక అకౌంట్ మరియు కీ అవసరం. ఒకవేళ మీరు సొంత హార్డ్‌వేర్‌పై టన్నెల్‌ను టెర్మినేట్ చేయాలనుకుంటే, మీ స్వంత WireGuard సర్వర్‌ను VPSలో రన్ చేయడం ద్వారా అవతలి వైపున సెటప్ చేయవచ్చు, మరియు Dockerలో wg-easy దానిని వెబ్ ఇంటర్‌ఫేస్‌తో సులభతరం చేస్తుంది.

network_mode: "service:gluetun" వాస్తవానికి ఏమి చేస్తుంది

ప్రతి Docker container సాధారణంగా తన సొంత network namespace ను కలిగి ఉంటుంది: అంటే దాని సొంత interfaces, routing table, firewall rules మరియు listening sockets ఉంటాయి. service: mode ఆ దశను దాటవేసి, gluetun యొక్క namespace లోపల container ను ప్రారంభిస్తుంది. ఒకే namespace అంటే ఒకే IP address అని అర్థం, ఇది ఆరు విషయాలను మారుస్తుంది.

• అప్లికేషన్‌కు దాని సొంత address ఉండదు. దాని address gluetun యొక్క address అవుతుంది.
• అప్లికేషన్ ఏ Docker network కు అనుసంధానించబడదు, కాబట్టి దాని service name ఎప్పటికీ register అవ్వదు మరియు resolve అవ్వదు. ఇతర containers తప్పనిసరిగా gluetun ను ఉపయోగించాలి.
• namespace లోపల ఉన్న containers ఒకదానికొకటి localhost ద్వారా చేరుకుంటాయి.
• ఒకే namespace లో ఉన్న రెండు containers ఒకే port పై వినలేవు (listen అవ్వలేవు). Gluetun డాక్యుమెంటేషన్ దీని గురించి స్పష్టంగా చెబుతోంది: దీనికి ఎటువంటి ప్రత్యామ్నాయం లేదు.
• Capabilities అనేవి ఒక container కు చెందుతాయి, namespace కు కాదు. Gluetun tunnel interface ను సృష్టిస్తుంది కాబట్టి, అది NET_ADMIN మరియు /dev/net/tun లను కలిగి ఉంటుంది. అనుసంధానించబడిన container వాటిని వారసత్వంగా పొందదు.
• ఒక service network_mode మరియు networks రెండింటినీ సెట్ చేసే ఫైల్‌ను Compose తిరస్కరిస్తుంది. Gluetun ను మీ networks కు అనుసంధానించండి, అప్పుడు అప్లికేషన్ దానితో పాటు పనిచేస్తుంది.

Gluetun ను restart చేయడం వల్ల దానికి అనుసంధానించబడినవన్నీ డిస్‌కనెక్ట్ అవుతాయి. ఇది డాక్యుమెంట్ చేయబడిన ప్రవర్తన, మరియు కనెక్షన్ విఫలమైనప్పుడు gluetun బయటకు వచ్చేయకుండా, container లోపల VPN ప్రాసెస్‌ను restart చేయడానికి ఇదే కారణం. మీరు gluetun ను స్వయంగా restart చేసినా లేదా మళ్ళీ సృష్టించినా, దానికి అనుసంధానించబడిన containers ను కూడా restart చేయండి.

పనిచేసే compose ఫైల్

services:
  gluetun:
    image: qmcgaw/gluetun:v3
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - SERVER_CITIES=Amsterdam
      - TZ=Europe/Amsterdam
    env_file:
      - ./gluetun.env
    volumes:
      - ./gluetun:/gluetun
    ports:
      - 127.0.0.1:8080:8080/tcp
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent:/config
      - ./downloads:/downloads
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

:v3 ట్యాగ్ v3 సిరీస్‌లో అత్యంత కొత్త స్థిరమైన (stable) విడుదల. :latest ట్యాగ్ మాస్టర్ బ్రాంచ్ యొక్క చివరి కమిట్‌ను సూచిస్తుంది, ఇది అభివృద్ధి దశలో ఉన్న వెర్షన్. కాబట్టి, మీరు మంగళవారం నాడు డీబగ్గింగ్ చేయకూడదనుకునే మెషీన్‌పై :v3 ని పిన్ (pin) చేయండి.

WEBUI_PORT=8080 పబ్లిష్ చేసిన పోర్ట్‌తో సరిపోలాలి, ఎందుకంటే qBittorrent అనేది gluetun యొక్క నేమ్‌స్పేస్ లోపల బైండ్ అవుతుంది మరియు పబ్లిష్ రూల్ హోస్ట్ ట్రాఫిక్‌ను అక్కడి 8080 పోర్ట్‌కు పంపుతుంది. ఒక నంబర్‌ను మార్చి మరొకటి మార్చకపోతే, ఆ పోర్ట్ ఏ సమాధానం ఇవ్వదు. 127.0.0.1:8080:8080 వెబ్ ఇంటర్‌ఫేస్‌ను హోస్ట్ లూప్‌బ్యాక్ అడ్రస్‌పై ఉంచుతుంది. కేవలం 8080:8080 అని ఇస్తే అది ప్రతి ఇంటర్‌ఫేస్‌పై పబ్లిష్ అవుతుంది మరియు దాని సొంత ఫైర్‌వాల్ రూల్‌ను రాస్తుంది, Docker పబ్లిష్ చేసిన పోర్ట్‌లు ufw ను ఎలా దాటి వెళ్తాయో ఇది చూపిస్తుంది.

దీనిని ప్రారంభించి, ఈ క్రమంలో తనిఖీ చేయండి:

docker compose up -d
docker compose ps
docker compose logs gluetun | tail -30

docker compose ps కమాండ్ gluetun ను healthy గా మరియు qbittorrent ను running గా చూపాలి. ఆ తర్వాత నేమ్‌స్పేస్ లోపల నుండి ఎగ్జిట్ అడ్రస్‌ను నిర్ధారించుకోండి, మిగిలినవన్నీ దీనిపైనే ఆధారపడి ఉంటాయి:

docker run --rm --network=container:gluetun alpine:3.22 sh -c "apk add wget && wget -qO- https://ipinfo.io"

ఆ JSON లోని ip ఫీల్డ్ మీ VPN ప్రొవైడర్ అడ్రస్‌ను కలిగి ఉండాలి. ఒకవేళ అది మీ సర్వర్ యొక్క సొంత అడ్రస్ అయితే, అప్లికేషన్ టన్నెల్ లోపల లేదు అని అర్థం, అప్పుడు కింద పేర్కొన్న ఏదీ వివరించినట్లుగా పనిచేయదు.

Compose ఫైల్‌లో కీలను ఉంచవద్దు

gluetun.env క్రెడెన్షియల్స్‌ను కలిగి ఉంటుంది, ఇది git లో ఉండకూడదు:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

ఈ రెండు విలువలు మీ ప్రొవైడర్ ఖాతా ప్రాంతంలో మీరు రూపొందించే WireGuard కాన్ఫిగరేషన్ ఫైల్ నుండి వస్తాయి. ఈ ఫైల్‌ను 600 మోడ్‌కు సెట్ చేయండి. దీనివల్ల కలిగే ప్రయోజనం గురించి స్పష్టంగా ఉండండి: కీ మీ రిపోజిటరీలో ఉండదు, కానీ Docker socket ను యాక్సెస్ చేయగల ఎవరైనా docker inspect gluetun ద్వారా ప్రతి environment variable ను చూడగలరు. Docker Compose లో environment ఫైళ్లు మరియు secrets మరింత మెరుగైన పద్ధతులను వివరిస్తుంది.

టన్నెల్ వెలుపల ఉన్న కంటైనర్ లోపల ఉన్న దానితో ఎలా మాట్లాడుతుంది

రెండు దిశలలోనూ కమ్యూనికేషన్ సాధ్యమవుతుంది, ప్రతిదానికి వేర్వేరు పేర్లు ఉపయోగిస్తారు. ఈ రెండు కంటైనర్లకు ఒకే Docker network అవసరం. అంటే, అనుసంధానించబడిన కంటైనర్‌కు సొంత నెట్‌వర్క్ ఏదీ ఉండదు కాబట్టి, అది gluetun యొక్క నెట్‌వర్క్‌ను ఉపయోగిస్తుంది. Docker Compose నెట్‌వర్క్‌లు ఎలా అనుసంధానించబడతాయి అనే విభాగం డిఫాల్ట్ సెట్టింగ్‌ల గురించి వివరిస్తుంది.

బయటి నుండి లోపలికి కమ్యూనికేట్ చేయడానికి, gluetun పేరును మరియు అప్లికేషన్ వినే (listen) పోర్ట్‌ను ఉపయోగించండి. ఒక రివర్స్ ప్రాక్సీ కంటైనర్ qBittorrent వెబ్ ఇంటర్‌ఫేస్‌ను gluetun:8080 ద్వారా చేరుకుంటుంది. దీని కోసం ఎటువంటి ports: ఎంట్రీ అవసరం లేదు, ఎందుకంటే కంటైనర్-టు-కంటైనర్ ట్రాఫిక్ Docker నెట్‌వర్క్‌లోనే ఉంటుంది మరియు హోస్ట్ పోర్ట్‌ను తాకదు.

లోపలి నుండి బయటికి కమ్యూనికేట్ చేయడానికి, ఇతర కంటైనర్ యొక్క సర్వీస్ పేరును ఉపయోగించండి, ఉదాహరణకు postgres:5432. v3.41 నుండి gluetun తన నేమ్‌స్పేస్ లోపల నుండి ఇతర కంటైనర్ పేర్లను రిజాల్వ్ చేస్తోంది, కాబట్టి పేరు రిజాల్వ్ కాకపోతే ఆ వెర్షన్‌ను లేదా అంతకంటే కొత్త వెర్షన్‌ను పిన్ చేయండి.

gluetun యొక్క ఫైర్‌వాల్ ఎవరిని కనెక్షన్ తెరవడానికి అనుమతించాలో నిర్ణయిస్తుంది. gluetun యొక్క సొంత Docker నెట్‌వర్క్ నుండి వచ్చే ట్రాఫిక్ అనుమతించబడుతుంది. వేరే సబ్‌నెట్‌లో ఉన్న క్లయింట్, మీ LAN లో ఉన్న ల్యాప్‌టాప్ లేదా వేరే బ్రిడ్జ్ నెట్‌వర్క్‌లో ఉన్న కంటైనర్ నుండి వచ్చే ట్రాఫిక్, మీరు ఆ సబ్‌నెట్‌ను పేర్కొనే వరకు నిలిపివేయబడుతుంది:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

డాక్యుమెంటేషన్‌లో ఉన్న అర్థం ఖచ్చితమైనది: కామాతో వేరు చేయబడిన సబ్‌నెట్‌లు, వీటిని gluetun మరియు దాని నెట్‌వర్క్ స్టాక్‌ను పంచుకునే కంటైనర్లు యాక్సెస్ చేయడానికి అనుమతించబడతాయి.

ఇంటర్నెట్ నుండి వచ్చే ఇన్‌బౌండ్ కనెక్షన్‌లు వేరే సమస్య. టొరెంట్ క్లయింట్ యొక్క పీర్స్ (peers) VPN వైపు నుండి వస్తాయి, కాబట్టి హోస్ట్‌పై 6881 పోర్ట్‌ను పబ్లిష్ చేయడం వల్ల వాటికి ఎటువంటి ఉపయోగం ఉండదు. మీకు మీ ప్రొవైడర్ నుండి ఫార్వర్డ్ చేయబడిన పోర్ట్ అవసరం, మరియు ఆ పోర్ట్ FIREWALL_VPN_INPUT_PORTS లో జాబితా చేయబడాలి, ఇది VPN సర్వర్ వైపు నుండి పోర్ట్‌లను అనుమతిస్తుంది. Docker Compose తో నిర్మించిన మీడియా స్టాక్‌లలో చాలా వరకు ఈ భాగాన్నే సరిగ్గా కాన్ఫిగర్ చేయరు.

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

ఈ పద్ధతి వైఫల్యం చెందినప్పుడు దాని సంక్లిష్టతను సమర్థించుకుంటుంది. అనుసంధానించబడిన కంటైనర్‌కు రెండవ రూట్ ఉండదు. అది షేర్ చేసుకున్న నేమ్‌స్పేస్ మాత్రమే దాని ఏకైక మార్గం, కాబట్టి టన్నెల్ డౌన్ అయినప్పుడు దానికి వేరే ప్రత్యామ్నాయం ఉండదు. Gluetun ఫైర్‌వాల్ అవతలి వైపు నుండి కూడా అదే నియమాన్ని అమలు చేస్తుంది: అవుట్‌బౌండ్ ట్రాఫిక్ టన్నెల్ ద్వారా లేదా VPN సర్వర్ ఎండ్‌పాయింట్‌కు వెళ్లాలి, మిగిలినవన్నీ నిలిపివేయబడతాయి. క్లయింట్ మళ్లీ కనెక్ట్ అయ్యే సమయంలో ప్యాకెట్లు సాధారణ ఇంటర్‌ఫేస్ ద్వారా బయటకు లీక్ అయ్యే అవకాశం ఉండదు.

Gluetun తన సొంత కనెక్షన్‌ను పర్యవేక్షిస్తుంది. ప్రతి నిమిషం ఇది HEALTH_ICMP_TARGET_IPS లోని అడ్రస్‌లకు ICMP ఎకో (పింగ్) పంపుతుంది, ఇవి డిఫాల్ట్‌గా 1.1.1.1,8.8.8.8 గా ఉంటాయి. ప్రతి ఐదు నిమిషాలకు ఇది HEALTH_TARGET_ADDRESSES కి పూర్తి TCP మరియు TLS (ట్రాన్స్‌పోర్ట్ లేయర్ సెక్యూరిటీ) డయల్ చేస్తుంది, ఇది డిఫాల్ట్‌గా cloudflare.com:443,github.com:443. అవి విఫలమైనప్పుడు, ఇది కంటైనర్ లోపల VPNని రీస్టార్ట్ చేసి లాగ్ చేస్తుంది:

WARN [vpn] restarting VPN because it failed to pass the healthcheck: periodic check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout

ఈ క్రమాన్ని దృష్టిలో ఉంచుకుని అనుసంధానించబడిన కంటైనర్ లాగ్‌లను చదవండి. యాప్ లోపల connection refused, operation not permitted మరియు i/o timeout వంటి లైన్లు టన్నెల్ ఆగిపోవడం వల్ల కలిగే పరిణామాలు, కారణాలు కావు. Gluetun డాక్యుమెంటేషన్ దీనిని స్పష్టంగా పేర్కొంది, ఎందుకంటే వినియోగదారులు పరిణామాన్ని చూసి దాని కోసం గంటల తరబడి వెతుకుతుంటారు.

HEALTH_RESTART_VPN=on అనేది డిఫాల్ట్ సెట్టింగ్ మరియు ఇది ఆన్‌లోనే ఉండాలి. ఏదైనా నిర్దిష్ట వైఫల్యాన్ని డీబగ్ చేస్తున్నప్పుడు మాత్రమే దీనిని ఆఫ్ చేయండి, ఎందుకంటే ఇది ఆఫ్ చేయబడితే, ఆగిపోయిన టన్నెల్ మళ్లీ పునరుద్ధరించబడదు.

క్రమబద్ధీకరణ: టన్నెల్ సిద్ధం కాకముందే స్టాక్ ప్రారంభం కాకుండా ఆపడం

ఈ ఇమేజ్ ఒక Docker healthcheck ను కలిగి ఉంటుంది:

HEALTHCHECK --interval=5s --timeout=5s --start-period=10s --retries=1 CMD /gluetun-entrypoint healthcheck

ఆ కమాండ్ gluetun యొక్క రెండవ, స్వల్పకాలిక కాపీని రన్ చేస్తుంది. ఇది రన్ అవుతున్న gluetun యొక్క హెల్త్ సర్వర్‌ను http://127.0.0.1:9999/ వద్ద క్వెరీ చేస్తుంది. సరిగ్గా పనిచేస్తున్న టన్నెల్ 200 OK అని సమాధానం ఇస్తుంది. విఫలమైన టన్నెల్ ఒక ఎర్రర్ స్ట్రింగ్‌తో 500 Internal server error అని సమాధానం ఇస్తుంది, మరియు ఒకే ఒక్క వైఫల్యంతో కంటైనర్ unhealthy గా గుర్తించబడుతుంది.

condition: service_healthy అనేది దాని కోసం వేచి ఉంటుంది. సాధారణ depends_on: [gluetun] కేవలం కంటైనర్ ప్రారంభం కావడానికి మాత్రమే వేచి ఉంటుంది. ఇది హ్యాండ్‌షేక్ పూర్తి కావడానికి కొన్ని సెకన్ల ముందే జరుగుతుంది, కాబట్టి అప్లికేషన్ నెట్‌వర్క్ లేని స్థితిలో ప్రారంభమై, తరచుగా తన మొదటి కనెక్షన్ ప్రయత్నాన్ని విరమించుకుంటుంది. Docker Compose లో హెల్త్‌చెక్స్ సింటాక్స్ మరియు టైమింగ్ ఫీల్డ్స్ గురించి వివరిస్తుంది.

ఒక పరిమితి వినియోగదారులను ఇబ్బంది పెడుతుంది. కంటైనర్‌ను సృష్టించేటప్పుడు Compose ఆ కండిషన్‌ను ఒక్కసారి మాత్రమే అంచనా వేస్తుంది. gluetun అన్‌హెల్తీగా మారితే, అది అప్లికేషన్‌ను ఆపదు లేదా రీస్టార్ట్ చేయదు. దానికి బదులుగా gluetun యొక్క అంతర్గత ఆటో-హీలింగ్ ఆ పరిస్థితిని చక్కదిద్దుతుంది, అందుకే ఇది కంటైనర్‌ను కాకుండా VPN ప్రాసెస్‌ను రీస్టార్ట్ చేస్తుంది.

సెటప్‌ను నమ్మే ముందు DNS లీక్ ఉందేమో తనిఖీ చేయండి

DNS (domain name system) అనేది సరైన టన్నెల్ ఉన్నప్పటికీ లీక్ అయ్యే అవకాశం ఉన్న అంశం. Gluetun తన సొంత రిజాల్వర్‌ను నేమ్‌స్పేస్ లోపల నడుపుతుంది మరియు డిఫాల్ట్‌గా DoT (DNS over TLS) ద్వారా Cloudflare కి క్వెరీలను ఫార్వర్డ్ చేస్తుంది: DNS_UPSTREAM_RESOLVER_TYPE=dot మరియు DNS_UPSTREAM_RESOLVERS=cloudflare. వీటిని మార్చకుండా ఉంచితే, మీ లుకప్‌లు ఎన్‌క్రిప్ట్ చేయబడి టన్నెల్ ద్వారా ప్రయాణిస్తాయి.

దీనిని దెబ్బతీసే సెట్టింగ్ DNS_UPSTREAM_PLAIN_ADDRESSES. ఏదైనా పేరు రిజాల్వ్ కానప్పుడు, తమ రూటర్ లేదా ప్రొవైడర్ రిజాల్వర్ సమాధానం ఇవ్వాలని భావించి వినియోగదారులు దీనిని ఉపయోగిస్తారు. Gluetun డాక్యుమెంటేషన్ దీని వల్ల కలిగే నష్టాన్ని స్పష్టంగా చెబుతోంది: మొత్తం DNS ట్రాఫిక్ VPN టన్నెల్ ద్వారా వెళ్ళదు మరియు బయటకు లీక్ అవుతుంది. మీ ట్రాఫిక్ ప్రైవేట్‌గా ఉన్నప్పటికీ, మీరు సందర్శించే హోస్ట్‌నేమ్‌ల జాబితా ప్రైవేట్‌గా ఉండదు. ఇదే పొరపాటుకు సంబంధించిన WireGuard వెర్షన్ గురించి WireGuard టన్నెల్ ద్వారా DNS రిజాల్వ్ కాకపోవడం లో వివరించబడింది.

దీనిని పరీక్షించడానికి, Gluetun లో HTTPPROXY=on ని సెట్ చేసి, 8888:8888/tcp ని పబ్లిష్ చేయండి. ఆ తర్వాత బ్రౌజర్‌ను ఆ ప్రాక్సీకి పాయింట్ చేసి, DNS లీక్ టెస్ట్‌ను లోడ్ చేయండి. ఫలితాల్లో మీ ప్రొవైడర్ లేదా Cloudflare పేరు మాత్రమే ఉండాలి, మీ హోమ్ రూటర్ పేరు ఎట్టి పరిస్థితుల్లోనూ ఉండకూడదు. Gluetun డాక్యుమెంటేషన్ హెచ్చరించినట్లుగా, కొన్ని లీక్ టెస్టులు వింత ఫలితాలను చూపవచ్చు, ఎందుకంటే నేమ్‌స్పేస్ లోపల ఉండే రిజాల్వర్ అనేది చివరగా సమాధానం ఇచ్చే సర్వర్ కంటే, స్థానికంగా క్యాష్ చేసే ఒక మధ్యవర్తి మాత్రమే. ఒకవేళ తప్పుడు దేశం పేరు లేదా మీ స్వంత ISP రిజాల్వర్ కనిపిస్తే, అది లీక్ జరుగుతోందని అర్థం చేసుకోవాలి.

VPN sidecar పక్కన Tailscale ను జోడించడం మరియు ఏది ప్రాధాన్యత పొందుతుంది

Tailscale అనేది మీ స్వంత యంత్రాలను చేరుకోవడానికి WireGuard పై నిర్మించిన ఒక overlay network. అడ్మిన్ మార్గాన్ని అందుబాటులో ఉంచుకోవడానికి చాలామంది దీనిని VPN ప్రొవైడర్‌తో పాటు ఉపయోగిస్తారు. ఈ రెండింటి మధ్య ఘర్షణ చాలా అరుదు, దీనికి ఒక ముఖ్యమైన కారణం ఉంది. Tailscale డాక్యుమెంటేషన్ ప్రకారం, ఇది ఒక overlay network గా పనిచేస్తుంది; ఇది Tailscale నడుస్తున్న పరికరాల మధ్య మాత్రమే ట్రాఫిక్‌ను రౌట్ చేస్తుంది మరియు మీ పబ్లిక్ ఇంటర్నెట్ ట్రాఫిక్‌ను ఏమీ చేయదు.

కాబట్టి సమాధానం ఒక సెట్టింగ్‌పై ఆధారపడి ఉంటుంది.

• Tailscale దాని స్వంత కంటైనర్‌లో, డిఫాల్ట్ కాన్ఫిగరేషన్‌లో ఉన్నప్పుడు: ఇది అప్లికేషన్ యొక్క అవుట్‌బౌండ్ ట్రాఫిక్‌ను చూడదు. Gluetun మాత్రమే దానిని నిర్వహిస్తుంది. Tailscale ఇతర బయటి కంటైనర్ల మాదిరిగానే gluetun:8080 వద్ద అప్లికేషన్‌ను చేరుకుంటుంది.
• network_mode: "service:gluetun" తో gluetun యొక్క నెట్‌వర్క్ నేమ్‌స్పేస్‌కు Tailscale ను జత చేసినప్పుడు: దీనికి సొంతంగా cap_add, net_admin మరియు net_raw అవసరం, ఎందుకంటే నేమ్‌స్పేస్‌తో పాటు సామర్థ్యాలు (capabilities) రావు. డిఫాల్ట్ userspace నెట్‌వర్కింగ్ మోడ్‌లో, TS_USERSPACE ఆన్‌లో ఉన్నప్పుడు, tailscaled ఎటువంటి ఇంటర్‌ఫేస్‌ను సృష్టించదు మరియు SOCKS5 లేదా HTTP ప్రాక్సీగా పనిచేస్తుంది, కాబట్టి ఇది రూటింగ్‌ను మార్చలేదు. Gluetun అన్నింటినీ నిర్వహిస్తుంది.
• అదే సెట్టింగ్‌లో TS_USERSPACE=false తో: tailscaled ఒక టన్నెల్ పరికరాన్ని సృష్టించి రూట్‌లను ఇన్‌స్టాల్ చేస్తుంది, కానీ ఇది కేవలం 100.64.0.0/10 tailnet పరిధికి మరియు మీరు TS_ROUTES తో ప్రకటించే సబ్‌నెట్ రూట్‌లకు మాత్రమే పరిమితం. పబ్లిక్ ట్రాఫిక్ ఇప్పటికీ gluetun ద్వారానే వెళ్తుంది.
• పైన పేర్కొన్న వాటిలో దేనినైనా exit node తో ఎంచుకున్నప్పుడు, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale డిఫాల్ట్ రూట్‌ను తీసుకుంటుంది మరియు అదే ప్రాధాన్యత పొందుతుంది. దీనిని gluetun తో కలపవద్దు. ఒక డిఫాల్ట్ రూట్‌కు ఒకే యజమాని ఉండాలి.

ఒకవేళ ఆ ప్రకటించిన రూట్‌లే ముఖ్యమైతే, మరియు మీరు కేవలం బాక్స్‌ను మాత్రమే కాకుండా బాక్స్ వెనుక ఉన్న మొత్తం ప్రైవేట్ నెట్‌వర్క్‌ను చేరుకోవాలనుకుంటే, VPS పై Tailscale సబ్‌నెట్ రౌటర్‌ను రన్ చేయడం అనే అంశం రూట్ ఆమోదం, IP ఫార్వార్డింగ్ మరియు TS_ROUTES ద్వారా పూర్తికాని క్లయింట్ సైడ్ ఫ్లాగ్‌లను వివరిస్తుంది.

Tailscale కేవలం రూట్ కోసం కాకుండా అడ్మిన్ URL కోసం ఉద్దేశించినట్లయితే, tailscale serve మరియు tailscale funnel మీ tailnet కోసం gluetun:8080 ముందు HTTPS ను ఉంచుతాయి, funnel ద్వారా మాత్రమే ఇది పబ్లిక్ ఇంటర్నెట్‌కు అందుబాటులో ఉంటుంది.

టన్నెల్ లోపల Tailscale రన్ అయినప్పుడు ఒక దుష్ప్రభావం కనిపిస్తుంది. దీని peers VPN ప్రొవైడర్ యొక్క అడ్రస్‌ను చూస్తాయి, కాబట్టి ఇది తరచుగా relays కు మళ్లుతుంది. ఇలా జరిగినప్పుడు tailscale status లో peer పక్కన direct కు బదులుగా relay "..." కనిపిస్తుంది. కనెక్షన్ పనిచేస్తుంది కానీ వేగం తక్కువగా ఉంటుంది. మీకు కేవలం overlay మాత్రమే అవసరమైతే, సాధారణ WireGuard మరియు Tailscale మధ్య వ్యత్యాసం ప్రారంభించడానికి సరైన మార్గం.

ఏమి విఫలమవుతుంది మరియు మీకు కనిపించే సందేశం

Docker అప్లికేషన్ కంటైనర్‌ను సృష్టించడానికి నిరాకరిస్తుంది. Error response from daemon: conflicting options: port publishing and the container type network mode అంటే ఒక ports: బ్లాక్ ఇంకా అటాచ్ చేయబడిన సర్వీస్‌పైనే ఉంది అని అర్థం. దానిని gluetun కు తరలించండి.

Compose మొత్తం ఫైల్‌ను తిరస్కరిస్తుంది. ఒక సర్వీస్ ఒకేసారి network_mode మరియు networks రెండింటినీ సెట్ చేయలేదు. నెట్‌వర్క్‌లను gluetun పై ఉంచండి.

మరొక కంటైనర్ అప్లికేషన్‌ను రిజాల్వ్ చేయలేదు. curl: (6) Could not resolve host: qbittorrent అనేది సరైన ప్రవర్తన, ఎందుకంటే అటాచ్ చేయబడిన కంటైనర్ ఏ నెట్‌వర్క్‌లోనూ చేరలేదు మరియు ఏ పేరును రిజిస్టర్ చేయలేదు. gluetun మరియు పోర్ట్‌ను ఉపయోగించండి.

రెండవ అటాచ్ చేయబడిన కంటైనర్ ప్రారంభం కాదు. ఒకే నేమ్‌స్పేస్‌లో ఉన్న రెండు ప్రాసెస్‌లు ఒకే పోర్ట్‌ను బైండ్ చేయలేవు, మరియు ఓడిపోయిన ప్రాసెస్ అడ్రస్ ఇప్పటికే వాడుకలో ఉందని రిపోర్ట్ చేస్తుంది. అప్లికేషన్ యొక్క అంతర్గత పోర్ట్‌ను మార్చండి లేదా రెండవ gluetun ను రన్ చేయండి.

మీరు gluetun ను తాకిన తర్వాత అప్లికేషన్‌కు నెట్‌వర్క్ ఉండదు. gluetun ను రీస్టార్ట్ చేయడం లేదా రీక్రియేట్ చేయడం వల్ల దానికి అటాచ్ చేయబడిన అన్నింటి కనెక్టివిటీ పోతుంది. ఆ కంటైనర్లను రీస్టార్ట్ చేయండి.

చిన్న పేజీలు లోడ్ అవుతాయి మరియు పెద్దవి హ్యాంగ్ అవుతాయి. ఇది MTU (maximum transmission unit) సమస్య. టన్నెల్ అదనపు ఓవర్‌హెడ్‌ను జోడిస్తుంది, మరియు పాత్‌లో ఏదో ఒకటి ఎర్రర్ పంపకుండానే పెద్ద ప్యాకెట్లను డ్రాప్ చేస్తుంది. WIREGUARD_MTU ని తగ్గించండి, 1400 ప్రయత్నించండి, ఆపై 1320 ప్రయత్నించండి.

Gluetun ఎప్పటికీ హెల్తీగా మారదు. స్టార్టప్ చెక్ మొదటి అనుమానితులను ఇలా పేర్కొంటుంది: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. కీ గడువు ముగిసిందో లేదో తనిఖీ చేయండి, ఆపై సర్వర్ జాబితా పాతదైందేమో చూడండి, చివరగా మీ హోస్ట్ ఫైర్‌వాల్ అవుట్‌బౌండ్ UDPని బ్లాక్ చేస్తుందేమో పరిశీలించండి.

FAQ

Gluetun వెనుక నా కంటైనర్ యొక్క published ports ఎందుకు పనిచేయడం లేదు?

ఎందుకంటే network_mode: "service:gluetun" కంటైనర్‌ను Gluetun యొక్క network namespace లోపల ఉంచుతుంది. ఒక namespace కి ఒక IP అడ్రస్ మరియు ఒకే రకమైన listening ports ఉంటాయి. అప్లికేషన్ వినడం (listening) కొనసాగిస్తుంది, కానీ publish నియమం మాత్రం ఆ namespace ని కలిగి ఉన్న కంటైనర్‌పైనే ఉండాలి. ports: జాబితాను Gluetun సర్వీస్‌కు తరలించండి. ఒకవేళ మీరు దానిని attached సర్వీస్‌పైనే ఉంచితే, Docker దానిని సృష్టించదు: Error response from daemon: conflicting options: port publishing and the container type network mode.

VPN టన్నెల్ లోపల ఉన్న కంటైనర్‌ను, బయట ఉన్న కంటైనర్ నుండి ఎలా చేరుకోవాలి?

Gluetun సర్వీస్ పేరును మరియు అప్లికేషన్ వింటున్న పోర్ట్‌ను ఉపయోగించండి, ఉదాహరణకు gluetun:8080. Attached కంటైనర్‌కు సొంతంగా ఎటువంటి Docker నెట్‌వర్క్ ఉండదు, కాబట్టి దాని పేరు ఎప్పటికీ resolve అవ్వదు. కంటైనర్-టు-కంటైనర్ ట్రాఫిక్ కోసం దేనినీ publish చేయాల్సిన అవసరం లేదు. దీనికి విరుద్ధంగా, namespace లోపల ఉన్న కంటైనర్, బయట ఉన్న కంటైనర్‌ను దాని సర్వీస్ పేరుతో చేరుకుంటుంది, ఉదాహరణకు Gluetun v3.41 మరియు ఆ పైన వెర్షన్లలో postgres:5432. వేరే సబ్‌నెట్‌లో ఉన్న క్లయింట్ (ఉదాహరణకు మీ LAN లోని ల్యాప్‌టాప్) ట్రాఫిక్‌ను, మీరు ఆ సబ్‌నెట్‌ను FIREWALL_OUTBOUND_SUBNETS లో చేర్చే వరకు Gluetun ఫైర్‌వాల్ నిలిపివేస్తుంది.

VPN కనెక్షన్ తెగిపోయినప్పుడు Gluetun 'kill switch' లా పనిచేస్తుందా?

అవును, ఇది ఒకేసారి రెండు కారణాల వల్ల పనిచేస్తుంది. Attached కంటైనర్‌కు షేర్డ్ namespace లో ఉన్న రూట్ తప్ప వేరే మార్గం ఉండదు, కాబట్టి టన్నెల్ ఆగిపోతే అది మెషిన్ బయటకు వెళ్లలేదు. అలాగే, Gluetun ఫైర్‌వాల్ కేవలం టన్నెల్ ద్వారా మరియు VPN సర్వర్ ఎండ్‌పాయింట్‌కు మాత్రమే బయటకు వెళ్లే ట్రాఫిక్‌ను అనుమతిస్తుంది. Gluetun స్వయంగా రీస్టార్ట్ అవ్వకుండా, VPNని అంతర్గతంగా రీస్టార్ట్ చేస్తుంది మరియు WARN [vpn] restarting VPN because it failed to pass the healthcheck అని లాగ్ చేస్తుంది. ఎందుకంటే Gluetun రీస్టార్ట్ అయితే దానికి అనుసంధానించబడిన అన్ని కంటైనర్లు నెట్‌వర్క్‌ను కోల్పోతాయి.

ఒకే stack లో Tailscale మరియు Gluetun ఉంటే, బయటకు వెళ్లే ట్రాఫిక్‌ను ఏది నిర్వహిస్తుంది?

ఒక కాన్ఫిగరేషన్ మినహా మిగిలిన అన్నింటిలోనూ Gluetun నిర్వహిస్తుంది. Tailscale డిఫాల్ట్‌గా మీ tailnet లోని పరికరాల మధ్య మాత్రమే ట్రాఫిక్‌ను రూట్ చేస్తుంది, పబ్లిక్ ట్రాఫిక్‌ను ఏమీ చేయదు. కంటైనర్ ఇమేజ్ యొక్క డిఫాల్ట్ userspace మోడ్‌లో ఇది ఎటువంటి ఇంటర్‌ఫేస్‌ను సృష్టించదు, కాబట్టి ఇది రూటింగ్‌పై ప్రభావం చూపదు. TS_USERSPACE=false తో ఇది కేవలం 100.64.0.0/10 మరియు మీరు ప్రకటించిన (advertised) సబ్‌నెట్‌ల కోసం మాత్రమే రూట్‌లను ఇన్‌స్టాల్ చేస్తుంది. దీనికి మినహాయింపు exit node: sudo tailscale set --exit-node=<exit-node-ip> ద్వారా Tailscale డిఫాల్ట్ రూట్‌గా మారుతుంది, అప్పుడు అది ట్రాఫిక్‌ను నియంత్రిస్తుంది. రెండింటినీ కలిపి వాడటం కంటే, డిఫాల్ట్ రూట్‌ను నిర్వహించడానికి ఏదో ఒక ప్రోడక్ట్‌ను మాత్రమే ఎంచుకోండి.