Gluetun कंटेनरमध्ये पोर्ट आणि नेटवर्क ॲक्सेस कसा द्यावा?

जेव्हा एखादा कंटेनर gluetun च्या नेटवर्कमध्ये सामील होतो तेव्हा काय होते

जो कंटेनर network_mode: service:gluetun सेट करतो, त्याचे स्वतःचे कोणतेही नेटवर्क इंटरफेस नसतात. तो gluetun च्या नेटवर्क नेमस्पेसमध्ये सामील होतो, त्यामुळे पोर्ट पब्लिशिंग आणि फायरवॉलचे नियम त्या कंटेनरचे गुणधर्म न राहता gluetun सेवेचे गुणधर्म बनतात. खालील प्रत्येक उत्तर याच एका तथ्यावर आधारित आहे.

नेटवर्क नेमस्पेस म्हणजे कर्नलची नेटवर्क स्टॅकची खाजगी प्रत: त्याचे स्वतःचे इंटरफेस, स्वतःचे राउटिंग टेबल, स्वतःचे फायरवॉल नियम आणि स्वतःचे लिसनिंग सॉकेट्स. Docker डीफॉल्टनुसार प्रत्येक कंटेनरला एक नेमस्पेस देते. जेव्हा तुम्ही network_mode: service:gluetun लिहिता, तेव्हा Docker ती पायरी वगळते आणि नवीन कंटेनरला gluetun च्या मालकीच्या नेमस्पेसमध्ये ठेवते. कंटेनर आपली स्वतःची फाईलसिस्टम आणि स्वतःची /etc/hosts फाईल कायम ठेवतो, आणि ही दुसरी गोष्ट नंतर महत्त्वाची ठरते.

तुम्ही हे थेट पाहू शकता.

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

हे container: आणि त्यानंतर gluetun कंटेनर ID प्रिंट करते, जिथे सामान्य कंटेनर bridge प्रिंट करेल. हे मार्गदर्शक gluetun सह VPN द्वारे Docker ट्रॅफिक राउट करणे जिथे संपते तिथून पुढे सुरू होते: टनेल काम करत आहे, आणि आता कंटेनरशी कोणीही संवाद साधू शकत नाही.

gluetun वर पोर्ट पब्लिश करा, ॲप्लिकेशनवर नको

सेवेवर ports: ब्लॉक तसाच ठेवा जो network_mode सेट करतो, आणि Docker कंटेनर तयार करण्यास नकार देईल:

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

याचे कारण स्पष्ट आहे. पोर्ट पब्लिश करणे म्हणजे एक NAT (network address translation) नियम जोडणे, जो होस्ट पोर्टला कंटेनरच्या स्वतःच्या नेटवर्क नेमस्पेसमध्ये फॉरवर्ड करतो, आणि या कंटेनरकडे तशी नेमस्पेस नसते. मॅपिंग gluetun सेवेवर हलवा. पोर्ट नंबर बदलत नाही, कारण ॲप्लिकेशन अजूनही त्या सामायिक नेमस्पेसमध्ये त्याच पोर्टवर लिसन करत आहे.

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

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

डिपेंडंट सेवेवरील expose: ब्लॉक देखील निरर्थक आहे आणि तिथे असलेला networks: ब्लॉक तर थेट अडथळा ठरतो: Compose रिपोर्ट करते की सेवा परस्परविरोधी network_mode आणि networks घोषित करत आहे, आणि फाईल लोड करण्यास पूर्णपणे नकार देते.

याचा एक परिणाम नंतर जाणवतो. नेमस्पेस मधील प्रत्येक कंटेनर एकच पोर्ट स्पेस शेअर करतो, त्यामुळे दोन ॲप्लिकेशन्स जे दोन्ही डीफॉल्टनुसार 8080 वर चालतात, ते एकमेकांवर आदळतात (collide). परिणामी, दुसरे ॲप्लिकेशन सुरू होताना 'address already in use' अशी त्रुटी येते. त्यापैकी एकाचे कॉन्फिगरेशन बदला, उदाहरणार्थ LinuxServer qBittorrent इमेजवरील WEBUI_PORT व्हेरिएबल बदला, आणि त्यानंतर नवीन नंबर gluetun वर पब्लिश करा.

gluetun च्या मागे असलेले कंटेनर एकमेकांशी कसे संपर्क साधतात?

