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 मार्ग बिग्रेको मार्ग जस्तै पढिन्छ। रुटिङ पीयर क्लाउड नेटवर्कभित्र चल्छ भने, प्रदायकको फर्वार्डिङ र फायरवाल नियम पनि समीक्षा गर्नुहोस्, किनकि दर्ताले तिनलाई रद्द गर्दैन। परीक्षणका अवलोकन योजनाको छेउमा राख्नुहोस्, किनकि यसलाई अब डिबग गर्ने व्यक्तिलाई टोपोलोजीको वर्णन होइन, मिलेको नीति र अभिलेख गरिएको स्रोत ठेगाना चाहिन्छ।