ద్వారా Matt Connor 2026-08-04 · అప్‌డేట్ చేయబడింది 2026-08-13

Gluetun ద్వారా host, ఇతర containers ను చేరడం ఎలా

Q: Docker "port publishing and the container type network mode" అని ఎందుకు చెబుతుంది?

network_mode: service:gluetun ను కూడా సెట్ చేసిన service లో ports: block ఇంకా ఉండటం వల్ల ఈ సందేశం వస్తుంది. Port publish చేయడం ద్వారా host port నుంచి container యొక్క స్వంత network namespace కు forward చేసే NAT rule జోడించబడుతుంది. అయితే ఈ mode లోని container కు స్వంత network namespace ఉండదు. ఆ service నుంచి ports: block ను తొలగించి, అదే mapping ను gluetun service కు జోడించండి. Application shared namespace లో అదే port పై ఇంకా listening చేస్తుంది కాబట్టి port number మారదు.

Q: gluetun వెనుక ఉన్న service ను ఇతర containers ఎలా చేరుకుంటాయి?

అదే namespace లోని containers ఒకదానినొకటి 127.0.0.1 వద్ద చేరుకుంటాయి. బయట ఉన్న containers gluetun service name ను ఉపయోగించాలి. అందువల్ల http://gluetun:8080 పనిచేస్తుంది, కానీ http://qbittorrent:8080 పనిచేయదు. Application container ఏ Docker network పైనా address కలిగి ఉండదు. కాబట్టి embedded DNS server దాని పేరు కోసం resolve చేయడానికి ఏదీ కలిగి ఉండదు. రెండు containers ఒకే Compose network పంచుకుంటే దీనికి port publishing అవసరం లేదు.

Gluetun వెనుక ఉన్న container కు స్వంత interfaces ఉండవు. దాని ports ను gluetun పై publish చేసి, tunnel వెలుపల చేరాల్సిన subnets ను మాత్రమే అనుమతించండి.

container gluetun నెట్‌వర్క్‌లో చేరినప్పుడు ఏమి జరుగుతుంది

network_mode: service:gluetun ను సెట్ చేసిన container కు స్వంత network interfaces ఉండవు. అది gluetun యొక్క network namespace లో చేరుతుంది. అందువల్ల port publishing మరియు firewall rules ఆ container లక్షణాలుగా కాకుండా gluetun service లక్షణాలుగా మారతాయి. దిగువ సమాధానాలన్నీ ఈ ఒక్క వాస్తవం నుంచే వస్తాయి.

Network namespace అనేది kernel అందించే network stack యొక్క private copy. ఇందులో స్వంత interfaces, స్వంత routing table, స్వంత firewall rules మరియు స్వంత listening sockets ఉంటాయి. Docker సాధారణంగా ప్రతి container కు ఒక namespace కేటాయిస్తుంది. మీరు network_mode: service:gluetun అని వ్రాసినప్పుడు, Docker ఆ దశను దాటవేసి, ఇప్పటికే gluetun ఆధీనంలో ఉన్న namespace లోకి కొత్త container ను ఉంచుతుంది. ఆ container తన స్వంత filesystem ను మరియు తన స్వంత /etc/hosts file ను కొనసాగిస్తుంది. తరువాత ఈ రెండవది ముఖ్యమవుతుంది.

దీనిని నేరుగా చూడవచ్చు.

docker inspect -f '{{.HostConfig.NetworkMode}}' qbittorrent

ఇది container: ను, దాని తరువాత gluetun container ID ను ముద్రిస్తుంది. సాధారణ container అయితే bridge ను ముద్రిస్తుంది. ఈ guide gluetun ద్వారా Docker traffic ను VPN మీదుగా route చేయడం ముగిసిన చోటు నుంచి కొనసాగుతుంది: tunnel పనిచేస్తోంది, కానీ ఇప్పుడు ఏదీ container తో సంభాషించలేకపోతోంది.

gluetun పై port ను publish చేయండి, application పై కాదు

