GET VPN सदस्यों के लिए स्थिर पंजीकरण स्रोत चुनें

कोई समूह सदस्य का पंजीकरण एक loopback पते पर लगाता है और घोषणा करता है कि GET VPN की अस्थिरता हल हो गई। कभी-कभी सचमुच हो जाती है। अकसर loopback केवल सदस्य की अपनी रूटिंग तालिका से पहुँच में होता है और कहीं और से नहीं, इसलिए अगली बार जब उसे ढोने वाला uplink डगमगाता है तो पंजीकरण फिर टूट जाता है। पंजीकरण का पता कंट्रोल-प्लेन की पहचान है, और वह केवल तब मदद करता है जब दोनों दिशाओं में असली मार्ग मौजूद हो। उसे सोच-समझकर चुनना बनता है, और यह लोककथा के दावे से छोटा बदलाव है।

पंजीकरण का पता क्या पहचानता है

GDOI परिनियोजन में समूह सदस्य कुंजी सर्वर के पास पंजीकरण करता है और उससे समूह नीति प्राप्त करता है। कुंजी सर्वर जो पता दर्ज करता है वह उस बातचीत के लिए सदस्य की पहचान है।

यह पहचान कंट्रोल बातचीत को कवर करती है: पंजीकरण, कुंजी नवीनीकरण और नीति का डाउनलोड। यह ग्राहक ट्रैफ़िक का स्रोत नहीं बनता, और यह नहीं बदलता कि कौन-से इंटरफ़ेस किन फ़्लो की रक्षा करते हैं।

दोनों को अलग रखना पहला कदम है, क्योंकि इस सेटिंग के आसपास का अधिकांश भ्रम इस अपेक्षा से आता है कि कंट्रोल-प्लेन में बदलाव डेटा-प्लेन के लक्षण को ठीक कर देगा।

loopback उतना ही अच्छा है जितना उसका रूट

loopback सदस्य को एक तार्किक पता देता है जो एक भौतिक uplink विफल होने पर गायब नहीं होता। कुंजी सर्वर तक कई मार्गों वाले राउटर पर यह असली लाभ है।

पर यह भी केवल एक पता है। अगर कुंजी सर्वर के पास उस तक वापसी का रूट नहीं है, तो पंजीकरण ठीक पहले जैसा विफल होता है। अगर सदस्य की रूटिंग तालिका कुंजी सर्वर तक केवल एक uplink से पहुँचती है, तो loopback स्थिर है और मार्ग नहीं।

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

नियंत्रण और संरक्षित ट्रैफ़िक को अलग रखें

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

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

डेटा-प्लेन नीति एक अलग डिज़ाइन है। पंजीकरण कहाँ से आता है, यह बदलने से संरक्षित फ़्लो, सिलेक्टर और बायपास नियम ठीक वहीं रहते हैं जहाँ थे।

संक्रमण के दौरान पहचान जाँचें

बदलाव से पहले समूह, चुना गया पंजीकरण पता, कुंजी सर्वर का गंतव्य, रूटिंग संदर्भ और अनुमत कंट्रोल मार्ग दर्ज करें। स्वीकृत uplink बदलाव के बाद कुंजी सर्वर के पंजीकृत सदस्य दृश्य और सदस्य की कंट्रोल स्थिति फिर से देखें।

आप जो देखना चाहते हैं वह यह है कि इच्छित तार्किक अंतिम बिंदु अभी भी पहुँच योग्य है और अभी भी वैसे ही प्रस्तुत है जैसे आपने डिज़ाइन किया था। आप जो नहीं देखना चाहते वह है ऐसे पते से दूसरा पंजीकरण जिसका आपने इरादा नहीं किया था, क्योंकि सदस्य की अनुलिपि प्रविष्टियाँ ठीक इसी तरह बनती हैं।

फिर संरक्षित एप्लिकेशन ट्रैफ़िक को अलग से परखें। स्थानांतरण सफल हो सकता है जबकि अगले कुंजी नवीनीकरण के पास जाने की कोई जगह न हो, और सफल पंजीकरण यह नहीं बताता कि कोई विशिष्ट फ़्लो सही ढंग से चुना और रूट किया गया है या नहीं।

स्थिर स्रोत क्या ठीक नहीं करता

यह पिछली गलत कॉन्फ़िगरेशन से बनी सदस्य की अनुलिपि प्रविष्टियाँ नहीं हटाता। सदस्य और कुंजी सर्वर के बीच नीति मेल न खाने से हुई कुंजी नवीनीकरण विफलता का मरम्मत नहीं करता। ऐसी भौतिक मार्ग विफलता से नहीं बचता जिसने कुंजी सर्वर तक का एकमात्र रूट हटा दिया।

यह जो करता है वह एक चर हटाना है: uplink पता बदलने पर पहचान अब नहीं बदलती। यह रखने लायक है, और यह पूरा डिज़ाइन नहीं बल्कि डिज़ाइन में एक पंक्ति है।

काम का क्रम: कंट्रोल मार्ग का नाम दें, दोनों दिशाओं में रूट वाला पता चुनें, कुंजी सर्वर का दृश्य पुष्टि करें, फिर संरक्षित ट्रैफ़िक को अलग से परखें। यदि पंजीकरण फिर भी विफल हो, तो loopback कभी समस्या नहीं था।