Meshnet, Docker और बीच की अनुमति

दो URL पीयर के ब्राउज़र से एक जैसे दिख सकते हैं और फ़ायरवॉल के लिए बिल्कुल अलग बातें मान सकते हैं। एक ऐसी सेवा की ओर इशारा करता है जो होस्ट पर ही सुन रही है। दूसरा ऐसे होस्ट पते की ओर इशारा करता है जिसका पोर्ट कंटेनर नेटवर्क में प्रकाशित है, जहाँ अनुवाद का एक चरण कनेक्शन को दूसरी IP को सौंप देता है। पीयर-टू-पीयर मेश में, जो हर पीयर के लिए अनुमति से स्थानीय नेटवर्क पहुँच नियंत्रित करता है, वही अंतर पूरी समीक्षा है।

अनुमति होस्ट के अंतिम बिंदु के बारे में है, अनुवाद Docker के बारे में है, और लॉगिन एप्लिकेशन के बारे में है। तीन निर्णय, देखने के तीन स्थान।

प्रकाशन के बाद गंतव्य का पालन करें

ऐसा Linux Docker होस्ट लें जो कंटेनर का पोर्ट 80 होस्ट के पोर्ट 8080 पर प्रकाशित करता है। एक पीयर 8080 पर होस्ट के मेश पते से जुड़ता है, होस्ट कनेक्शन स्वीकार करता है, और गंतव्य का अनुवाद उसे कंटेनर के ब्रिज पते की ओर फिर से लिखता है, आम तौर पर 172.17.0.2 जैसा कुछ, पोर्ट 80 पर।

जब कोई नियम उस प्रवाह की जाँच करता है, तब रोचक गंतव्य कंटेनर है, होस्ट नहीं। जो नीति केवल «इस मशीन पर एक सेवा» के बारे में सोचती है, वह गलत वस्तु के बारे में सोचती है। अनुरोध होस्ट पर उतरा, परंतु उसे कहीं और पहुँचाया जा रहा है।

इसीलिए मेश का दस्तावेज़ीकरण Docker कंटेनरों को उन संसाधनों में गिनता है जिन्हें Linux पर स्थानीय नेटवर्क अनुमति नियंत्रित करती है। अनुमति सामान्य VPN अनुमति सूची की प्रविष्टि का पर्याय नहीं है, और दोनों नियंत्रण एक-दूसरे का स्थान नहीं लेते। एक तय करता है कि पीयर स्थानीय संसाधनों तक पहुँच सकता है या नहीं; दूसरा तय करता है कि टनल मार्ग कौन-से गंतव्य ले जाता है।

तय करें कि एक अनुमति कितनी स्थानीय पहुँच देती है

पीयर को स्थानीय नेटवर्क पहुँच देना एक ही कंटेनर का निर्णय नहीं है। यह उसी होस्ट पर अन्य प्रकाशित सेवाओं को उजागर कर सकता है, और होस्ट कैसे अग्रेषित करता है उसके आधार पर और दूर तक पहुँच सकता है। एक डैशबोर्ड के लिए स्विच दबाने से पहले प्रभावी दायरे की समीक्षा करें।

फिर देखें कि Docker पोर्ट कहाँ प्रकाशित करता है। 0.0.0.0 पर प्रकाशन हर होस्ट पते पर एक श्रोता बनाता है, जो मेश प्रविष्टि के साथ-साथ एक सामान्य LAN प्रविष्टि जोड़ सकता है। यदि आवश्यकता केवल मेश है, तो प्रकाशन को उस विशिष्ट पते या इंटरफ़ेस से बाँधें जो आप चाहते हैं, और व्यापक बंधन को सुविधा नहीं बल्कि अलग निष्कर्ष मानें।

होस्ट की अग्रेषण नीति और एप्लिकेशन का अपना प्रमाणीकरण सेवा के लिए पर्याप्त संकीर्ण रखें। निजी दिखने वाला URL पहुँच नियंत्रण नहीं है, और जो कंटेनर अपने ब्रिज नेटवर्क के हर स्रोत पर भरोसा करता है वह मेश पीयर के स्वीकृत होने से सुरक्षित नहीं होता। एप्लिकेशन का प्रमाणीकरण तीसरा निर्णय है, और वही एकमात्र जानता है कि उपयोगकर्ता कौन है। होस्ट-स्तर की अनुमति वह ज्ञान नहीं दे सकती।

अनुमति जाँचें, केवल URL नहीं

स्वीकृत पीयर से ठीक उसी सेवा को खोलें और पुष्टि करें कि वह काम करती है। फिर ऐसे गंतव्य का प्रयास करें जो अस्वीकृत ही रहना चाहिए और पुष्टि करें कि वह काम नहीं करता। केवल सुखद मार्ग जाँचना आपको बताता है कि अनुमति दी गई; यह नहीं बताता कि सीमा वहीं है जहाँ आप सोचते हैं।

होस्ट-मूल सेवा की अलग से तुलना करें। यदि डेटाबेस होस्ट पर सुन रहा है और डैशबोर्ड कंटेनर में चल रहा है, तो वे एक ही अनुमति से अलग-अलग मार्ग लेते हैं और होस्ट की अग्रेषण नीति उन्हें समान रूप से नियंत्रित नहीं कर सकती। समीक्षा टिप्पणी लिखने से पहले दर्ज करें कि कौन-सा क्या है।

पहुँच «रीसेट» करने के लिए Docker की तालिकाएँ या मेश क्लाइंट के नियम खाली न करें। दोनों उत्पाद अपना नीति एकीकरण स्थापित करते हैं, और उसे मिटाने से ऐसा होस्ट बनता है जो काम करता दिखता है जबकि उन नियंत्रणों को बायपास करता है जिन्हें आपको मूल्यांकन करने के लिए कहा गया था। यदि कोई नियम गलत लगे, तो उसे पढ़ें और केवल उसी नियम को बदलें। यदि आप समझा नहीं सकते कि कोई नियम क्या करता है, तो वही निष्कर्ष है, उसे हटाने का कारण नहीं।

निष्कर्ष को सिस्टम की अपनी शब्दावली में लिखें

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

होस्ट का पता, प्रकाशित पोर्ट, कंटेनर का गंतव्य और पीयर की अनुमति एक ही वाक्य में बताएँ। वह वाक्य किसी और द्वारा जाँचा जा सकता है, और यही उसे राय के बजाय निष्कर्ष बनाता है।