network_mode ను సెట్ చేసే ports: block ను service పై ఉంచితే Docker container ను సృష్టించడానికి నిరాకరిస్తుంది:

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

కారణం స్పష్టంగా ఉంది. Port ను publish చేయడం అంటే host port నుంచి container యొక్క స్వంత network namespace లోకి traffic ను forward చేసే NAT (network address translation) rule ను జోడించడం. అయితే ఈ container కు స్వంత network namespace లేదు. Mapping ను gluetun service కు తరలించండి. Port number మారదు, ఎందుకంటే shared namespace లో application అదే port పై listening చేస్తూనే ఉంటుంది.

services:
  gluetun:
    ports:
      - "8080:8080/tcp"   # qBittorrent web UI

  qbittorrent:
    network_mode: "service:gluetun"
    # no ports: block here

ఆధారపడిన service పై expose: block ఉంచడం కూడా ప్రయోజనం లేనిదే. అక్కడ networks: block ఉంచితే అది పూర్తిగా ఆపివేస్తుంది: service పరస్పరం మినహాయించుకునే network_mode మరియు networks ను ప్రకటించిందని Compose నివేదించి, file ను అసలు load చేయదు.

దీని ప్రభావం తరువాత కనిపిస్తుంది. Namespace లోని ప్రతి container ఒకే port space ను పంచుకుంటుంది. అందువల్ల default గా 8080 ఉపయోగించే రెండు applications పరస్పరం ఢీకొంటాయి. రెండోది start కావడానికి ప్రయత్నించినప్పుడు address already in use error తో విఫలమవుతుంది. వాటిలో ఒకదాని స్వంత configuration లో port ను మార్చండి. ఉదాహరణకు LinuxServer qBittorrent image లోని WEBUI_PORT variable ను మార్చి, కొత్త number ను gluetun పై publish చేయండి.

gluetun వెనుక ఉన్న containers ఒకదానితో ఒకటి ఎలా చేరుకుంటాయి?

namespace లో అవి ఇప్పటికే ఒకే loopback interface ను పంచుకుంటాయి. gluetun వెనుక ఉన్న container, Docker network అవసరం లేకుండానే 127.0.0.1:<port> వద్ద ఉన్న తన sibling ను చేరుకుంటుంది.

namespace వెలుపల ఆ container కు పేరు ఉండదు. Docker embedded DNS, user defined network పై ఉన్న సేవ address కు service name ను resolve చేస్తుంది. కానీ ఈ container కు ఏ network పైనా address లేదు. అందువల్ల Sonarr వంటి సాధారణ container, torrent client ను http://qbittorrent:8080 వద్ద చేరుకోదు. అది http://gluetun:8080 వద్ద చేరుకుంటుంది, ఎందుకంటే socket gluetun namespace లో, gluetun address పై listening చేస్తోంది. Docker Compose networks మరియు service names ఎలా పనిచేస్తాయో తెలిసినవారికి ఇది ఆశ్చర్యంగా అనిపిస్తుంది. సాధారణ naming వర్తిస్తుందని వారు ఆశిస్తారు. రెండు containers ఒకే Compose network పై ఉన్నందున, host కు ఏదీ publish చేయకపోయినా ఇది పనిచేస్తుంది.

ఇంకేదైనా debug చేయడానికి ముందు DNS ను తనిఖీ చేయండి. Gluetun తన స్వంత resolver ను నడుపుతుంది మరియు తన container లో /etc/resolv.conf ను తిరిగి రాస్తుంది. అయితే /etc/resolv.conf ప్రతి container కు ప్రత్యేకమైన file. కాబట్టి gluetun రాసిన file, మీ application చదివే file కాదు.

docker exec qbittorrent cat /etc/resolv.conf

Docker host పై నడుస్తున్న సేవను ఎలా చేరుకోవాలి?

host.docker.internal ఉపయోగించండి. దీనికి రెండు వేర్వేరు చోట్ల రెండు సెట్టింగ్‌లు అవసరం, ఎందుకంటే రెండు వేర్వేరు అంశాలు సరిగ్గా అమర్చబడలేదు.

