VPN कंटेनर के अंदर वेब इंटरफ़ेस तक पहुँचें: पोर्ट का मालिक चुनें

ऐप में कुछ गलत नहीं है और टनल में कुछ गलत नहीं है, फिर भी डैशबोर्ड लोड नहीं होता। जब कोई सेवा network_mode: service:vpn के साथ चलती है, तो वह VPN कंटेनर का नेटवर्क नेमस्पेस साझा करती है, यानी उसका लिसनर और उसके प्रकाशित पोर्ट उस नेमस्पेस के हैं, सेवा के नहीं। इससे तीन फ़ैसले निकलते हैं: ऐप कहाँ बँधता है, कौन सा कंटेनर पोर्ट प्रकाशित करता है, और प्रबंधन का रास्ता कितना संकरा है। इन्हें गलत क्रम में करें और हर अलग सेटिंग सही दिखेगी, जबकि मेल नहीं चल सकता।

पोर्ट नेमस्पेस का मालिक कौन है

साझा नेमस्पेस में निर्भर सेवा में ports: प्रविष्टि जोड़ने से कोई लाभ नहीं होता, और कई नेटवर्किंग विकल्प डिज़ाइन से ही उसके लिए समर्थित नहीं हैं। इसके बजाय उस कंटेनर पर प्रकाशित करें जो नेमस्पेस का मालिक है। वही कंटेनर वह भी है जिसका पता होस्ट पर दिखता है, इसलिए मैपिंग एक प्रविष्टि के रूप में पढ़ी जाती है, प्रति सेवा एक नहीं।

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

मैपिंग के बाईं ओर के पते पर ध्यान दें। 127.0.0.1 पर बाँधने से प्रकाशित पोर्ट होस्ट के लूपबैक पर रहता है, जो आम तौर पर प्रबंधन इंटरफ़ेस चाहता है। 0.0.0.0 पर बाँधने से वह होस्ट के हर इंटरफ़ेस पर खुल जाता है, और यह सुविधा नहीं, अलग सुरक्षा निर्णय है।

ऐप को वहाँ सुनने दें जहाँ नेमस्पेस उम्मीद करता है

नेमस्पेस के भीतर 127.0.0.1 पर बँधा लिसनर केवल उसी नेमस्पेस के भीतर से पहुँचा जा सकता है। प्रकाशित होस्ट पोर्ट बाहर से आते हैं, इसलिए मैपिंग काम करने के लिए ऐप को व्यापक पता बाँधना पड़ता है। यह अधिकांश सर्वरों में एक पंक्ति का बदलाव है, और यही वह कदम है जो लोग बिना कंटेनर वाली तैनाती के लिए लिखी गई हार्डनिंग गाइड कॉपी करने के बाद छोड़ देते हैं।

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

ऐप के भीतर लिसनर सूची बाइंड पते के बारे में सच बताती है, और docker port बताता है कि मालिक ने वास्तव में क्या प्रकाशित किया। अगर पहला 127.0.0.1 दिखाए और दूसरा होस्ट मैपिंग दिखाए, तो आपने VPN कॉन्फ़िगरेशन छुए बिना ही असंगति पा ली।

तय करें कि प्रबंधन का रास्ता कैसे अंदर आए

तीन उचित व्यवस्थाएँ हैं। VPN कंटेनर पर प्रकाशित करें और होस्ट या लोकल नेटवर्क से वहाँ पहुँचें। नेमस्पेस के सामने रिवर्स प्रॉक्सी रखें और प्रॉक्सी को एकमात्र खुला पोर्ट दें। या डैशबोर्ड को केवल नेमस्पेस के भीतर से exec सत्र या SSH टनल के ज़रिए पहुँचने योग्य रखें, जो सबसे कम जोखिम और सबसे कम सुविधा है।

कौन सा ठीक है यह इस पर निर्भर है कि इंटरफ़ेस किसे और कहाँ से चाहिए। एक ही होस्ट पर अकेले व्यवस्थापक के लिए लूपबैक बाइंडिंग काफ़ी है। VPN के ज़रिए पहुँचने वाली टीम को सोचा-समझा रास्ता और नामित मालिक चाहिए। प्रॉक्सी विकल्प चुनने पर आपको TLS और एक्सेस लॉग मिलते हैं, पर एक और घटक अद्यतित रखना पड़ता है।

सब कुछ खोले बिना प्रबंधन पोर्ट खोलें

VPN क्लाइंट की अपनी लोकल-एक्सेस या लॉकडाउन नीति आने वाला प्रबंधन अनुरोध गिरा सकती है, तब भी जब बाहर जाती टनल बिल्कुल ठीक चल रही हो। इच्छित स्रोत और पोर्ट के लिए एक प्रलेखित अपवाद की अनुमति दें, फिर पुष्टि करें कि टनल की सामान्य सुरक्षा अपरिवर्तित है। डैशबोर्ड लोड कराने के लिए किल स्विच बंद करना ब्राउज़र टैब के बदले एक असली नियंत्रण खोना है।

ऐप का अपना प्रमाणीकरण चालू रखें। VPN से जुड़े स्टैक के भीतर होना हर स्थानीय उपयोगकर्ता या होस्ट तक पहुँच सकने वाले हर उपकरण को अधिकृत नहीं करता, और टनल के पीछे बिना प्रमाणीकरण वाला एडमिन पैनल अब भी बिना प्रमाणीकरण वाला एडमिन पैनल है।

प्रबंधन डिवाइस से जाँचें, फिर बाद में दोबारा जाँचें

उस मशीन से परखें जो वास्तव में सेवा का प्रबंधन करेगी, होस्ट से नहीं, और फिर ऐप के ज़रूरी इंटरनेट मार्ग को अलग से जाँचें। प्रबंधन की सफलता एक दिशा साबित करती है और बाहर जाने के बारे में कुछ नहीं कहती।

स्टैक फिर से बनने के बाद दोबारा परखें। बदला हुआ नेटवर्क मालिक उस नेमस्पेस को बदल देता है जिससे ऐप जुड़ता है, और अपडेट से पहले चला URL बाद में कहीं इंगित नहीं कर सकता। प्रकाशित मैपिंग और बाइंड पता लिख लें ताकि अगली पुनर्निर्माण दोबारा जाँच न होकर दो मिनट की पड़ताल हो।