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 पछि कतै निर्देश नगर्न सक्छ। प्रकाशित म्यापिङ र बाइन्ड ठेगाना लेख्नुहोस्, ताकि अर्को पुनर्निर्माण फेरि अनुसन्धान होइन, दुई मिनेटको जाँच होस्।