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 चा वापर केला आहे, त्यामुळे तुमच्याकडे प्रोव्हायडरचे खाते आणि की (key) असणे आवश्यक आहे. जर तुम्हाला टनेल तुमच्या मालकीच्या हार्डवेअरवर टर्मिनेट करायचा असेल, तर VPS वर स्वतःचा WireGuard सर्व्हर चालवणे हा पर्याय दुसऱ्या बाजूला सेटअप तयार करतो आणि Docker मधील wg-easy त्याला वेब इंटरफेसमध्ये गुंफते.

network_mode: "service:gluetun" नक्की काय करते

प्रत्येक Docker container ला सामान्यतः स्वतःचे network namespace मिळते: स्वतःचे interfaces, routing table, firewall नियम आणि listening sockets. service: मोड ही पायरी वगळतो आणि container ला gluetun च्या namespace मध्ये सुरू करतो. एक namespace म्हणजे एक IP address, आणि यामुळे सहा गोष्टी बदलतात.

• ॲपचा स्वतःचा कोणताही address नसतो. त्याचा address gluetun चा address असतो.
• ॲप कोणत्याही Docker network ला जोडलेले नसते, त्यामुळे त्याचे service name कधीही register होत नाही आणि कधीही resolve होत नाही. इतर containers नी gluetun वापरणे आवश्यक आहे.
• एकाच namespace मधील containers एकमेकांशी localhost द्वारे संपर्क साधतात.
• एकाच namespace मधील दोन containers एकाच port वर listen करू शकत नाहीत. Gluetun चे documentation याबद्दल स्पष्ट आहे: यावर कोणताही उपाय नाही.
• Capabilities या container च्या असतात, namespace च्या नसतात. Gluetun कडे NET_ADMIN आणि /dev/net/tun असतात कारण ते tunnel interface तयार करते. जोडलेले container त्यांना वारसाहक्काने मिळवत नाही.
• जर एखाद्या service ने network_mode आणि networks दोन्ही सेट केले असतील, तर Compose अशी फाईल नाकारते. Gluetun ला तुमच्या networks ला जोडा, आणि ॲप त्यासोबत कार्य करेल.

Gluetun रीस्टार्ट केल्यामुळे त्याला जोडलेले सर्व काही डिस्कनेक्ट होते. हे दस्तऐवजीकरण केलेले वर्तन आहे आणि कनेक्शन अयशस्वी झाल्यावर बाहेर पडण्याऐवजी gluetun कंटेनरमधील VPN प्रक्रिया रीस्टार्ट करते, याचे हेच कारण आहे. तुम्ही स्वतः gluetun रीस्टार्ट किंवा पुन्हा तयार केल्यानंतर, त्याला जोडलेले containers रीस्टार्ट करा.

कार्यरत असलेले 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 टॅग हा master ब्रँचच्या शेवटच्या कमिटला दर्शवतो, जो डेव्हलपमेंटचा भाग आहे. त्यामुळे ज्या मशीनवर तुम्हाला त्रुटी शोधायच्या (debug) नाहीत, तिथे :v3 चा वापर करा.

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 प्रोव्हायडरचा ॲड्रेस असणे आवश्यक आहे. जर तिथे तुमच्या सर्व्हरचा स्वतःचा ॲड्रेस दिसत असेल, तर ॲप टनेलच्या बाहेर आहे आणि खालीलपैकी कोणतीही गोष्ट अपेक्षेप्रमाणे काम करणार नाही.

कीज (keys) compose फाईलच्या बाहेर ठेवा

gluetun.env मध्ये क्रेडेंशियल्स असतात आणि ती git मध्ये समाविष्ट केली जात नाहीत:

WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU=
WIREGUARD_ADDRESSES=10.64.222.21/32

दोन्ही व्हॅल्यूज तुमच्या प्रोव्हायडरच्या अकाउंट एरियामध्ये तयार केलेल्या WireGuard कॉन्फिगरेशन फाईलमधून मिळतात. या फाईलचा मोड 600 वर सेट करा. यामुळे काय फायदा होतो हे स्पष्टपणे समजून घ्या: की (key) तुमच्या रिपॉझिटरीच्या बाहेर राहते, परंतु ज्याला Docker socket चा ॲक्सेस आहे, अशी कोणतीही व्यक्ती docker inspect gluetun वापरून सर्व environment variables पाहू शकते. Environment files and secrets in Docker Compose मध्ये अधिक सुरक्षित पर्यायांची माहिती दिली आहे.