ముందుగా పేరు వస్తుంది. /etc/hosts ప్రతి container కు ప్రత్యేకంగా ఉంటుంది. కాబట్టి extra_hosts entry gluetun పై కాకుండా application container పై ఉండాలి.

  prowlarr:
    network_mode: "service:gluetun"
    extra_hosts:
      - "host.docker.internal:host-gateway"

host-gateway అనేది Docker host యొక్క అంతర్గత address తో Docker భర్తీ చేసే ప్రత్యేక value. సాధారణ Linux Docker installation లో ఇది docker0 bridge యొక్క address. సాధారణంగా ఇది 172.17.0.1. VPS పై ip -4 addr show docker0 ఉపయోగించి మీ address ను నిర్ధారించండి. Docker Desktop ఈ పేరును స్వయంగా resolve చేస్తుంది. అందుకే laptop కోసం రాసిన guides లో extra_hosts line ఉండదు. అదే file server పై విఫలమవుతుంది.

తర్వాత route వస్తుంది. పేరు జోడించడం ద్వారా container ఏ address ఉపయోగించాలో మాత్రమే తెలుస్తుంది. Packet ఇంకా gluetun యొక్క default route ద్వారా బయటకు వెళ్తుంది. ఆ route tunnel కావడంతో gluetun firewall దాన్ని drop చేస్తుంది. దీని లక్షణం connection hang అయి, తరువాత timeout కావడం. Connection refused అయితే packet చేరి, ఏదో ఒక సేవ నిరాకరణకు సమాధానం ఇచ్చిందని అర్థం. Timeout అయితే packet చేరలేదని అర్థం.

  gluetun:
    environment:
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32

తర్వాత host service వాస్తవంగా ఆ address పై listening చేస్తుందో లేదో పరిశీలించండి. 127.0.0.1 కు మాత్రమే bind చేసిన PostgreSQL server ను ఏ container నుంచైనా చేరుకోలేరు; tunnel ఉన్నా లేకపోయినా ఇదే పరిస్థితి. ఎందుకంటే namespace లోని 127.0.0.1 ఆ namespace యొక్క స్వంత loopback. దాని బదులుగా 172.17.0.1 కు bind చేయండి. అప్పుడు public interface పై అందుబాటులో లేకుండానే containers నుంచి connections స్వీకరిస్తుంది. Host పై ss -lntp | grep 5432 ఉపయోగించి నిర్ధారించండి.

FIREWALL_OUTBOUND_SUBNETS వాస్తవంగా మార్చేది

gluetun documentation ప్రకారం, gluetun మరియు దాని network stack ను పంచుకునే containers access చేయడానికి అనుమతించిన comma-separated subnets ఇవి. ఇందులో firewall మరియు routing మార్పులు ఉంటాయని కూడా documentation పేర్కొంటుంది. ఈ రెండు అంశాలూ ముఖ్యమైనవి. జాబితాలోని ప్రతి subnet కోసం gluetun Docker bridge gateway ద్వారా ఒక route ను జోడిస్తుంది. అందువల్ల ఆ addresses కు వెళ్లే packets tunnel ద్వారా కాకుండా eth0 పైగా బయటకు వెళ్తాయి. వాటి కోసం firewall ను కూడా తెరుస్తుంది. లేకపోతే VPN server వైపు వెళ్లని outbound traffic ను gluetun drop చేస్తుంది.

కమాల తర్వాత ఖాళీలు లేకుండా value ను రాయండి.

      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,192.168.1.0/24,100.64.7.9/32

సులభంగా మిస్ అయ్యే రెండు విషయాలు ఉన్నాయి. ఇది namespace-level setting. అందువల్ల మీరు ఉద్దేశించిన container కు మాత్రమే కాకుండా, gluetun వెనుక ఉన్న ప్రతి container కు ఇది వర్తిస్తుంది. రెండవది, ఇది outbound traffic కు మాత్రమే వర్తిస్తుంది. అంటే container ప్రారంభించే connections ను ఇది నియంత్రిస్తుంది. Published port కు వచ్చే connections వేరే మార్గంలో ప్రయాణిస్తాయి. వాటి కోసం ఇక్కడ entry అవసరం లేదు.

