Meshnet, Docker र तिनीहरूबीचको अनुमति

दुई URL पियरको ब्राउजरबाट एउटै देखिन सक्छन् तर फायरवालका लागि पूर्ण रूपमा फरक कुरा अर्थाउन सक्छन्। एउटाले होस्टमै सुनिरहेको सेवालाई संकेत गर्छ। अर्कोले पोर्ट कन्टेनर नेटवर्कमा प्रकाशित भएको होस्ट ठेगानालाई संकेत गर्छ, जहाँ अनुवादको चरणले जडान अर्को IP लाई सुम्पन्छ। प्रत्येक पियरका लागि अनुमतिले स्थानीय नेटवर्क पहुँच नियन्त्रण गर्ने पियर-टु-पियर मेसमा, त्यही भिन्नता सम्पूर्ण समीक्षा हो।

अनुमति होस्टको अन्तिम बिन्दुको बारेमा हो, अनुवाद Docker को बारेमा हो, र लगइन अनुप्रयोगको बारेमा हो। तीन निर्णय, हेर्ने तीन ठाउँ।

प्रकाशनपछि गन्तव्यलाई पछ्याउनुहोस्

कन्टेनरको पोर्ट 80 होस्टको पोर्ट 8080 मा प्रकाशित गर्ने Linux Docker होस्ट लिनुहोस्। एक पियर 8080 मा होस्टको मेस ठेगानामा जोडिन्छ, होस्टले जडान स्वीकार गर्छ, र गन्तव्यको अनुवादले यसलाई कन्टेनरको ब्रिज ठेगानातर्फ, सामान्यतया 172.17.0.2 जस्तो केही, पोर्ट 80 मा पुनः लेख्छ।

जब कुनै नियमले त्यो प्रवाह जाँच्छ, रोचक गन्तव्य कन्टेनर हो, होस्ट होइन। «यो मेसिनमा रहेको सेवा» मात्र विचार गर्ने नीतिले गलत वस्तुको बारेमा विचार गर्छ। अनुरोध होस्टमा अवतरण भयो, तर यो अन्तै पुर्‍याइँदै छ।

त्यसैले मेसको कागजातले Docker कन्टेनरहरूलाई Linux मा स्थानीय नेटवर्क अनुमतिले नियन्त्रण गर्ने स्रोतहरूमा सूचीबद्ध गर्छ। अनुमति सामान्य VPN अनुमति सूचीको प्रविष्टिको समानार्थी होइन, र दुई नियन्त्रणहरू एकअर्काको विकल्प होइनन्। एउटाले पियर स्थानीय स्रोतहरूमा पुग्न सक्छ कि भनेर निर्णय गर्छ; अर्कोले सुरुङ मार्गले कुन गन्तव्यहरू बोक्छ भनेर निर्णय गर्छ।

अनुमतिले कति स्थानीय पहुँच दिन्छ भनेर निर्णय गर्नुहोस्

पियरलाई स्थानीय नेटवर्क पहुँच दिनु एउटै कन्टेनरको निर्णय होइन। यसले त्यही होस्टमा प्रकाशित अन्य सेवाहरू खुलाउन सक्छ, र होस्टले कसरी अगाडि पठाउँछ भन्ने आधारमा अझ टाढा पुग्न सक्छ। एउटा ड्यासबोर्डका लागि स्विच थिच्नु अघि प्रभावकारी दायराको समीक्षा गर्नुहोस्।

त्यसपछि Docker ले पोर्ट कहाँ प्रकाशित गर्छ हेर्नुहोस्। 0.0.0.0 मा प्रकाशनले प्रत्येक होस्ट ठेगानामा श्रोता सिर्जना गर्छ, जसले मेस प्रविष्टिको छेउमा सामान्य LAN प्रविष्टि थप्न सक्छ। यदि आवश्यकता मेस मात्र हो भने, प्रकाशनलाई तपाईंले चाहेको निर्दिष्ट ठेगाना वा इन्टरफेसमा बाँध्नुहोस्, र फराकिलो बाँधाइलाई सुविधा नभई छुट्टै निष्कर्ष मान्नुहोस्।