टनेलच्या बाहेरील कंटेनर टनेलच्या आतील कंटेनरशी कसा संवाद साधतो

दोन्ही दिशांनी संवाद शक्य आहे आणि प्रत्येक दिशेसाठी वेगळ्या नावाचा वापर केला जातो. दोन्ही कंटेनरना एका सामायिक Docker network ची आवश्यकता असते, ज्याचा अर्थ gluetun चे नेटवर्क असा होतो, कारण जोडलेल्या कंटेनरचे स्वतःचे कोणतेही नेटवर्क नसते. Docker Compose नेटवर्क्स कसे जोडले जातात मध्ये डीफॉल्ट सेटिंग्जची माहिती दिली आहे.

बाहेरून आत येताना, gluetun चे नाव आणि ज्या पोर्टवर ॲप ऐकत आहे (listens) त्याचा वापर करा. एक रिव्हर्स प्रॉक्सी कंटेनर qBittorrent वेब इंटरफेसपर्यंत gluetun:8080 द्वारे पोहोचतो. त्यासाठी कोणत्याही ports: एन्ट्रीची आवश्यकता नसते, कारण कंटेनर-टू-कंटेनर ट्रॅफिक Docker network वरच राहते आणि ते कधीही होस्ट पोर्टला स्पर्श करत नाही.

आतल्या बाजूने बाहेर जाताना, दुसऱ्या कंटेनरच्या सर्व्हिस नावाचा वापर करा, उदाहरणार्थ postgres:5432. v3.41 पासून gluetun ने त्याच्या नेमस्पेसच्या आतून इतर कंटेनरची नावे रिझॉल्व्ह करण्यास सुरुवात केली आहे, त्यामुळे जर नाव रिझॉल्व्ह होत नसेल तर ती आवृत्ती किंवा त्यापेक्षा नवीन आवृत्ती वापरा.

gluetun चा फायरवॉल ठरवतो की कोण त्याला कनेक्शन उघडू शकते. gluetun च्या स्वतःच्या Docker network कडून येणारे ट्रॅफिक स्वीकारले जाते. वेगळ्या सबनेटवरील क्लायंट, तुमच्या LAN वरील लॅपटॉप किंवा वेगळ्या ब्रिज नेटवर्कवरील कंटेनरचे ट्रॅफिक, जोपर्यंत तुम्ही त्या सबनेटचे नाव देत नाही, तोपर्यंत ड्रॉप केले जाते:

FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24

याचा अर्थ स्पष्ट आहे: स्वल्पविरामाने वेगळे केलेले सबनेट, ज्यांना Gluetun आणि त्याचे नेटवर्क स्टॅक शेअर करणारे कंटेनर ॲक्सेस करू शकतात.

इंटरनेटवरून येणारी इनबाउंड कनेक्शन्स ही एक वेगळी समस्या आहे. टोरेंट क्लायंटचे पीअर्स (peers) VPN बाजूने येतात, त्यामुळे होस्टवर पोर्ट 6881 पब्लिश केल्याने त्यांना काहीही फायदा होत नाही. तुम्हाला तुमच्या प्रोव्हायडरकडून फॉरवर्ड केलेले पोर्ट आवश्यक आहे आणि ते पोर्ट FIREWALL_VPN_INPUT_PORTS मध्ये सूचीबद्ध असणे आवश्यक आहे, जे VPN सर्व्हरच्या बाजूने पोर्ट्सना परवानगी देते. हा तो भाग आहे जो Docker Compose सह तयार केलेले मीडिया स्टॅक्स अनेकदा अपूर्ण ठेवतात.

किल स्विच: टनेल बंद पडल्यावर काय होते

जेव्हा टनेल बंद पडते, तेव्हा ही रचना तिच्या गुंतागुंतीचे फळ देते. जोडलेल्या कंटेनरकडे दुसरा कोणताही मार्ग नसतो. मशीनबाहेर जाण्यासाठी त्याच्याकडे फक्त तोच नेमस्पेस (namespace) असतो जो तो शेअर करतो, त्यामुळे टनेल बंद असताना परत जाण्यासाठी कोणताही पर्याय उरत नाही. Gluetun चा फायरवॉल दुसऱ्या बाजूनेही हाच नियम लागू करतो: आउटबाउंड ट्रॅफिक एकतर टनेलद्वारे किंवा VPN सर्व्हर एंडपॉईंटकडे जाते आणि बाकी सर्व काही ड्रॉप केले जाते. क्लायंट पुन्हा कनेक्ट होत असताना पॅकेट्स साध्या इंटरफेसद्वारे लीक होण्याची कोणतीही शक्यता नसते.

