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 मार्ग अगदी तुटलेल्या मार्गासारखाच वाचला जातो। राउटिंग पीअर क्लाउड नेटवर्कमध्ये चालत असेल, तर पुरवठादाराचे फॉरवर्डिंग आणि फायरवॉल नियमही तपासा, कारण नोंदणी ते रद्द करत नाही। चाचणीची निरीक्षणे योजनेजवळ ठेवा, कारण हे पुढे डीबग करणाऱ्याला टोपोलॉजीचे वर्णन नाही, जुळलेले धोरण आणि नोंदवलेला स्रोत पत्ता हवा असेल।