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 नंतर कुठेही निर्देश करू शकत नाही। प्रकाशित मॅपिंग आणि बाइंड पत्ता लिहून ठेवा, म्हणजे पुढील पुनर्बांधणी पुन्हा तपासणी न होता दोन मिनिटांची तपासणी होईल।