Gluetun स्वतःच्या कनेक्शनवर लक्ष ठेवते. दर मिनिटाला ते HEALTH_ICMP_TARGET_IPS मधील पत्त्यांवर एक ICMP echo (पिंग) पाठवते, जे डीफॉल्टनुसार 1.1.1.1,8.8.8.8 असतात. दर पाच मिनिटांनी ते HEALTH_TARGET_ADDRESSES वर पूर्ण TCP आणि TLS (transport layer security) डायल करते, जे डीफॉल्टनुसार 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 चे अंतर्गत 'auto-healing' हे प्रकरण हाताळते, म्हणूनच ते कंटेनरऐवजी VPN प्रक्रिया रीस्टार्ट करते.

सेटअपवर विश्वास ठेवण्यापूर्वी DNS लीक तपासा

DNS (domain name system) हा असा लीक आहे जो योग्य टनेल असूनही टिकून राहतो. Gluetun स्वतःच्या नेमस्पेसमध्ये स्वतःचा रिझॉल्व्हर चालवते आणि डीफॉल्टनुसार Cloudflare कडे DoT (DNS over TLS) द्वारे क्वेरी फॉरवर्ड करते: 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 वर आधारित एक ओव्हरले नेटवर्क आहे, ज्याचा वापर स्वतःच्या मशीनशी संपर्क साधण्यासाठी केला जातो. ॲडमिनिस्ट्रेशनसाठी एक मार्ग उपलब्ध असावा म्हणून अनेक लोक ते VPN प्रोव्हायडरसोबत चालवतात. हे दोन्ही सहसा एकमेकांच्या कामात अडथळा आणत नाहीत, याचे कारण समजून घेणे महत्त्वाचे आहे. Tailscale च्या डॉक्युमेंटेशननुसार, ते एक ओव्हरले नेटवर्क म्हणून काम करते, फक्त Tailscale चालू असलेल्या उपकरणांमधील ट्रॅफिक राउट करते आणि तुमच्या सार्वजनिक इंटरनेट ट्रॅफिकला स्पर्श करत नाही.

त्यामुळे याचे उत्तर एका सेटिंगवर अवलंबून आहे.

• Tailscale स्वतःच्या कंटेनरमध्ये, डीफॉल्ट कॉन्फिगरेशनसह: हे ॲपचे आउटबाउंड ट्रॅफिक पाहत नाही. Gluetun सर्व ट्रॅफिक हाताळते. Tailscale इतर कोणत्याही बाह्य कंटेनरप्रमाणेच ॲपपर्यंत gluetun:8080 द्वारे पोहोचते.
• Tailscale ला network_mode: "service:gluetun" वापरून gluetun च्या नेमस्पेसशी जोडल्यास: याला स्वतःचे cap_add, net_admin आणि net_raw आवश्यक असतात, कारण नेमस्पेससोबत हे अधिकार मिळत नाहीत. डीफॉल्ट युजरस्पेस नेटवर्किंग मोडमध्ये, TS_USERSPACE चालू असताना tailscaled कोणतेही इंटरफेस तयार करत नाही आणि SOCKS5 किंवा HTTP प्रॉक्सी म्हणून काम करते, त्यामुळे ते राउटिंग बदलू शकत नाही. Gluetun अजूनही सर्व ट्रॅफिक हाताळते.
• तसेच, TS_USERSPACE=false सह: tailscaled एक टनेल डिव्हाइस तयार करते आणि राउट्स इन्स्टॉल करते, परंतु ते फक्त tailnet रेंज 100.64.0.0/10 आणि तुम्ही TS_ROUTES द्वारे जाहिरात केलेल्या सबनेट राउट्ससाठी असते. सार्वजनिक ट्रॅफिक अजूनही gluetun द्वारेच बाहेर जाते.
• वरीलपैकी कोणत्याही पर्यायात एक्झिट नोड निवडल्यास, sudo tailscale set --exit-node=<exit-node-ip>: Tailscale डीफॉल्ट राउटवर ताबा मिळवते आणि प्रभावी ठरते. हे gluetun सोबत वापरू नका. एक डीफॉल्ट राउट, एकच मालक.

