Check Point VSX VPN: लिङ्क चयन कि पियर बेमेल?

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

क्रम बिग्रियो भने पहिचानको बेमेल सुधार्न स्रोत चयन मिलाउन थाल्नुहुन्छ। यसरी एउटै सुरुङ दुई पटक सुधारिन्छ र अर्को मार्ग परिवर्तनपछि फेरि बिग्रन्छ।

दुई अवस्था छुट्याउने तीन सर्त

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

पहिलो सर्त असफल भयो भने तपाईंसँग मार्ग वा अनुवादको समस्या छ। दोस्रो असफल भयो भने पियरसँगको सम्झौताको समस्या छ। तेस्रो अज्ञात छ भने कन्फिगरेसन रोक्नुहोस्।

पहिले बाह्य-पियर अभिलेख बनाउनुहोस्

केही पनि छुनुअघि भर्चुअल प्रणाली, सफ्टवेयर संस्करण र स्थापित अद्यावधिक स्तर लेख्नुहोस्। त्यसपछि बाह्य इन्टरफेस, टाढाको पियरतर्फको मार्ग, NAT अघि र पछिको अपेक्षित स्रोत ठेगाना, र टाढाको पियरको कन्फिगर गरिएको अन्त्यबिन्दु अभिलेख गर्नुहोस्।

भित्री संरक्षित प्रिफिक्सहरू त्यो अभिलेखको छुट्टै भागमा राख्नुहोस्। बाह्य स्रोत बदल्नु र संरक्षित LAN ठेगाना बदल्नु फरक कार्य हुन् जो संयोगवश एउटै नीतिमा बस्छन्।

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

लिङ्क चयनले वास्तवमा के छुट्याउँछ पढ्नुहोस्

Check Point को R81.20 मा लिङ्क चयन मार्गदर्शिकाले मानिसहरूले एउटैमा मिसाउने तीन कुरा छुट्याउँछ: टाढाको पियरले गेटवे ठेगाना कसरी समाधान गर्छ, कुन मार्गले बाहिर जाने ट्राफिक बोक्छ, र कुन स्रोत IP प्रयोग हुन्छ। प्रत्येकले फरक प्रश्नको उत्तर दिन्छ। तीमध्ये कुनैले पनि पियरले प्रमाणित गर्ने पहिचान बदल्दैन।

यही छुट्याइले मार्ग परिवर्तनले IKE पहिचानलाई नछोई देखिने बाह्य ठेगाना किन बदल्न सक्छ, र पहिचान परिवर्तनले मार्गनिर्देशन त्रुटिरहित सुरुङ किन तोड्न सक्छ भन्ने व्याख्या गर्छ।

RFC 7296 ले IKE आफैंका लागि पनि त्यही रेखा तान्छ: पहिचान पेलोड ढुवानी ठेगाना होइन। उत्पादकहरूले यो विभाजन लागू गर्छन्, पुनः परिभाषित गर्दैनन्।

सेटिङ प्यानलले होइन, प्रमाणले निर्णय गर्नुहोस्

पियरले अज्ञात वा नमिल्ने पहिचान रिपोर्ट गर्यो भने स्रोत चयन होइन, पियर वस्तु वा पहिचानको कन्फिगरेसन सुधार्नुहोस्। पियरले केही रिपोर्ट नगरे र तपाईंको क्याप्चरले प्याकेट अप्रत्याशित ठेगानाबाट बाहिर जाँदै छ भनी देखाए, पहिले मार्ग वा अनुवाद सुधार्नुहोस्। दुवै ठीक देखिए पनि सुरुङ असफल भयो भने टाढाको पक्षमा क्याप्चर गरी उसले के प्राप्त गर्यो तुलना गर्नुहोस्। ठेगाना र पहिचान मिलेर पनि मार्ग अझै गलत भएपछि मात्र लिङ्क चयनको कुनै विकल्प उम्मेदवार बन्छ।

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

दुवै छेउ मिलाउनुहोस् र अभिलेख राख्नुहोस्

समर्थित डिजाइन भएपछि बाह्य पहुँच, पियर अन्त्यबिन्दुको कन्फिगरेसन र पहिचानको सहमति सँगै, एउटै करारका रूपमा समीक्षा गर्नुहोस्। त्यसपछि तीन अवस्थाका लागि स्वीकृतिको योजना बनाउनुहोस्: सुरुवाती जडान, टाढाको पक्षले सुरु गरेको जडान, र मार्ग टुट्दा अपेक्षित असफलता।

देखिएका बाह्य ठेगाना सक्रिय भर्चुअल-प्रणाली सन्दर्भको छेउमा बचत गर्नुहोस्। अनि अर्को मार्ग परिवर्तनले कसैको पूर्वनिर्धारितबारे सम्झनासँग होइन, अभिलेखित करारसँग तुलना गर्नेछ।