Check Point VSX VPN: लिंक चयन या पीयर बेमेल?

Check Point साइट-टू-साइट टनल के ऊपर न आने पर दो अलग-अलग बदलाव एक ही लक्षण पैदा करते हैं: पीयर को अलग बाहरी पता दिखता है, या वह अब मिलने वाली IKE पहचान को अस्वीकार कर देता है। एक तरफ़ से लिए गए कैप्चर में दोनों एक जैसे दिखते हैं। यह तय करने के लिए कि आपके पास कौन-सा मामला है, तीन जाँचें चाहिए, और उनमें से कोई भी लिंक चयन वाला पैनल नहीं है।

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

दोनों स्थितियों को अलग करने वाली तीन शर्तें

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

पहली शर्त विफल हो तो आपके पास रूटिंग या अनुवाद की समस्या है। दूसरी विफल हो तो पीयर-अनुबंध की समस्या है। तीसरी अज्ञात हो तो कॉन्फ़िगर करना बंद कर दें।

पहले बाहरी-पीयर रिकॉर्ड बनाएँ

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

भीतरी संरक्षित प्रीफ़िक्स उस रिकॉर्ड के अलग हिस्से में रखें। बाहरी स्रोत बदलना और संरक्षित LAN पता बदलना अलग-अलग क्रियाएँ हैं जो संयोगवश एक ही नीति में रहती हैं।

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

पढ़ें कि लिंक चयन वास्तव में क्या अलग करता है

Check Point की R81.20 में लिंक चयन की मार्गदर्शिका उन तीन चीज़ों को अलग करती है जिन्हें लोग एक में मिला देते हैं: दूरस्थ पीयर गेटवे पते को कैसे हल करता है, कौन-सा रूट बाहर जाने वाला ट्रैफ़िक ढोता है, और कौन-सा स्रोत IP इस्तेमाल होता है। हर एक अलग सवाल का जवाब देता है। इनमें से कोई भी उस पहचान को नहीं बदलता जिसे पीयर प्रमाणित करता है।

यही अलगाव बताता है कि रूट बदलाव IKE पहचान को छुए बिना दिखने वाला बाहरी पता क्यों बदल सकता है, और पहचान का बदलाव उस टनल को क्यों तोड़ सकता है जिसका रूटिंग निर्दोष है।

RFC 7296 स्वयं IKE के लिए वही रेखा खींचता है: पहचान पेलोड परिवहन पता नहीं है। विक्रेता उस विभाजन को लागू करते हैं, उसे फिर से परिभाषित नहीं करते।

सेटिंग्स पैनल से नहीं, सबूत से फ़ैसला करें

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

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

दोनों सिरों को मिलाएँ और रिकॉर्ड रखें

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

देखे गए बाहरी पते सक्रिय वर्चुअल-सिस्टम संदर्भ के साथ सहेजें। तब अगला रूट बदलाव किसी की डिफ़ॉल्ट की याद के बजाय documented अनुबंध से तुलना करेगा।