Tailscale peer నుంచి web UIకి చేరుకోవడం

Tailscale ప్రతి యంత్రానికి carrier grade NAT కోసం కేటాయించిన 100.64.0.0/10 పరిధిలో ఒక address ఇస్తుంది. ఇక్కడ inbound మరియు outbound దిశలకు వేర్వేరు విధానాలు అవసరం.

Inbound విధానం సులభం. gluetunలో 8080:8080 ను publish చేస్తే, ఆ port hostకు చెందిన అన్ని addressesపై bind అవుతుంది. Host యొక్క tailscale0 interface కూడా వాటిలో ఒకటి. అందువల్ల peer నుంచి http://<machine-name>:8080 తెరిస్తే containerకి చేరుకోవచ్చు. ఈ మార్గంలో Gluetunకు ఎలాంటి పాత్ర ఉండదు, ఎందుకంటే Docker యొక్క NAT rule hostపై, namespace వెలుపల ఉంటుంది.

UIను tailnet ద్వారా మాత్రమే అందుబాటులో ఉంచడానికి, published portను అన్ని addressesకు బదులుగా host యొక్క Tailscale addressకు bind చేయండి.

    ports:
      - "100.101.102.103:8080:8080/tcp"

Hostపై tailscale ip -4 ఉపయోగించి ఆ addressను కనుగొనండి. ఇక్కడ firewall rule కంటే binding మరింత బలమైన నియంత్రణను ఇస్తుంది, ఎందుకంటే port public interfaceపై అసలు open కాదు. ఇది Docker portsను ufwను దాటి నేరుగా publish చేయడం అనే సమస్యను కూడా నివారిస్తుంది.

Outbound మార్గంలో FIREWALL_OUTBOUND_SUBNETS మళ్లీ ఉపయోగపడుతుంది. Container ఒక peerకు call చేయాల్సి ఉంటే, ఆ peer addressను జోడించండి. మొత్తం /10కు బదులుగా ప్రతి peerకు ఒక /32 ఉపయోగించడం మంచిది. Container host యొక్క resolverను ఉపయోగించదు కాబట్టి, MagicDNS names containerలో resolve కావు. అందువల్ల numeric 100.x addressను ఉపయోగించండి లేదా దాన్ని extra_hosts lineతో స్థిరంగా కేటాయించండి. Headscaleతో మీ స్వంత Tailscale control serverను నడపడం సందర్భంలో కూడా ఇదే వర్తిస్తుంది.

సాధారణ నిర్మాణానికి పూర్తి compose file

VPN వెనుక ఉన్న download client, tailnet పై మాత్రమే స్పందించే రెండు web UIలు, అలాగే hostపై నడుస్తున్న PostgreSQL database నుంచి డేటాను చదివే ఒక container.

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - "127.0.0.1:8000:8000/tcp"        # gluetun control server, host only
      - "100.101.102.103:8080:8080/tcp"  # qBittorrent UI, tailnet only
      - "100.101.102.103:9696:9696/tcp"  # Prowlarr UI, tailnet only
    volumes:
      - ./gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - WIREGUARD_ADDRESSES=${WIREGUARD_ADDRESSES}
      - SERVER_CITIES=Amsterdam
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32,100.64.7.9/32
      - TZ=Europe/Amsterdam
    restart: unless-stopped

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

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    network_mode: "service:gluetun"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - PROWLARR__POSTGRES__HOST=host.docker.internal
      - PROWLARR__POSTGRES__PORT=5432
      - PROWLARR__POSTGRES__USER=prowlarr
      - PROWLARR__POSTGRES__PASSWORD=${PROWLARR_DB_PASSWORD}
      - PROWLARR__POSTGRES__MAINDB=prowlarr-main
      - PROWLARR__POSTGRES__LOGDB=prowlarr-log
    volumes:
      - ./prowlarr:/config
    depends_on:
      gluetun:
        condition: service_healthy
    restart: unless-stopped