होस्टको अगाडि पठाउने नीति र अनुप्रयोगको आफ्नै प्रमाणीकरणलाई सेवाका लागि पर्याप्त साँघुरो राख्नुहोस्। निजी देखिने URL पहुँच नियन्त्रण होइन, र आफ्नो ब्रिज नेटवर्कको प्रत्येक स्रोतमा भरोसा गर्ने कन्टेनर मेस पियर स्वीकृत भएकै कारण सुरक्षित हुँदैन। अनुप्रयोगको प्रमाणीकरण तेस्रो निर्णय हो, र प्रयोगकर्ता को हो भन्ने जान्ने एक मात्र निर्णय। होस्ट-स्तरको अनुमतिले त्यो ज्ञान दिन सक्दैन।

अनुमति परीक्षण गर्नुहोस्, URL मात्र होइन

स्वीकृत पियरबाट ठ्याक्कै त्यही सेवा खोल्नुहोस् र यो चल्छ भनी पुष्टि गर्नुहोस्। त्यसपछि अस्वीकृत रहनुपर्ने गन्तव्य प्रयास गर्नुहोस् र यो चल्दैन भनी पुष्टि गर्नुहोस्। केवल सुखद मार्ग परीक्षण गर्दा अनुमति दिइयो भन्ने थाहा हुन्छ; सीमा तपाईंले सोचेको ठाउँमै छ भन्ने थाहा हुँदैन।

होस्टको मौलिक सेवालाई अलग्गै तुलना गर्नुहोस्। यदि डाटाबेस होस्टमा सुनिरहेको छ र ड्यासबोर्ड कन्टेनरमा चलिरहेको छ भने, तिनीहरू एउटै अनुमतिबाट फरक मार्ग लिन्छन् र होस्टको अगाडि पठाउने नीतिले तिनीहरूलाई समान रूपमा नियन्त्रण नगर्न सक्छ। समीक्षा टिप्पणी लेख्नु अघि कुन कुन हो लेख्नुहोस्।

पहुँच «रिसेट» गर्न Docker का तालिका वा मेस क्लाइन्टका नियम खाली नगर्नुहोस्। दुवै उत्पादनले आफ्नै नीति एकीकरण स्थापना गर्छन्, र त्यो मेट्दा मूल्याङ्कन गर्न भनिएका नियन्त्रणहरू बाइपास गर्दै काम गरेको जस्तो देखिने होस्ट बन्छ। नियम गलत देखिन्छ भने पढ्नुहोस् र त्यही नियम मात्र परिवर्तन गर्नुहोस्। नियमले के गर्छ भनेर व्याख्या गर्न सक्नुहुन्न भने त्यही निष्कर्ष हो, त्यो मेट्ने कारण होइन।

निष्कर्षलाई प्रणालीकै शब्दावलीमा लेख्नुहोस्

महत्त्वपूर्ण कुरा उत्पादनले वास्तवमै लागू गर्ने भेद हो, समीक्षा टेम्प्लेटमा रहेको होइन: होस्टको अन्तिम बिन्दुमा पुग्ने अनुमति, मार्गनिर्देशित निजी स्रोतहरूमा पुग्ने अनुमति, र अनुप्रयोग प्रयोग गर्ने अनुमति। पोर्ट प्रकाशित गर्दा ती तीन निर्णय जहाँ थिए त्यहीँ रहन्छन्, र तिनलाई एउटै मान्ने समीक्षकले गलत दायरा स्वीकृत गर्नेछ।

होस्टको ठेगाना, प्रकाशित पोर्ट, कन्टेनरको गन्तव्य र पियरको अनुमति एउटै वाक्यमा भन्नुहोस्। त्यो वाक्य अरू कसैले परीक्षण गर्न सक्छ, र त्यसैले यो राय नभई निष्कर्ष बन्छ।