SoftEther कॅस्केड: दोन व्हर्च्युअल हब जाणीवपूर्वक जोडा

कॅस्केडने जोडलेले दोन SoftEther हब एकच प्रसारण डोमेन सामायिक करतात, त्यामुळे लूप किंवा दुसरा DHCP सर्व्हर स्थानिक चूक राहत नाही आणि सामायिक चूक बनतो। हे संपूर्ण जोखीम मॉडेल आहे। कॅस्केड स्वतः एक कॉन्फिगर केलेला क्लायंट संबंध आहे: स्थानिक व्हर्च्युअल हब त्या सर्व्हरने अनुमती दिलेल्या ओळखीखाली दूरच्या सर्व्हरच्या हबकडे बाहेरून जोडतो। हे मोठ्या व्हर्च्युअल नेटवर्कसाठीचा बांधकाम घटक आहे, कधीही इंटरनेट एग्झिट नाही।

1. लिंकने काय वाहिले पाहिजे ते ठरवा

वैशिष्ट्यापासून नाही, गरजेपासून सुरुवात करा। कॅस्केड हबमध्ये दुसऱ्या स्तरातील फ्रेम हलवते, आणि दोन ठिकाणे एकच इथरनेट विभाग दिसायला हव्यात तेव्हा हेच लागते। गरज फक्त काही उपजाळांपर्यंत मार्गित प्रवेश असेल, तर मार्गित मार्ग सोपा असतो आणि अधिक दिसणाऱ्या पद्धतीने अपयशी होतो। कॅस्केड निवडणे म्हणजे सामायिक प्रसारण, सामायिक शोध आणि एकच लूप टोपोलॉजी स्वीकारणे।

सर्व्हरला स्पर्श करण्यापूर्वी गरज एका ओळीत लिहा: कोणत्या प्रणाली एकाच तारेवर दिसायला हव्यात आणि कोणत्यांना फक्त मार्ग हवा। «मार्ग» असे उत्तर देणारे सर्व कॅस्केडबाहेर आहे। हे एकच वाक्य डुप्लिकेट पत्ता सेवांवर संपणाऱ्या बहुतेक रचनांना प्रतिबंध करते।

2. अनुमती देणाऱ्या ओळखीची व्याप्ती ठरवा

सर्व्हरचे व्यवस्थापन करणारी क्रेडेन्शियल्स आणि कॅस्केड जोडण्यासाठी वापरणारी ओळख वेगवेगळी गुपिते आहेत, आणि ती मिसळणे लांब शेपटीचा नेहमीचा शॉर्टकट आहे। दूरच्या हबला या कॅस्केडला जोडण्याची परवानगी देणारी वापरकर्ता किंवा धोरण नोंद हवी। ती नोंदच अधिकृती आहे; यशस्वी लॉगिन दूरच्या हबच्या मागे काय आहे याबद्दल काहीही सांगत नाही।

कोणता हब सुरुवात करतो, कोणत्या दूरच्या हबला जोडतो आणि दूरची ओळख कितीपर्यंत पोहोचू शकते ते नोंदवा। कटिबद्ध होण्यापूर्वी दोन्ही आर्किटेक्चरची तुलना करा:

दोन्ही टोकांची क्रेडेन्शियल्स आणि पुनर्प्राप्ती सूचना अद्ययावत ठेवा। दूरच्या हबवर पासवर्ड बदलणे किंवा धोरण संपादित करणे तुमच्या स्थानिक वापरकर्त्यांना स्पर्श न करता कॅस्केड तोडते, आणि अपयश सहसा सुरू असूनही रिकामी लिंक म्हणून दिसते।

3. हब आधीच काय वाहते ते तपासा

हब क्वचितच वेगळा असतो। तो आधीच भौतिक ॲडॉप्टरला ब्रिज करू शकतो, व्हर्च्युअल राउटरमधून मार्ग करू शकतो किंवा दुसरीकडे कॅस्केड करू शकतो, आणि त्या प्रत्येक जोडणीचे नवीन संबंधात हस्तांतरण होते। म्हणूनच «आम्ही फक्त दोन हब जोडले» हे «हे दोन ठिकाणे आता एकच विभाग का आहेत» असे वारंवार बदलते।

एकाच भौतिक विभागात ब्रिज केलेले आणि नंतर एकमेकांशी कॅस्केड केलेले दोन हब लूप तयार करतात। स्पॅनिंग ट्री जोडा किंवा ते बांधू नका। तीच चाचणी दुसऱ्या कॅस्केडमधून लक्ष्य गाठणाऱ्या हबलाही लागू होते: दुसरी लिंक क्षमता वाढवत नाही, ती मार्ग वाढवते।

एक मार्ग नसल्यामुळे लिंक जोडू नका; मार्ग दुरुस्त करा। आधी कागदावर टोपोलॉजी काढा, प्रत्येक ब्रिज आणि कॅस्केडसह, कारण आकृती दोन मिनिटे घेते आणि बहुतेक लूप त्यांच्या निर्मितीपूर्वीच पकडते।

4. जोडण्यापूर्वी पत्ता व्यवस्था करा

जोडलेले विभाग डुप्लिकेट उपजाळे आणतात, आणि डुप्लिकेट DHCP सर्व्हर हे नेहमीचे लक्षण आहे: ग्राहक जो सर्व्हर आधी उत्तर देतो त्याच्याकडून भाडे घेतात, त्यामुळे वर्तन यादृच्छिक दिसते आणि रीबूटमध्ये बदलते। कोणती बाजू पत्ता वाटपाची मालक आहे हे आधीच ठरवा, आणि दूरच्या विभागाला स्थानिक कोणत्याही गोष्टीशी न मिळणारी श्रेणी द्या। कॅस्केड ऑनलाइन येण्यापूर्वी दुसरी DHCP सेवा बंद करा, पहिल्या तक्रारीनंतर नाही।

DNS हा वेगळा प्रश्न आहे। कॅस्केड फ्रेम वाहते; ते रिझोल्व्हर कॉन्फिगर करत नाही, आणि स्थानिक बाजूला सुटणारे नाव लिंकपार सुटू शकत नाही। IP मार्गापासून वेगळे लुकअप तपासा, कारण चालणारे ping दोनपैकी एकच सिद्ध करते।

5. खऱ्या संसाधनाने ते सिद्ध करा

इच्छित दूरच्या विभागावर परवानगी असलेली सेवा निवडा आणि उत्तर कॅस्केडमधून परत येते याची खात्री करा। नंतर नाव सोडवण्यासाठी पुन्हा करा। लक्ष्य प्रसारण शोधावर अवलंबून असेल, तर एका तारेपेक्षा ब्रिज केलेल्या लिंकवर वेगळे वर्तन अपेक्षा करा, आणि ते दोष म्हणून नोंदवण्याऐवजी योजनेत घ्या।

शेवटी टोपोलॉजी लिहा: कोणता हब कुठे कॅस्केड करतो, कोणती ओळख त्याला अनुमती देते, कोणते विभाग ब्रिज केलेले आहेत आणि प्रत्येकावर पत्ता वाटपाची मालकी कोणाकडे आहे। ती नोंदच पुढच्या व्यक्तीला अस्तित्व माहीत नसलेला विभाग खाली न पाडता धोरण बदलू देते।