Product names కంటే patternను గమనించి fileను చదవండి. రెండు UIలు gluetunపై publish చేయబడి, host యొక్క tailnet addressకు bind అవుతాయి. అందువల్ల అవి Tailscaleపై మాత్రమే స్పందిస్తాయి; మరెక్కడా స్పందించవు. Prowlarr మాత్రమే extra_hosts lineను కలిగి ఉంటుంది, ఎందుకంటే host.docker.internal ను resolve చేసే container Prowlarr. FIREWALL_OUTBOUND_SUBNETS రెండు single addressesను పేర్కొంటుంది: Prowlarr database connectionను తెరవడానికి ఉపయోగించే host యొక్క Docker bridge address, అలాగే ఒక tailnet peer.

PostgreSQL serverను ఉద్దేశపూర్వకంగా ఈ fileలో చేర్చలేదు. అది VPSపై సాధారణ system serviceగా నడుస్తూ 172.17.0.1:5432 పై listen చేస్తుంది. ఇది Docker Composeపై arr stackతో సమానమైన layering. అయితే databaseను Docker వెలుపల ఉంచారు.

WireGuard private keyను compose fileలో ఉంచవద్దు. ${WIREGUARD_PRIVATE_KEY} దాని పక్కన ఉన్న .env file నుంచి చదువుతుంది. ఈ విధానం Docker Compose కోసం env files మరియు secretsలో వివరించబడింది. gluetun imageలో ఇప్పటికే ఉన్న healthcheckను condition: service_healthy clause ఉపయోగిస్తుంది. అందువల్ల tunnel up అయినట్లు report చేసే వరకు ఏదీ ప్రారంభం కాదు. సాధారణ రూపం కోసం Compose healthchecks చూడండి.

ప్రతి addressపై publish చేయడం, tailnetపై మాత్రమే కాకుండా

0.0.0.0 పై ఉన్న address prefix మరియు port bindsను తొలగించండి. ఇందులో VPS public IP కూడా ఉంటుంది. మీరు నియంత్రించే firewall వెనుక మాత్రమే ఇలా చేయండి. ముందుగా పై ఉన్న ufw గమనికను చదవండి.

    ports:
      - "8080:8080/tcp"

టన్నెల్ ఇప్పటికీ ట్రాఫిక్‌ను తీసుకెళ్తోందో నిర్ధారించండి

అదే అభ్యర్థనను రెండుసార్లు అమలు చేయండి. ఒకసారి namespace లోపల నుంచి, మరోసారి host నుంచి అమలు చేసి ఫలితాలను పోల్చండి.

docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org
curl -s https://api.ipify.org

మొదటి ఆదేశం మీ VPN provider యొక్క exit address ను చూపాలి. రెండవది VPS address ను చూపాలి. రెండూ ఒకేలా ఉంటే, container యొక్క ట్రాఫిక్ tunnel ద్వారా వెళ్లడం లేదు. అది సరిచేయబడే వరకు ఈ guide లోని ఇతర పరిష్కారాలు ఉపయోగపడవు.

Routing table లో tunnel ద్వారా వెళ్లే మరియు వెళ్లని మార్గాలు కనిపిస్తాయి.

docker run --rm --network=container:gluetun alpine:3.22 ip route show

Default route tunnel interface, tun0, వైపు చూపాలి. దాని కింద FIREWALL_OUTBOUND_SUBNETS లోని ప్రతి entryకి ఒక route కనిపించాలి. ఈ routes Docker bridge gateway వైపు చూపాలి. eth0 ద్వారా బయటకు వెళ్లే మరే ఇతర route అయినా VPN ను దాటివెళ్లే ట్రాఫిక్‌ను సూచిస్తుంది.

Gluetun యొక్క control server port 8000 పై అదే public IP ను /v1/publicip/ip వద్ద చూపిస్తుంది. ఇటీవలి versions లో control server routes కోసం authentication ను configure చేయాలి. కాబట్టి దానిపై ఆధారపడే ముందు authentication ను ఏర్పాటు చేయండి.

