Nebula लाइटहाउस फ़िल्टर बनाम फ़ायरवॉल: हर एक क्या रोकता है

गलत छोर से Nebula हैंडशेक देखें और दोनों तंत्र एक-दूसरे के विकल्प लगते हैं। एक तय करता है कि नोड लाइटहाउस को कौन-से पते बताएगा और कौन-से दूरस्थ पते आज़माएगा; दूसरा तय करता है कि सुरंग बनने के बाद क्या पार हो सकता है। कोई फ़ायरवॉल नियम आँके जाने से पहले ही फ़िल्टर किसी कनेक्शन को रोक सकता है, और कोई फ़ायरवॉल नियम उस एंडपॉइंट को फिर से जीवित नहीं कर सकता जिसे खोज ने हटा दिया। दोनों परतें अलग सवालों के जवाब देती हैं, और वे जिस क्रम में काम करती हैं वही कुंजी है।

एक कनेक्शन को चार चरणों में देखें: घोषित स्थानीय पता, विचाराधीन दूरस्थ एंडपॉइंट, हैंडशेक और ओवरले ट्रैफ़िक। हर चरण का अपना कॉन्फ़िगरेशन और अपना विफलता-चिह्न है।

उस स्थानीय पते से शुरू करें जिसकी घोषणा नोड करता है

local_allow_list लाइटहाउस को रिपोर्ट किए जाने से पहले इस होस्ट के स्थानीय पतों को फ़िल्टर करता है। प्रविष्टियाँ पता-श्रेणियाँ हो सकती हैं, और कॉन्फ़िगरेशन इंटरफ़ेस-नाम पैटर्न भी समर्थित करता है। यह तब उपयोगी है जब होस्ट में कंटेनर ब्रिज या अतिरिक्त सुरंग इंटरफ़ेस हों जिन्हें पीयर एंडपॉइंट नहीं बनना चाहिए।

होस्ट के इंटरफ़ेस देखें और पूछें कि दूरस्थ पीयर वास्तव में किन तक पहुँच सकता है। Docker ब्रिज पता उस होस्ट के लिए स्थानीय है और दूसरे नेटवर्क के पीयर के लिए बेकार है। उसे घोषित करना खोज को बर्बाद करता है और पीयर को ऐसे पते की ओर भेज सकता है जो कभी उत्तर नहीं देता। जिस तक पीयर रूट नहीं कर सकता वह लाइटहाउस के उत्तर में केवल शोर है।

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

फिर दूरस्थ एंडपॉइंट के चयन को देखें

remote_allow_list हैंडशेक के दौरान यह होस्ट दूरस्थ पीयर के लिए जिन पतों पर विचार करेगा उन्हें फ़िल्टर करता है। यह अंडरले पते पर लागू होता है, सुरंग बनने के बाद पीयर जिस ओवरले पते का उपयोग करेगा उस पर नहीं।

एक निजी श्रेणी साझा कार्यालय नेटवर्क में पूरी तरह उपयोगी हो सकती है और तब अर्थहीन हो जाती है जब दोनों होस्ट असंबद्ध नेटवर्क में हों जो दोनों 10.0.0.0/8 का उपयोग करते हैं। फ़िल्टर आपको रूट होने योग्य मार्ग को प्राथमिकता देने और संयोग को अनदेखा करने देता है।

जब पीयर जुड़ न पाए, तो जिस पते को आज़माया जा रहा है उसकी तुलना उससे मेल खाने वाले नियम से करें। हैंडशेक लॉग चालू करें और चुना गया दूरस्थ पता पढ़ें; लॉग पंक्ति उस एंडपॉइंट का नाम बताती है जो फ़िल्टरिंग से बचा, और यह पीयर के पास मौजूद पतों की सूची से अधिक उपयोगी है।

घोषणा करने वाली ओर का इंटरफ़ेस-नाम फ़िल्टर एंडपॉइंट को तब हटा सकता है जब प्राप्त करने वाली ओर ने उसे देखा भी न हो। जब केवल एक दिशा विफल हो तो दोनों नोड जाँचें।

हैंडशेक के बाद ओवरले के पहुँच नियम लागू होते हैं

Nebula फ़ायरवॉल नियम ओवरले के भीतर, सुरंग बनने के बाद काम करते हैं। वे होस्ट, समूह, पोर्ट और प्रोटोकॉल मिलाते हैं, और तय करते हैं कि पैकेट स्थानीय होस्ट में प्रवेश कर सकता है या उससे बाहर निकल सकता है। वे अंडरले एंडपॉइंट नहीं चुनते।

यह अलगाव एक आम गलत निदान को समझाता है। ऑपरेटर किसी पोर्ट के लिए फ़ायरवॉल नियम जोड़ता है और फिर भी जुड़ नहीं पाता, क्योंकि लाइटहाउस फ़िल्टर ने एकमात्र पहुँचने योग्य एंडपॉइंट हटा दिया था। दूसरा ऑपरेटर पता फ़िल्टर खोलता है और फिर भी सेवा तक नहीं पहुँचता, क्योंकि ओवरले का फ़ायरवॉल पोर्ट को अस्वीकार करता है।

विफलता को सही परत पर पढ़ें। जो हैंडशेक कभी पूरा नहीं होता वह खोज, एंडपॉइंट फ़िल्टरिंग या नेटवर्क मार्ग की ओर संकेत करता है। पूरा हुआ हैंडशेक और उसके बाद अस्वीकृत या छोड़ा गया सेवा कनेक्शन ओवरले के फ़ायरवॉल या एप्लिकेशन की ओर संकेत करता है।

अनुमति और निषेध मिलाते समय डिफ़ॉल्ट पढ़ें

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

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

डिफ़ॉल्ट को नियम का हिस्सा मानें, बॉयलरप्लेट नहीं। यदि परिवार का डिफ़ॉल्ट निषेध है, तो सूची में न दिया गया हर पता बाहर रहता है, जिसमें कॉन्फ़िगरेशन लिखे जाने के बाद जोड़ी गई नई कार्यालय श्रेणी भी शामिल है।

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

जब कोई सीधा एंडपॉइंट पहुँच योग्य न हो तो रिले का उपयोग करें

यदि हर उम्मीदवार एंडपॉइंट फ़िल्टर हो जाए या पहुँच से बाहर हो, तो उत्तर ऐसी चौड़ी अनुमति-सूची नहीं है जो उन पतों को फिर स्वीकार करे जिन पर आप भरोसा नहीं करते। जब सीधी कनेक्टिविटी व्यावहारिक न हो तो Nebula का रिले कॉन्फ़िगरेशन वैकल्पिक पीयर मार्ग देता है।

रिले परिवहन और खोज सुलझाता है, प्राधिकरण नहीं, और यह फ़ायरवॉल को चौड़ा नहीं करता। ओवरले का फ़ायरवॉल अब भी तय करता है कि कौन-सी सेवाएँ उपयोग हो सकती हैं, और रिले लाइटहाउस फ़िल्टरिंग को पहुँच-नियंत्रण तंत्र नहीं बनाता।

सीधे एंडपॉइंट बंद रखकर रिले मार्ग का परीक्षण करें और पुष्टि करें कि इच्छित सेवा अब भी काम करती है जबकि अनिच्छित नहीं। वह एक ही परीक्षण परिवहन सुधार को नीति परिवर्तन से अलग करता है और दोनों परतों को ईमानदार रखता है।