नेमस्पेसच्या आत ते आधीच एक लूपबॅक इंटरफेस शेअर करतात. gluetun च्या मागे असलेला कंटेनर त्याच्या सोबती कंटेनरशी 127.0.0.1:<port> वर संपर्क साधतो, ज्यामध्ये कोणत्याही Docker नेटवर्कचा वापर होत नाही.

नेमस्पेसच्या बाहेरून पाहिल्यास, त्या कंटेनरला कोणतेही नाव नसते. Docker चे एम्बेडेड DNS एखाद्या सर्व्हिसचे नाव वापरकर्त्याने परिभाषित केलेल्या नेटवर्कवरील त्या सर्व्हिसच्या पत्त्यावर रिझॉल्व्ह करते, परंतु या कंटेनरचा कोणत्याही नेटवर्कवर पत्ता नसतो. त्यामुळे Sonarr सारखा सामान्य कंटेनर torrent क्लायंटपर्यंत http://qbittorrent:8080 द्वारे पोहोचू शकत नाही. तो त्यापर्यंत http://gluetun:8080 द्वारे पोहोचतो, कारण सॉकेट gluetun च्या नेमस्पेसमध्ये आणि gluetun च्या पत्त्यावर लिसन करत असतो. ज्यांना Docker Compose नेटवर्क्स आणि सर्व्हिस नेम्स कसे काम करतात हे माहित आहे आणि जे नेहमीच्या नेमिंग पद्धतीची अपेक्षा करतात, त्यांना हे आश्चर्यकारक वाटते. हे होस्टवर काहीही पब्लिश न करता देखील काम करते, कारण दोन्ही कंटेनर एकाच Compose नेटवर्कवर असतात.

इतर कशाचेही डीबगिंग करण्यापूर्वी DNS तपासा. gluetun स्वतःचा रिझॉल्व्हर चालवते आणि स्वतःच्या कंटेनरमध्ये /etc/resolv.conf पुन्हा लिहिते, परंतु /etc/resolv.conf ही फाईल प्रति कंटेनर असते, त्यामुळे gluetun ने लिहिलेली फाईल आणि तुमच्या ॲप्लिकेशनने वाचलेली फाईल वेगळी असते.

docker exec qbittorrent cat /etc/resolv.conf

Docker host वर चालणाऱ्या सर्व्हिसपर्यंत कसे पोहोचायचे?

host.docker.internal वापरा. यासाठी दोन वेगवेगळ्या ठिकाणी दोन सेटिंग्ज कराव्या लागतात, कारण दोन वेगवेगळ्या गोष्टींमध्ये त्रुटी असते.

प्रथम नाव येते. /etc/hosts हे प्रति कंटेनर असते, म्हणून extra_hosts एन्ट्री gluetun वर नसून ॲप्लिकेशन कंटेनरवर असणे आवश्यक आहे.

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

host-gateway हे एक विशेष मूल्य आहे, ज्याला Docker होस्टच्या अंतर्गत पत्त्याने बदलतो. सामान्य Linux Docker इन्स्टॉलवर तो docker0 ब्रिजचा पत्ता असतो, जो सहसा 172.17.0.1 असतो. VPS वर ip -4 addr show docker0 वापरून तुमचा पत्ता तपासा. Docker Desktop हे नाव स्वतःहून रिझॉल्व्ह करते, म्हणूनच लॅपटॉपवर लिहिलेल्या गाईड्समध्ये extra_hosts ओळ वगळलेली असते आणि तीच फाईल सर्व्हरवर वापरल्यास अपयशी ठरते.

दुसरे म्हणजे राउट. फक्त नाव जोडल्याने कंटेनरला कोणता पत्ता वापरायचा हे समजते. पॅकेट अजूनही gluetun च्या डीफॉल्ट राउटद्वारे, म्हणजेच टनेलद्वारे बाहेर पडते आणि gluetun चा फायरवॉल ते ड्रॉप करतो. याचे लक्षण म्हणजे कनेक्शन हँग होणे आणि नंतर टाइम-आउट होणे, न की कनेक्शन नाकारले जाणे. नाकारले जाणे (refusal) म्हणजे पॅकेट पोहोचले आणि समोरून 'नाही' असे उत्तर आले. टाइम-आउट म्हणजे पॅकेट कधीच पोहोचले नाही.

  gluetun:
    environment:
      - FIREWALL_OUTBOUND_SUBNETS=172.17.0.1/32