जर जाहिरात केलेले राउट्स (advertised routes) महत्त्वाचे असतील आणि तुम्हाला फक्त बॉक्सच नाही तर संपूर्ण खाजगी नेटवर्कपर्यंत पोहोचायचे असेल, तर VPS वर Tailscale सबनेट राउटर चालवणे या लेखात राउट अप्रूव्हल, IP फॉरवर्डिंग आणि क्लायंट-साइड फ्लॅगची माहिती दिली आहे, जी TS_ROUTES स्वतःहून पूर्ण करत नाही.

जर Tailscale चा वापर राउटऐवजी ॲडमिन URL मिळवण्यासाठी असेल, तर tailscale serve आणि tailscale funnel तुमच्या tailnet साठी gluetun:8080 च्या पुढे HTTPS सेट करतात, ज्यामध्ये फक्त फनेलद्वारे ते सार्वजनिक इंटरनेटसाठी खुले केले जाते.

जेव्हा Tailscale टनेलच्या आत चालते तेव्हा एक परिणाम दिसून येतो. त्याचे पीअर्स VPN प्रोव्हायडरचा पत्ता पाहतात, त्यामुळे ते अधिक वेळा रिलेवर अवलंबून राहण्याची शक्यता असते. जेव्हा असे घडते, तेव्हा tailscale status मध्ये पीअरच्या बाजूला direct ऐवजी relay "..." दिसते. कनेक्शन काम करते पण ते संथ असते. जर तुम्हाला फक्त ओव्हरलेचीच गरज असेल, तर plain WireGuard आणि Tailscale मधील फरक हा अधिक चांगला पर्याय आहे.

काय बिघडते आणि तुम्हाला कोणता संदेश दिसेल

Docker ॲप कंटेनर तयार करण्यास नकार देते. Error response from daemon: conflicting options: port publishing and the container type network mode चा अर्थ असा आहे की ports: ब्लॉक अजूनही संलग्न सेवेवर आहे. त्याला gluetun वर हलवा.

Compose संपूर्ण फाईल स्वीकारण्यास नकार देते. एखादी सेवा एकाच वेळी network_mode आणि networks सेट करू शकत नाही. नेटवर्क्स gluetun वर ठेवा.

दुसरा कंटेनर ॲपला रिझॉल्व्ह (resolve) करू शकत नाही. curl: (6) Could not resolve host: qbittorrent ही योग्य वर्तणूक आहे, कारण संलग्न कंटेनर कोणत्याही नेटवर्कमध्ये सामील झाला नाही आणि कोणतेही नाव नोंदवले नाही. gluetun आणि पोर्ट वापरा.

दुसरा संलग्न कंटेनर सुरू होत नाही. एकाच नेमस्पेसमध्ये दोन प्रक्रिया एकाच पोर्टला बाइंड (bind) होऊ शकत नाहीत आणि जो अयशस्वी होतो तो पत्ता आधीच वापरात असल्याचे सूचित करतो. ॲपचा अंतर्गत पोर्ट बदला किंवा दुसरा gluetun चालवा.

तुम्ही gluetun ला स्पर्श केल्यानंतर ॲपकडे नेटवर्क नाही. gluetun रीस्टार्ट किंवा पुन्हा तयार केल्यामुळे त्याला जोडलेल्या प्रत्येक गोष्टीची कनेक्टिव्हिटी तुटते. ते कंटेनर रीस्टार्ट करा.

लहान पेजेस लोड होतात आणि मोठी पेजेस हँग होतात. हे MTU (maximum transmission unit) मुळे घडते. टनेल ओव्हरहेड वाढवते आणि मार्गातील काही घटक त्रुटी न पाठवता मोठे पॅकेट्स ड्रॉप करतात. WIREGUARD_MTU कमी करा, 1400 वापरून पहा, त्यानंतर 1320 वापरून पहा.

Gluetun कधीही हेल्दी (healthy) होत नाही. स्टार्टअप चेक पहिल्या संशयितांची नावे सांगतो: WARN [vpn] restarting VPN because it failed to pass the healthcheck: startup check: dialing: dial tcp4: lookup cloudflare.com: i/o timeout. की (key) कालबाह्य झाली आहे का ते तपासा, त्यानंतर सर्व्हर लिस्ट जुनी झाली आहे का ते तपासा आणि शेवटी तुमचा होस्ट फायरवॉल आउटबाउंड UDP ब्लॉक करत आहे का ते तपासा.

FAQ

Gluetun च्या मागे माझ्या कंटेनरचे पब्लिश केलेले पोर्ट्स का काम करत नाहीत?