ఒక తప్పు subnet వల్ల ఏర్పడే leak

FIREWALL_OUTBOUND_SUBNETS firewall లో ఉద్దేశపూర్వకంగా చేసే రంధ్రం. అందువల్ల ఆ రంధ్రం పరిమాణమే ప్రమాదం పరిమాణం. దాన్ని అవసరానికి మించి పెద్దదిగా చేసే నాలుగు మార్గాలు ఇవి:

0.0.0.0/0 tunnel వెలుపలికి వెళ్లే మొత్తం traffic ను పంపుతుంది. పై రెండు IP checks ను మొదటిసారి అమలు చేసినప్పుడు ఈ సమస్య కనిపిస్తుంది, ఎందుకంటే అవి ఒకే address ను తిరిగి ఇస్తాయి.
target కంటే విస్తృతమైన range ను ఉపయోగించడం. 10.0.1.7 వద్ద ఉన్న ఒక machine ను చేరుకోవడానికి 10.0.0.0/8 ను open చేస్తే, ఆ range లో torrent peer ప్రకటించే ప్రతి address కూడా open అవుతుంది. 10.0.1.7/32 రాయండి.
tunnel కు చెందిన addresses తో overlap అయ్యే range ను ఉపయోగించడం. ఇలా చేస్తే gluetun VPN traffic ను bridge ద్వారా బయటికి పంపుతుందని gluetun documentation హెచ్చరిస్తుంది. దీనివల్ల port forwarding పనిచేయదు. ఏదైనా private range ను open చేయడానికి ముందు మీ WIREGUARD_ADDRESSES విలువను తనిఖీ చేయండి.
Tailscale కోసం 100.64.0.0/10 ఉపయోగించడం. ఒక peer ను చేరుకోవడానికి సుమారు నాలుగు million addresses ను open చేసినట్లవుతుంది. అవసరమైన peers ను /32 entries గా జాబితా చేయండి.

ఈ setting మొత్తం namespace కు వర్తిస్తుందని గుర్తుంచుకోండి. ఒక indexer host service ను చేరుకోవడానికి subnet ను open చేస్తే, అదే namespace ను share చేస్తున్న torrent client కు కూడా ఆ subnet open అవుతుంది. ఈ variable లో ప్రతి మార్పు తర్వాత public IP check ను మళ్లీ అమలు చేయండి. మీరు ఉద్దేశించిన విధంగానే మార్పు పనిచేసిందో చూపించే ఏకైక test ఇదే.

gluetun ను restart చేసినప్పుడు ఏమి విఫలమవుతుంది

gluetun namespace ను నిర్వహిస్తుంది. అందువల్ల gluetun lifecycle నే namespace lifecycle గా ఉంటుంది. gluetun ఆపివున్నప్పుడు దానిపై ఆధారపడే container ను ప్రారంభిస్తే వెంటనే విఫలమవుతుంది:

Error response from daemon: cannot join network of a non running container

gluetun ను అదే స్థానంలో restart చేయడం నిశ్శబ్దంగా కనిపించే విఫలత. dependent containers నడుస్తూనే ఉంటాయి. అయితే అవి అనుసంధానమైన namespace వాటి కిందనే మళ్లీ నిర్మించబడుతుంది. అందువల్ల docker ps ప్రతిదీ ఆరోగ్యంగా ఉందని చూపిస్తుంది, కానీ ఏదీ స్పందించదు. gluetun service లో ఏదైనా మార్పు చేసిన తర్వాత, ఒక భాగాన్ని మాత్రమే restart చేయకుండా మొత్తం group ను మళ్లీ సృష్టించండి.

docker compose up -d --force-recreate

image updates కు కూడా ఇదే వర్తిస్తుంది. కొత్త gluetun image ను pull చేసి, ఆ ఒక్క service ను మాత్రమే మళ్లీ సృష్టిస్తే, మిగిలినవి ఇక ఉనికిలో లేని namespace కు అనుసంధానమై ఉంటాయి.