त्यानंतर, होस्ट सर्व्हिस खरोखर त्या पत्त्यावर लिसन (listen) करत आहे का ते तपासा. फक्त 127.0.0.1 वर बाइंड केलेली PostgreSQL सर्व्हर कोणत्याही कंटेनरवरून पोहोचण्यायोग्य नसते, मग टनेल असो वा नसो, कारण नेमस्पेसच्या आत 127.0.0.1 हे त्या नेमस्पेसचे स्वतःचे लूपबॅक असते. त्याऐवजी त्याला 172.17.0.1 वर बाइंड करा: यामुळे ते सार्वजनिक इंटरफेसवर न राहता कंटेनरकडून येणारी कनेक्शन्स स्वीकारते. होस्टवर ss -lntp | grep 5432 वापरून याची खात्री करा.

FIREWALL_OUTBOUND_SUBNETS नक्की काय बदल करते

gluetun दस्तऐवजीकरणानुसार, हे स्वल्पविरामाने (comma) वेगळे केलेले सबनेट्स आहेत ज्यांना gluetun आणि त्याचे नेटवर्क स्टॅक वापरणारे कंटेनर्स ॲक्सेस करू शकतात. यात फायरवॉल आणि राउटिंगमधील बदलांचा समावेश होतो, हे लक्षात घेणे महत्त्वाचे आहे. दोन्ही गोष्टी महत्त्वाच्या आहेत. gluetun प्रत्येक सूचीबद्ध सबनेटसाठी Docker ब्रिज गेटवेद्वारे एक राउट जोडते, त्यामुळे त्या पत्त्यांसाठीचे पॅकेट्स टनेलऐवजी eth0 वरून बाहेर पडतात. हे त्यांच्यासाठी फायरवॉल देखील उघडते, कारण अन्यथा gluetun VPN सर्व्हरकडे न जाणारा आउटबाउंड ट्रॅफिक ड्रॉप करते.

ही व्हॅल्यू लिहिताना स्वल्पविरामानंतर कोणतीही स्पेस देऊ नका.

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

दोन गोष्टींकडे दुर्लक्ष होण्याची शक्यता असते. ही एक नेमस्पेस लेव्हल सेटिंग आहे, त्यामुळे ती फक्त तुमच्या विचारात असलेल्या कंटेनरलाच नाही, तर gluetun च्या मागे असलेल्या प्रत्येक कंटेनरला लागू होते. आणि हे फक्त आउटबाउंडसाठी आहे: हे कंटेनरद्वारे सुरू होणाऱ्या कनेक्शन्सवर नियंत्रण ठेवते. पब्लिश केलेल्या पोर्टवर येणारी कनेक्शन्स वेगळ्या मार्गाने येतात आणि त्यासाठी येथे कोणत्याही एन्ट्रीची आवश्यकता नसते.

Tailscale पीअरवरून वेब UI पर्यंत पोहोचणे

Tailscale प्रत्येक मशीनला 100.64.0.0/10 मधील एक पत्ता देते, जो carrier grade NAT साठी राखीव असलेला रेंज आहे. दोन्ही दिशांना काम करण्यासाठी वेगवेगळ्या पद्धतींची आवश्यकता असते.

इनबाउंड (Inbound) प्रक्रिया सोपी आहे. gluetun वर 8080:8080 पब्लिश केल्यामुळे तो पोर्ट होस्टच्या सर्व पत्त्यांवर बाइंड होतो आणि होस्टचा tailscale0 इंटरफेस त्यापैकी एक असतो, त्यामुळे पीअर http://<machine-name>:8080 उघडून कंटेनरपर्यंत पोहोचू शकतो. या मार्गामध्ये gluetun ची कोणतीही भूमिका नसते, कारण Docker चा NAT नियम होस्टवर, नेमस्पेसच्या बाहेर असतो.

UI फक्त tailnet वरूनच उपलब्ध व्हावा यासाठी, पब्लिश केलेला पोर्ट प्रत्येक पत्त्यावर बाइंड करण्याऐवजी फक्त होस्टच्या Tailscale पत्त्यावर बाइंड करा.

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

होस्टवर tailscale ip -4 वापरून तो पत्ता शोधा. येथे बाइंडिंग करणे हे फायरवॉल नियमापेक्षा अधिक प्रभावी नियंत्रण आहे, कारण पोर्ट सार्वजनिक इंटरफेसवर कधीच उघडला जात नाही. हे Docker द्वारे पोर्ट पब्लिश केल्यामुळे ufw बायपास होणे या समस्येवरही उपाय ठरते.