कारण network_mode: "service:gluetun" कंटेनरला Gluetun च्या नेटवर्क नेमस्पेसमध्ये ठेवते आणि एका नेमस्पेसमध्ये फक्त एक IP ॲड्रेस आणि लिसनिंग पोर्ट्सचा एक संच असतो. ॲप लिसनिंग सुरू ठेवते, परंतु पब्लिश नियम त्या कंटेनरवर असणे आवश्यक आहे ज्याच्याकडे नेमस्पेसची मालकी आहे. ports: यादी Gluetun सर्व्हिसवर हलवा. जर तुम्ही ती अटॅच्ड सर्व्हिसवर तशीच ठेवली, तर Docker ती तयारच करणार नाही: Error response from daemon: conflicting options: port publishing and the container type network mode.

VPN टनेलच्या आतील कंटेनरपर्यंत मी बाहेरील कंटेनरवरून कसा पोहोचू शकतो?

Gluetun चे सर्व्हिस नाव आणि ॲप ज्या पोर्टवर लिसन करते त्याचा वापर करा, उदाहरणार्थ gluetun:8080. अटॅच्ड कंटेनरचे स्वतःचे कोणतेही Docker नेटवर्क नसते, त्यामुळे त्याचे नाव कधीही रिझॉल्व्ह होत नाही. कंटेनर-टू-कंटेनर ट्रॅफिकसाठी काहीही पब्लिश करण्याची गरज नसते. उलट दिशेने, नेमस्पेसच्या आतील कंटेनर बाहेरील कंटेनरपर्यंत त्याच्या सर्व्हिस नावाने पोहोचू शकतो, जसे की Gluetun v3.41 आणि नवीन आवृत्त्यांवर postgres:5432. वेगळ्या सबनेटवरील क्लायंट, जसे की तुमच्या LAN वरील लॅपटॉप, याचे ट्रॅफिक Gluetun च्या फायरवॉलद्वारे ड्रॉप केले जाते, जोपर्यंत तुम्ही ते सबनेट FIREWALL_OUTBOUND_SUBNETS मध्ये जोडत नाही.

VPN ड्रॉप झाल्यावर Gluetun 'kill switch' म्हणून काम करते का?

हो, आणि एकाच वेळी दोन कारणांमुळे. अटॅच्ड कंटेनरकडे शेअर केलेल्या नेमस्पेसव्यतिरिक्त दुसरा कोणताही मार्ग (route) नसतो, त्यामुळे टनेल बंद पडल्यास त्याला मशीनबाहेर जाण्यासाठी कोणताही मार्ग उरत नाही. तसेच, Gluetun ची फायरवॉल केवळ टनेलद्वारे आणि VPN सर्व्हर एंडपॉईंटकडेच आउटबाउंड ट्रॅफिकला परवानगी देते. Gluetun स्वतः बंद होण्याऐवजी अंतर्गत रितीने VPN रीस्टार्ट करते आणि WARN [vpn] restarting VPN because it failed to pass the healthcheck लॉग करते, कारण Gluetun रीस्टार्ट झाल्यावर सर्व अटॅच्ड कंटेनर्सचे नेटवर्क कनेक्शन तुटते.

एकाच स्टॅकमध्ये Tailscale आणि Gluetun असल्यास, आउटबाउंड ट्रॅफिक कशाद्वारे जाते?

एका अपवाद वगळता, सर्व कॉन्फिगरेशनमध्ये Gluetun द्वारेच ट्रॅफिक जाते. Tailscale डीफॉल्टनुसार फक्त तुमच्या tailnet मधील उपकरणांमध्ये ट्रॅफिक राउट करते आणि सार्वजनिक ट्रॅफिकला धक्का लावत नाही. कंटेनर इमेजच्या डीफॉल्ट युजरस्पेस मोडमध्ये ते कोणतेही इंटरफेस तयार करत नाही, त्यामुळे ते राउटिंगवर परिणाम करू शकत नाही. TS_USERSPACE=false सह ते फक्त 100.64.0.0/10 आणि तुमच्या जाहिरात केलेल्या (advertised) सबनेट्ससाठी राउट्स इन्स्टॉल करते. अपवाद म्हणजे एक्झिट नोड: sudo tailscale set --exit-node=<exit-node-ip> मुळे Tailscale डीफॉल्ट राउट बनते आणि मग ते प्रभावी ठरते. दोन्ही एकत्र वापरण्याऐवजी, डीफॉल्ट राउटसाठी एकाच उत्पादनाची निवड करा.