FAQ

Docker "port publishing and the container type network mode" అని ఎందుకు చెబుతుంది?

network_mode: service:gluetun ను కూడా సెట్ చేసిన service లో ports: block ఇంకా ఉండటం వల్ల ఈ సందేశం వస్తుంది. Port publish చేయడం ద్వారా host port నుంచి container యొక్క స్వంత network namespace కు forward చేసే NAT rule జోడించబడుతుంది. అయితే ఈ mode లోని container కు స్వంత network namespace ఉండదు. ఆ service నుంచి ports: block ను తొలగించి, అదే mapping ను gluetun service కు జోడించండి. Application shared namespace లో అదే port పై ఇంకా listening చేస్తుంది కాబట్టి port number మారదు.

gluetun వెనుక ఉన్న service ను ఇతర containers ఎలా చేరుకుంటాయి?

అదే namespace లోని containers ఒకదానినొకటి 127.0.0.1 వద్ద చేరుకుంటాయి. బయట ఉన్న containers gluetun service name ను ఉపయోగించాలి. అందువల్ల http://gluetun:8080 పనిచేస్తుంది, కానీ http://qbittorrent:8080 పనిచేయదు. Application container ఏ Docker network పైనా address కలిగి ఉండదు. కాబట్టి embedded DNS server దాని పేరు కోసం resolve చేయడానికి ఏదీ కలిగి ఉండదు. రెండు containers ఒకే Compose network పంచుకుంటే దీనికి port publishing అవసరం లేదు.

FIREWALL_OUTBOUND_SUBNETS లో ఏమి పెట్టాలి?

gluetun వెనుక ఉన్న container connection ప్రారంభించాల్సిన addresses మాత్రమే పెట్టాలి. వాటిని సాధ్యమైనంత నిర్దిష్టంగా రాయాలి. ఒకే machine కోసం /32 ఉపయోగించాలి. సాధారణంగా ఉపయోగించే రెండు entries Docker host కోసం 172.17.0.1/32, మీరు సంప్రదించే ప్రతి Tailscale peer కోసం ఒక /32. 0.0.0.0/0 ను ఎప్పుడూ జోడించవద్దు. మీ VPN యొక్క స్వంత tunnel addresses తో overlap అయ్యే range ను కూడా జోడించవద్దు. Published port కు వచ్చే inbound connections కోసం ఇక్కడ entry అవసరం లేదు.

Container నా Tailscale MagicDNS names ను resolve చేయలేకపోవడానికి కారణం ఏమిటి?

Host యొక్క resolver ను Tailscale DNS server వైపు చూపించడం ద్వారా MagicDNS పనిచేస్తుంది. అయితే container host యొక్క resolver ను ఉపయోగించదు. అది తన స్వంత /etc/resolv.conf లో ఉన్న విలువను ఉపయోగిస్తుంది. gluetun వెనుక ఉన్నప్పుడు ఇది gluetun యొక్క DNS setup అవుతుంది. docker exec <container> cat /etc/resolv.conf తో నిర్ధారించండి. Peer యొక్క numeric 100.x address ను ఉపయోగించండి. లేదా ఆ container పై extra_hosts entry తో name ను స్థిరంగా map చేయండి.

Traffic ఇంకా VPN ద్వారా వెళ్తోందని ఎలా నిర్ధారించాలి?

Namespace లోపల ఒక request ను run చేయండి. అదే request ను host నుంచీ run చేసి, వచ్చిన answers ను పోల్చండి. docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org మీ VPN provider యొక్క exit address ను చూపాలి. VPS పై curl -s https://api.ipify.org VPS address ను చూపాలి. రెండు answers ఒకేలా ఉంటే tunnel container traffic ను మోసుకెళ్లడం లేదు. FIREWALL_OUTBOUND_SUBNETS లో ప్రతి మార్పు తర్వాత ఈ తనిఖీని మళ్లీ run చేయండి.

#gluetun #docker #docker-compose #tailscale #networking #vpn