आउटबाउंड (Outbound) प्रक्रियेत FIREWALL_OUTBOUND_SUBNETS पुन्हा येते. जर कंटेनरला एखाद्या पीअरला कॉल करायचा असेल, तर त्या पीअरचा पत्ता जोडा आणि संपूर्ण /10 ऐवजी प्रत्येक पीअरसाठी /32 वापरणे अधिक श्रेयस्कर आहे. MagicDNS नावे कंटेनरच्या आत रिझॉल्व्ह होणार नाहीत, कारण कंटेनर होस्टचा रिझॉल्व्हर वापरत नाही. त्यामुळे अंकीय 100.x पत्ता वापरा किंवा extra_hosts ओळीद्वारे तो पिन करा. जेव्हा तुम्ही तुमचा स्वतःचा Tailscale कंट्रोल सर्व्हर Headscale सह चालवता, तेव्हाही हेच लागू होते.

सामान्य रचनेसाठी एक पूर्ण compose फाईल

VPN च्या मागे असलेला एक डाउनलोड क्लायंट, फक्त tailnet वर प्रतिसाद देणारी दोन वेब UI, आणि होस्टवर चालणाऱ्या PostgreSQL डेटाबेसवरून माहिती वाचणारा एक कंटेनर.

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

उत्पादनांच्या नावांपेक्षा त्यातील पॅटर्न समजून घेण्यासाठी फाईल वाचा. दोन्ही UI gluetun वर पब्लिश केले आहेत आणि ते होस्टच्या tailnet ॲड्रेसला बाइंड केलेले आहेत, त्यामुळे ते फक्त Tailscale वरच प्रतिसाद देतात. फक्त Prowlarr मध्ये extra_hosts ओळ आहे, कारण Prowlarr हा असा कंटेनर आहे जो host.docker.internal रिझॉल्व्ह करतो. FIREWALL_OUTBOUND_SUBNETS दोन स्वतंत्र ॲड्रेस दर्शवते: होस्टचा Docker bridge ॲड्रेस, जेणेकरून Prowlarr डेटाबेस कनेक्शन उघडू शकेल, आणि एक tailnet पीअर.

PostgreSQL सर्व्हर मुद्दाम फाईलमधून वगळला आहे. तो VPS वर एक सामान्य सिस्टम सर्व्हिस म्हणून 172.17.0.1:5432 वर चालतो. ही रचना Docker Compose वरील arr स्टॅक प्रमाणेच आहे, फक्त डेटाबेस Docker च्या बाहेर ठेवला आहे.

WireGuard प्रायव्हेट की compose फाईलमध्ये ठेवू नका. ${WIREGUARD_PRIVATE_KEY} त्याच्या शेजारी असलेल्या .env फाईलमधून माहिती वाचते, हा पॅटर्न Docker Compose साठी env फाईल्स आणि सीक्रेट्स मध्ये दिला आहे. condition: service_healthy क्लॉज gluetun इमेजमध्ये आधीपासून असलेल्या healthcheck चा वापर करतो, त्यामुळे टनेल सुरू झाल्याची खात्री झाल्याशिवाय काहीही सुरू होत नाही. Compose healthchecks मध्ये याचे सामान्य स्वरूप स्पष्ट केले आहे.

    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 प्रोव्हायडरचा exit पत्ता दर्शवेल. दुसरी विनंती VPS चा पत्ता दर्शवेल. जर हे पत्ते जुळत असतील, तर कंटेनरचे ट्रॅफिक टनलमधून जात नाहीये, आणि जोपर्यंत हे दुरुस्त होत नाही तोपर्यंत या मार्गदर्शिकेतील इतर उपाय निरर्थक आहेत.

राउटिंग टेबल टनलमधून काय जात आहे आणि काय नाही, हे दर्शवते.

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

डिफॉल्ट राउट टनल इंटरफेस, tun0 कडे निर्देशित असावा. त्याच्या खाली तुम्हाला FIREWALL_OUTBOUND_SUBNETS मधील प्रत्येक एन्ट्रीसाठी एक राउट दिसेल, जो Docker ब्रिज गेटवेकडे निर्देशित असेल. eth0 द्वारे जाणारा कोणताही इतर राउट म्हणजे असे ट्रॅफिक आहे जे VPN ला वगळते.

Gluetun चा कंट्रोल सर्व्हर /v1/publicip/ip वर, पोर्ट 8000 वर तोच सार्वजनिक IP दर्शवतो. अलीकडील आवृत्त्यांमध्ये कंट्रोल सर्व्हर राउट्ससाठी ऑथेंटिकेशन कॉन्फिगर करणे आवश्यक आहे, त्यामुळे त्यावर अवलंबून राहण्यापूर्वी ते सेट करा.

