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 चे तक्ते किंवा मेश क्लायंटचे नियम रिकामे करू नका। दोन्ही उत्पादने स्वतःचे धोरण एकत्रीकरण स्थापित करतात, आणि ते पुसल्यास मूल्यांकन करण्यास सांगितलेली नियंत्रणे बायपास करताना कार्यरत दिसणारा होस्ट तयार होतो। नियम चुकीचा वाटल्यास तो वाचा आणि तोच नियम बदला। नियम काय करतो हे स्पष्ट करता येत नसेल, तर तोच निष्कर्ष आहे, तो हटवण्याचे कारण नाही।

निष्कर्ष सिस्टमच्याच परिभाषेत लिहा

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

होस्टचा पत्ता, प्रकाशित पोर्ट, कंटेनरचे गंतव्य आणि पीअरची परवानगी एकाच वाक्यात सांगा। ते वाक्य दुसऱ्या कोणी तपासू शकते, आणि त्यामुळेच तो मत न होता निष्कर्ष ठरतो।