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 ఉపయోగిస్తాయి, కాబట్టి మీకు మీ ప్రొవైడర్ నుండి ఒక ఖాతా మరియు కీ అవసరం. మీరు టన్నెల్‌ను మీ సొంత హార్డ్‌వేర్‌పై టెర్మినేట్ చేయాలనుకుంటే, VPSపై మీ సొంత WireGuard సర్వర్‌ను రన్ చేయడం ద్వారా అవతలి చివరను నిర్మించుకోవచ్చు, మరియు Dockerలో wg-easy దానిని వెబ్ ఇంటర్‌ఫేస్‌తో సులభతరం చేస్తుంది.

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

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

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

Gluetun ను restart చేయడం వల్ల దానికి అనుసంధానించబడినవన్నీ డిస్‌కనెక్ట్ అవుతాయి. ఇది డాక్యుమెంట్ చేయబడిన ప్రవర్తన, మరియు కనెక్షన్ విఫలమైనప్పుడు gluetun బయటకు వెళ్లకుండా (exit అవ్వకుండా) 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 file లో keys ఉంచవద్దు

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 files మరియు secrets మరింత మెరుగైన పద్ధతులను వివరిస్తుంది.

టన్నెల్ వెలుపల ఉన్న కంటైనర్ లోపల ఉన్న దానితో ఎలా కమ్యూనికేట్ చేస్తుంది

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

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

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

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

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 తర్వాత unhealthy గా మారితే, అది అప్లికేషన్‌ను ఆపదు లేదా రీస్టార్ట్ చేయదు. దానికి బదులుగా gluetun యొక్క అంతర్గత ఆటో-హీలింగ్ ఆ పరిస్థితిని చక్కదిద్దుతుంది, అందుకే అది కంటైనర్‌ను కాకుండా VPN ప్రాసెస్‌ను రీస్టార్ట్ చేస్తుంది.

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

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

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

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

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

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

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

• Tailscale దాని స్వంత కంటైనర్‌లో, డిఫాల్ట్ కాన్ఫిగరేషన్‌లో ఉన్నప్పుడు: ఇది అప్లికేషన్ యొక్క అవుట్‌బౌండ్ ట్రాఫిక్‌ను చూడదు. Gluetun మాత్రమే మొత్తం ట్రాఫిక్‌ను నిర్వహిస్తుంది. Tailscale, ఇతర బయటి కంటైనర్ల మాదిరిగానే, అప్లికేషన్‌ను gluetun:8080 వద్ద చేరుకుంటుంది.
• Gluetun నెట్‌వర్క్ నేమ్‌స్పేస్‌కు network_mode: "service: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 తో కలపవద్దు. ఒక డిఫాల్ట్ రూట్‌కు ఒక యజమాని మాత్రమే ఉండాలి.

టన్నెల్ లోపల 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

Why did my container's published ports stop working behind Gluetun?

Because network_mode: "service:gluetun" puts the container inside gluetun's network namespace, and a namespace has one IP address and one set of listening ports. The app keeps listening, but the publish rule has to live on the container that owns the namespace. Move the ports: list to the gluetun service. If you left it on the attached service, Docker will not even create it: Error response from daemon: conflicting options: port publishing and the container type network mode.

How do I reach a container inside the VPN tunnel from a container outside it?

Use gluetun's service name and the port the app listens on, for example gluetun:8080. The attached container is on no Docker network of its own, so its own name never resolves. Nothing needs publishing for container to container traffic. Going the other way, a container inside the namespace reaches an outside container by its service name, such as postgres:5432, on Gluetun v3.41 and newer. A client on a different subnet, such as a laptop on your LAN, is dropped by gluetun's firewall until you add that subnet to FIREWALL_OUTBOUND_SUBNETS.

Does Gluetun work as a kill switch when the VPN drops?

Yes, and for two reasons at once. The attached container has no route except the one in the shared namespace, so a dead tunnel leaves it with no path off the machine. Gluetun's firewall also allows outbound traffic only through the tunnel and to the VPN server endpoint. Gluetun then restarts the VPN internally, logging WARN [vpn] restarting VPN because it failed to pass the healthcheck, rather than exiting, because every attached container loses its network when gluetun itself restarts.

Tailscale and Gluetun in the same stack: which one carries outbound traffic?

Gluetun, in every configuration except one. Tailscale only routes traffic between devices in your tailnet by default and leaves public traffic alone. In the container image's default userspace mode it creates no interface at all, so it cannot affect routing. With TS_USERSPACE=false it installs routes for 100.64.0.0/10 and your advertised subnets only. The exception is an exit node: sudo tailscale set --exit-node=<exit-node-ip> makes Tailscale the default route, and then it wins. Choose one product to own the default route rather than stacking both.