NetBird पर दो LAN: कौन से पीयर रूट करते हैं और कौन बोल सकता है
पंजीकरण किसी LAN को रूट नहीं करता। प्रति साइट एक रूटिंग पीयर चुनें, मास्करेडिंग चालू रखें, नीति सीमित करें, फिर हर LAN गेटवे को अगला हॉप सिखाएँ।
पश्चिमी LAN पर स्थित वर्कस्टेशन ब्राउज़र खोलता है, पूर्वी LAN पर किसी एप्लिकेशन का पता टाइप करता है और समय समाप्त होने तक प्रतीक्षा करता है। NetBird की हर स्क्रीन कहती है कि पीयर जुड़े हुए हैं, जो सच है और बात से बाहर है: एक ओवरले नेटवर्क में होना दो स्थानीय सबनेट को एक नेटवर्क में रखने के बराबर नहीं है। नीचे की यात्रा उसी वर्कस्टेशन से शुरू होती है और ऐसे अनुरोध पर खत्म होती है जिसे डिज़ाइन जानबूझकर अस्वीकार करता है, और हर पड़ाव ऐसी चीज़ है जिसे आप डिवाइस से पढ़ते हैं, अनुमान नहीं लगाते। अपेक्षा रखें कि गायब हिस्सा कोई रूट या नीति है, ओवरले नहीं।
पहले वर्कस्टेशन से ही विफलता पढ़ें
प्रबंधन कंसोल खोलने से पहले तय करें कि वर्कस्टेशन वास्तव में क्या भेजता है। उसकी अपनी रूटिंग तालिका तय करती है कि पैकेट साइट गेटवे पर जाए, किसी स्थानीय इंटरफ़ेस पर जाए या कहीं न जाए, और यह निर्णय किसी भी ओवरले औज़ार के बिना दिखता है। जिस मशीन के पास दूर के प्रीफ़िक्स का रूट नहीं है वह विफल होगी, चाहे पीयर सूची कितनी भी स्वस्थ दिखे। ओवरले रेंज और साइट का अपना प्रीफ़िक्स अलग पता-स्थान हैं, और पंजीकरण ने उनमें से केवल एक को कॉन्फ़िगर किया।
इसके बाद नाम समाधान को पहुँच से अलग करें, क्योंकि ब्राउज़र दोनों को एक ही टाइमआउट बताता है। अनुरोध को पते से उस मशीन पर दोहराएँ जिस पर NetBird क्लाइंट चलता है, फिर उस साधारण वर्कस्टेशन पर जिस पर नहीं चलता। यदि पंजीकृत मशीन सफल हो और साधारण विफल, तो कमी स्थानीय रूटिंग में है; यदि दोनों विफल हों, तो रूट बदलने से पहले आगे पढ़ें।
प्रति साइट एक रूटिंग पीयर चुनें
रूटिंग पीयर वह होस्ट है जो ओवरले पर अपने LAN का प्रतिनिधित्व करता है, इसलिए किसी की मेज़ के वर्कस्टेशन के बजाय सबनेट तक स्थिर पहुँच वाली Linux मशीन चुनें। उसे सामान्य प्रक्रिया से पंजीकृत करें और भूमिका के नाम वाले समूह में रखें, क्योंकि नेटवर्क संसाधन और नीति दोनों उसी समूह का संदर्भ देंगे। प्रति साइट एक प्रतिनिधि पढ़ने योग्य रहता है; एक ही प्रीफ़िक्स की घोषणा करने वाले स्वयंसेवकों की भीड़ हर बाद के सवाल को डिबगिंग सत्र बना देती है। स्थानीय खंड पर पीयर का पता उसकी ओवरले पहचान जितना ही मायने रखता है, क्योंकि वही पता हर साधारण डिवाइस को बताया जाने वाला अगला हॉप बनता है।
कंसोल छूने से पहले योजना लिख लें, क्योंकि नाम और प्रीफ़िक्स ही वह जगह हैं जहाँ ये डिज़ाइन भटकते हैं: प्रीफ़िक्स, गेटवे, पीयर पता और समूह, प्रति साइट। पश्चिम 10.52.0.0/24 है जिसकी सेवा 10.52.0.5 करता है और पूर्व 10.63.0.0/24 है जिसकी सेवा 10.63.0.5 करता है; दो समूह west-routers और east-routers हैं, और कोई भी प्रीफ़िक्स दूसरे, ओवरले रेंज या किसी अन्य रूट किए गए गंतव्य के साथ ओवरलैप नहीं कर सकता।
संसाधन बनाएँ, मास्करेडिंग चालू रखें
तैनात डैशबोर्ड में प्रति साइट एक नेटवर्क संसाधन बनाएँ और उस साइट का रूटिंग-पीयर समूह उससे जोड़ें। संसाधन प्रीफ़िक्स है और समूह वह होस्ट है जो उसके लिए जवाब देता है, और कुछ भी घोषित करने से पहले दोनों का होना ज़रूरी है। पुष्टि करें कि तैनात स्व-होस्टेड संस्करण में नेटवर्क्स वर्कफ़्लो बिल्कुल है, क्योंकि समान नाम वाली रूट ऑब्जेक्ट वाला पुराना इंटरफ़ेस अलग सुविधा है।
मास्करेडिंग चालू रहने दें। NetBird की साइट-से-साइट मार्गदर्शिका इस व्यवस्था में इसे ज़रूरी बताती है, और हर मूल पता दिखाई देता रहे इसके लिए इसे बंद करना एक हॉप कम वाला वही डिज़ाइन नहीं है; यह बदलता है कि ओवरले की स्रोत जाँच और नीतियाँ क्या देखती हैं। नतीजा सीधे कहने लायक है: प्राप्त करने वाली सेवा स्रोत के रूप में रूटिंग पीयर दर्ज करती है, अलग वर्कस्टेशन नहीं। यदि उस सेवा की अनुमति-सूची या ऑडिट वर्कस्टेशन पतों की अपेक्षा करती है, तो या तो अपेक्षा बदलती है या अनुवाद से पहले साइट सीमा पर पहचान लागू करनी होगी।
शुरू करने वालों को अधिकृत करें, प्रीफ़िक्स को नहीं
रूट किसी पते को पहुँचने योग्य बनाता है और नीति तय करती है कि कौन उसका उपयोग कर सकता है; ये दो अलग मालिकों वाली दो अलग ऑब्जेक्ट हैं। नीति को वर्कलोड से पीछे की ओर लिखें: कौन सा समूह शुरू करता है, किस संसाधन को लक्षित करता है और किस TCP सेवा की ज़रूरत है। जो नेटवर्क हर पंजीकृत पीयर को दोनों प्रीफ़िक्स की घोषणा करता है उसने पहुँच बनाई है और कुछ तय नहीं किया।
फिर पढ़ें कि और क्या पहले से अनुमत है, क्योंकि संकीर्ण नया नियम उसके ऊपर बैठे विस्तृत पुराने नियम को रद्द नहीं करता। जब पूर्व को भी पश्चिम की ओर कनेक्शन शुरू करने हों, तो उस दिशा को अपनी अलग नीति के रूप में लिखें; पश्चिम द्वारा खोले गए सत्र का वापसी ट्रैफ़िक पूर्व की ओर नए सत्र अनुमत करने से अलग सवाल है। यदि केवल कुछ पश्चिमी वर्कस्टेशनों को पूर्वी एप्लिकेशन तक पहुँचना है, तो उन्हें अनुवाद से पहले साइट सीमा पर चुनें और एप्लिकेशन का अपना प्रमाणीकरण बनाए रखें। रूटिंग पीयर LAN ट्रैफ़िक को पूरी साइट के रूप में ले जाता है, प्रति-उपयोगकर्ता ओवरले पहचान के रूप में नहीं, इसलिए प्रति-उपयोगकर्ता लेखा कहीं और से आना चाहिए।
हर गेटवे को अगला हॉप सिखाएँ, फिर अस्वीकृति जाँचें
साधारण डिवाइस ओवरले कभी नहीं देखते, इसलिए उनके अपने गेटवे को ऐसा स्थिर रूट चाहिए जो दूर के प्रीफ़िक्स को रूटिंग पीयर के LAN पते की ओर भेजे। यही वह कदम है जो लोग छोड़ देते हैं, क्योंकि NetBird के भीतर दिखने वाला सब कुछ पहले से काम करता है जबकि साधारण वर्कस्टेशन अब भी समय समाप्त करते हैं। गेटवे अपना डिफ़ॉल्ट रूट जैसा था वैसा ही रखता है; यह प्रीफ़िक्स जोड़ है, प्रतिस्थापन नहीं।
दोनों रूट विवरण हर साइट के अपने गेटवे कॉन्फ़िगरेशन में आते हैं, होस्ट पर ओवरराइड में नहीं। दोनों साधारण स्थिर रूट हैं, और कोई भी डिफ़ॉल्ट रूट को नहीं छूता:
west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5उसी एप्लिकेशन से जाँचें जिसकी प्रोजेक्ट को वास्तव में ज़रूरत है, किसी साधारण वर्कस्टेशन से, और तीन चीज़ें लिखें: भेजने वाली ओर चुना गया अगला हॉप, जो नीति मेल खाई और वह स्रोत पता जो सेवा ने दर्ज किया। अस्वीकृति भी जाँचें, क्योंकि जिस डिज़ाइन ने कभी कुछ अस्वीकार नहीं किया उसके किनारे अज्ञात हैं, और अस्वीकृति ही एकमात्र सबूत है कि काम नीति कर रही है, रूटिंग नहीं। जब पूर्व को भी शुरू करना हो, तो दूसरी दिशा अपने आप आएगी मानने के बजाय उसी ओर से नया कनेक्शन शुरू करें। रूटिंग पीयर के पुनःआरंभ, उन्नयन और प्रतिस्थापन की भी योजना बनाएँ, क्योंकि एक होस्ट साइट की निर्भरता बन गया है।
| Test | A pass looks like | A failure points at |
|---|---|---|
| Ordinary workstation opens the east application | Next hop on west is the routing peer | Missing static route on the west gateway |
| A source outside policy is refused | No session in the service log | Policy too broad, or a route bypasses it |
| East starts a connection, if required | A fresh reverse session succeeds | No policy for the reverse direction |
निजी नामों को अपना रिज़ॉल्वर डिज़ाइन चाहिए, क्योंकि पहुँच DNS रिकॉर्ड नहीं बनाती और टूटे नाम के साथ काम करता IP पथ बिल्कुल टूटे पथ जैसा पढ़ा जाता है। यदि रूटिंग पीयर किसी क्लाउड नेटवर्क में चलता है, तो प्रदाता के फ़ॉरवर्डिंग और फ़ायरवॉल नियम भी देखें, क्योंकि पंजीकरण उन्हें रद्द नहीं करता। जाँच के अवलोकन योजना के पास रखें, क्योंकि आगे इसे डिबग करने वाला टोपोलॉजी का वर्णन नहीं, मेल खाती नीति और दर्ज किया गया स्रोत पता चाहेगा।