IPsec प्रोफ़ाइल में पाँच पता भूमिकाएँ, और कौन-सी गलत है

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

पाँच काम, उस क्रम में जिसमें वे मायने रखते हैं

परिवहन एंडपॉइंट वह जगह है जहाँ IKE का आदान-प्रदान पहुँचाया जाता है। प्रमाणित पहचान वह नाम है जिसे हर पक्ष सिद्ध करता है, और उसे राउटिंग तालिका के बजाय नीति के सामने जाँचा जाता है। सुरक्षित सबनेट वे चयनकर्ता हैं जो तय करते हैं कि कौन-सा आंतरिक ट्रैफ़िक सुरंग में आता है। फिर वह स्रोत है जो तब इस्तेमाल होता है जब गेटवे स्वयं बातचीत शुरू करता है, और अंत में साथी तक पहुँचने के लिए अंडरले का अगला हॉप।

left और right जैसे प्रतिभागी लेबल कनेक्शन के दो पक्षों के लिए परिपाटियाँ हैं, स्थानीय और दूर के पर्यायवाची नहीं। वास्तव में स्थापित कार्यान्वयन का मैनुअल पढ़ें, इससे पहले कि आप मान लें कि कोई कुंजी वही अर्थ रखती है जो किसी दूसरे उत्पाद ने उससे लिया था।

पहला निर्णय: कुछ भी स्थापित नहीं होता

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

अनुवाद के ज़रिए देखा गया सार्वजनिक पता वही चीज़ नहीं है जो पहचान साथी सिद्ध करता है। दूर के सिरे पर पैकेट कैप्चर जो दिखाता है उससे मिलाने के लिए पता बदलना एक आम और गलत सुधार है।

दूसरा निर्णय: सुरंग ऊपर है और ट्रैफ़िक मरता है

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

संपादित करने से पहले दोनों कॉन्फ़िगरेशन साथ-साथ पढ़ें। एक होस्ट की स्थानीय श्रेणी दूसरे की दूर की श्रेणी है, और एक ही अदला-बदली जोड़ी ऐसी सुरंग समझा देती है जो कुछ नहीं ढोती। कुंजियों को छूने से पहले जोड़ी को संकरा करें: सुरंग के भीतर एक सबनेट और बाहर एक आपको बताते हैं कि दोष चयनकर्ता का है या राउटिंग का।

तीसरा निर्णय: केवल गेटवे का अपना ट्रैफ़िक विफल होता है

क्लाइंट के लिए आगे भेजा गया ट्रैफ़िक पूरी तरह काम कर सकता है जबकि गेटवे स्वयं जो अनुरोध शुरू करता है वह विफल हो जाता है, क्योंकि उस प्रवाह के पास विरासत में लेने के लिए कोई क्लाइंट स्रोत नहीं है। पसंदीदा स्रोत की सेटिंग ठीक इसी स्थिति के लिए है, और यह स्रोत अनुवाद नहीं है: यह स्रोत पता चुनती है, फिर से लिखती नहीं।

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

अगला हॉप एक स्थानीय निर्देश है

अंडरले का अगला हॉप इस होस्ट को बताता है कि साथी तक कैसे पहुँचना है, और दूर के पक्ष को वही मान चाहिए नहीं। उसे साझा सेटिंग मानना, या डिफ़ॉल्ट गेटवे को हार्डकोड करना, उसी क्षण टूट जाता है जब मार्ग बदलता है या दूसरा रास्ता दिखाई देता है।

कुछ कार्यान्वयन यहाँ विशेष मान देते हैं। स्थापित संस्करण के लिए मैनुअल जो सूचीबद्ध करता है वही एकमात्र सुरक्षित उत्तर है, और स्थानीय राउटिंग तालिका इस बात का प्रमाण है कि यह काम कर गया। जब साथी तक नाम से पहुँचा जा सके पर पते से नहीं, तो वही असंगति निष्कर्ष है, टालने लायक ब्यौरा नहीं।

प्रोफ़ाइल को दोनों सिरों से पढ़ें

कागज़ पर भूमिकाएँ उलट देना सबसे तेज़ समीक्षा है: सुरक्षित श्रेणियाँ बदल दें, हर पक्ष का अपना अगला हॉप और हर पक्ष की अपनी पहचान रखें। जो अदला-बदली सह न सके वह संभवतः गलत काम को सौंपा गया है।

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