चुकीच्या सबनेटमुळे होणारी गळती

FIREWALL_OUTBOUND_SUBNETS हे तुम्ही मुद्दाम फायरवॉलमध्ये पाडलेले एक छिद्र आहे, त्यामुळे या छिद्राचा आकार म्हणजे तुमच्या जोखमीचा आकार होय. ते खूप मोठे करण्याचे चार मार्ग खालीलप्रमाणे आहेत:

• 0.0.0.0/0 सर्व ट्रॅफिक टनेलच्या बाहेर पाठवते. वरील दोन IP तपासण्या पहिल्या रनमध्येच हे पकडतात, कारण त्या दोन्ही वेळा समान पत्ता दर्शवतात.
• लक्ष्यापेक्षा मोठी रेंज. 10.0.1.7 वरील एका मशीनपर्यंत पोहोचण्यासाठी 10.0.0.0/8 उघडल्यास, त्या रेंजमध्ये एखादा टॉरेंट पीअर (torrent peer) जाहिरात करू शकणारा प्रत्येक पत्ता उघडला जातो. 10.0.1.7/32 लिहा.
• टनेलच्या स्वतःच्या पत्त्यांशी ओव्हरलॅप होणारी रेंज. gluetun डॉक्युमेंटेशन असा इशारा देते की यामुळे gluetun VPN ट्रॅफिक ब्रिजद्वारे बाहेर पाठवते, ज्यामुळे पोर्ट फॉरवर्डिंग खंडित होते. कोणतीही खाजगी रेंज उघडण्यापूर्वी तुमचे WIREGUARD_ADDRESSES मूल्य तपासा.
• Tailscale साठी 100.64.0.0/10. याचा अर्थ असा की एका पीअरपर्यंत पोहोचण्यासाठी सुमारे चाळीस लाख पत्ते उघडले जातात. तुम्हाला आवश्यक असलेले पीअर्स /32 एन्ट्रीज म्हणून सूचीबद्ध करा.

लक्षात ठेवा की ही सेटिंग संपूर्ण नेमस्पेस कव्हर करते. इंडेक्सरला (indexer) एखाद्या होस्ट सर्व्हिसपर्यंत पोहोचता यावे म्हणून सबनेट उघडल्यास, त्याच नेमस्पेसमध्ये काम करणाऱ्या टॉरेंट क्लायंटसाठीही तेच सबनेट उघडले जाते. या व्हेरिएबलमध्ये प्रत्येक बदल केल्यानंतर पब्लिक IP तपासणी पुन्हा करा, कारण तुम्ही केलेला बदल अपेक्षेप्रमाणे झाला आहे की नाही हे दर्शवणारी ही एकमेव चाचणी आहे.

gluetun रीस्टार्ट केल्यावर काय बिघडते

gluetun हे नेटवर्क नेमस्पेसचे नियंत्रण करते, त्यामुळे gluetun चे जीवनचक्र हेच त्या नेमस्पेसचे जीवनचक्र असते. gluetun बंद असताना त्यावर अवलंबून असलेला कंटेनर सुरू करण्याचा प्रयत्न केल्यास तो त्वरित अपयशी ठरतो:

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

gluetun ला आहे त्याच स्थितीत रीस्टार्ट करणे ही एक शांतपणे घडणारी चूक आहे. अवलंबून असलेले कंटेनर चालू राहतात, परंतु ज्या नेमस्पेसला ते जोडलेले होते, ती त्यांच्या खालून पुन्हा तयार केली जाते. परिणामी, docker ps सर्व काही व्यवस्थित असल्याचे दर्शवते, पण प्रत्यक्षात कोणतीही सेवा प्रतिसाद देत नाही. gluetun सर्व्हिसमध्ये कोणताही बदल केल्यानंतर, केवळ एक भाग रीस्टार्ट करण्याऐवजी संपूर्ण गट (group) पुन्हा तयार करा.

docker compose up -d --force-recreate

हेच नियम इमेज अपडेट्सनाही लागू होतात. gluetun ची नवीन इमेज पुल करून फक्त ती एक सर्व्हिस पुन्हा तयार केल्यास, इतर कंटेनर अशा नेमस्पेसकडे निर्देश करत राहतात जी आता अस्तित्वात नाही.

FAQ

Docker "port publishing and the container type network mode" असे का म्हणते?

कारण ports: ब्लॉक अजूनही अशा सर्व्हिसवर आहे जी network_mode: service:gluetun देखील सेट करते. पोर्ट पब्लिश केल्यामुळे एक NAT नियम तयार होतो जो होस्ट पोर्टला कंटेनरच्या स्वतःच्या नेटवर्क नेमस्पेसमध्ये फॉरवर्ड करतो, आणि या मोडमधील कंटेनरकडे असा नेमस्पेस नसतो. त्या सर्व्हिसमधून ports: ब्लॉक काढून टाका आणि तीच मॅपिंग gluetun सर्व्हिसमध्ये जोडा. पोर्ट नंबर तोच राहतो, कारण ॲप्लिकेशन अजूनही त्या सामायिक नेमस्पेसमध्ये त्याच पोर्टवर लिसन करत असते.

gluetun च्या मागे असलेल्या सर्व्हिसपर्यंत इतर कंटेनर कसे पोहोचतात?

एकाच नेमस्पेसमध्ये असलेले कंटेनर एकमेकांपर्यंत 127.0.0.1 द्वारे पोहोचतात. त्याबाहेरील कंटेनर gluetun सर्व्हिसचे नाव वापरतात, त्यामुळे जिथे http://qbittorrent:8080 काम करत नाही तिथे http://gluetun:8080 काम करते. ॲप्लिकेशन कंटेनरकडे कोणत्याही Docker नेटवर्कवर पत्ता नसतो, त्यामुळे एम्बेडेड DNS सर्व्हरकडे त्याच्या नावासाठी रिझॉल्व्ह करण्यासारखे काहीही नसते. जोपर्यंत दोन्ही कंटेनर एक सामायिक Compose नेटवर्क वापरतात, तोपर्यंत यासाठी पोर्ट पब्लिश करण्याची गरज नसते.

FIREWALL_OUTBOUND_SUBNETS मध्ये मी काय टाकावे?

केवळ ते पत्ते ज्यांच्याशी gluetun च्या मागे असलेल्या कंटेनरने कनेक्शन सुरू करणे आवश्यक आहे, ते शक्य तितक्या मर्यादित स्वरूपात लिहा. एक सिंगल मशीन म्हणजे /32. दोन सामान्य एन्ट्रीज म्हणजे 172.17.0.1/32 वरील Docker होस्ट आणि तुम्ही कॉल करत असलेल्या प्रत्येक Tailscale पीअरसाठी एक /32. कधीही 0.0.0.0/0 जोडू नका आणि तुमच्या VPN च्या स्वतःच्या टनेल पत्त्यांशी ओव्हरलॅप होणारी रेंज कधीही देऊ नका. पब्लिश केलेल्या पोर्टवर येणाऱ्या इनबाउंड कनेक्शनसाठी येथे कोणत्याही एन्ट्रीची गरज नसते.

कंटेनर माझे Tailscale MagicDNS नावे रिझॉल्व्ह का करू शकत नाही?

MagicDNS होस्टचा रिझॉल्व्हर Tailscale च्या DNS सर्व्हरकडे पॉइंट करून काम करते, आणि कंटेनर होस्टचा रिझॉल्व्हर वापरत नाही. तो स्वतःच्या /etc/resolv.conf मध्ये जे सांगितले आहे ते वापरतो, जे gluetun च्या मागे gluetun चे DNS सेटअप असते. docker exec <container> cat /etc/resolv.conf वापरून याची खात्री करा. पीअरचा अंकीय 100.x पत्ता वापरा, किंवा त्या कंटेनरवर extra_hosts एन्ट्री वापरून नाव पिन करा.

ट्रॅफिक अजूनही VPN मधून जात आहे हे मी कसे तपासावे?

नेमस्पेसच्या आतून एक विनंती (request) करा आणि होस्टवरून तीच विनंती करा, त्यानंतर उत्तरे तपासा. docker run --rm --network=container:gluetun curlimages/curl:latest -s https://api.ipify.org ने तुमच्या VPN प्रोव्हायडरचा एक्झिट पत्ता दर्शवला पाहिजे, तर VPS वरील curl -s https://api.ipify.org ने VPS चा पत्ता दर्शवला पाहिजे. जर दोन्ही उत्तरे जुळत असतील, तर याचा अर्थ टनेल कंटेनरचे ट्रॅफिक वाहून नेत नाहीये. FIREWALL_OUTBOUND_SUBNETS मध्ये प्रत्येक बदल केल्यानंतर ही तपासणी पुन्हा करा.