Check Point VSX VPN: दुवा निवड की पीअर विसंगती?

Check Point साइट-टू-साइट बोगदा वर येणे थांबल्यावर दोन वेगळे बदल एकच लक्षण निर्माण करतात: पीअरला वेगळा बाह्य पत्ता दिसतो, किंवा तो आता मिळणारी IKE ओळख नाकारतो. एका बाजूने घेतलेल्या कॅप्चरमध्ये दोन्ही सारखेच दिसतात. तुमच्याकडे कोणती स्थिती आहे हे ठरवण्यासाठी तीन तपासण्या लागतात, आणि त्यातील एकही दुवा निवडीची पॅनेल नाही.

क्रम चुकल्यास तुम्ही ओळखीची विसंगती दुरुस्त करण्यासाठी स्रोत निवड सजवता. अशा रीतीने तोच बोगदा दोन वेळा दुरुस्त होतो आणि पुढील मार्ग बदलानंतर पुन्हा तुटतो.

दोन प्रकरणांना वेगळे करणाऱ्या तीन अटी

पहिली अट: पीअरचा संरचित टोकबिंदू प्रत्यक्षात येणाऱ्या पत्त्याशी जुळतो का? जर पॅकेट्स दूरच्या गेटवेवर अशा पत्त्यावरून पोहोचत असतील ज्याला ते तुमच्या पीअर ऑब्जेक्टशी जोडत नाही, तर कोणतीही ओळख देवाणघेवाण होण्यापूर्वीच वाटाघाटी अयशस्वी होते. दुसरी अट: प्रस्तावातील IKE ओळख पीअर अपेक्षित असलेल्या मूल्याशी जुळते का? ते प्रमाणीकरण आहे, वाहतूक नाही. तिसरी अट: तुम्हाला बदलायचा असलेला पर्याय या आवृत्तीवर या व्हर्च्युअल सिस्टमसाठी समर्थित आहे का? कोणतेही दृश्यमान सेटिंग या प्रश्नांचे उत्तर देत नाही.

पहिली अट अयशस्वी झाल्यास तुमच्याकडे मार्गनिर्देशन किंवा भाषांतराची समस्या आहे. दुसरी अयशस्वी झाल्यास पीअर कराराची समस्या आहे. तिसरी अज्ञात असल्यास संरचना थांबवा.

प्रथम बाह्य-पीअर नोंद तयार करा

काहीही हात लावण्यापूर्वी व्हर्च्युअल सिस्टम, सॉफ्टवेअर आवृत्ती आणि स्थापित अद्ययावत स्तर लिहून घ्या. त्यानंतर बाह्य इंटरफेस, दूरच्या पीअरकडे जाणारा मार्ग, NAT आधी आणि नंतर अपेक्षित स्रोत पत्ते, आणि दूरच्या पीअरचा संरचित टोकबिंदू नोंदवा.

आतील संरक्षित उपसर्ग त्या नोंदीच्या वेगळ्या भागात ठेवा. बाह्य स्रोत बदलणे आणि संरक्षित LAN पत्ता बदलणे या वेगळ्या क्रिया आहेत ज्या योगायोगाने एकाच धोरणात राहतात.

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

दुवा निवड प्रत्यक्षात काय वेगळे करते ते वाचा

Check Pointची R81.20 मधील दुवा निवड मार्गदर्शिका लोक एकत्र करतात त्या तीन गोष्टी वेगळ्या करते: दूरचा पीअर गेटवे पत्ता कसा सोडवतो, कोणता मार्ग बाहेर जाणारी वाहतूक वाहतो, आणि कोणता स्रोत IP वापरला जातो. प्रत्येक वेगळ्या प्रश्नाचे उत्तर देते. त्यातील कोणतेही पीअर प्रमाणित करत असलेली ओळख बदलत नाही.

हेच विभाजन स्पष्ट करते की मार्ग बदल IKE ओळखीला हात न लावता दिसणारा बाह्य पत्ता कसा बदलू शकतो, आणि ओळखीचा बदल ज्याचे मार्गनिर्देशन निर्दोष आहे असा बोगदा कसा तोडू शकतो.

RFC 7296 स्वतः IKE साठी तीच रेषा काढते: ओळख पेलोड हा वाहतूक पत्ता नाही. उत्पादक हे विभाजन अंमलात आणतात, ते पुन्हा परिभाषित करत नाहीत.

सेटिंग्ज पॅनेलने नाही, पुराव्याने निर्णय घ्या

पीअरने अज्ञात किंवा न जुळणारी ओळख कळवल्यास स्रोत निवड नाही, तर पीअर ऑब्जेक्ट किंवा ओळखीची संरचना दुरुस्त करा. पीअरने काहीही कळवले नाही आणि तुमच्या कॅप्चरमध्ये पॅकेट्स अनपेक्षित पत्त्यावरून बाहेर पडताना दिसल्यास प्रथम मार्गनिर्देशन किंवा भाषांतर दुरुस्त करा. दोन्ही बरोबर दिसत असूनही बोगदा अयशस्वी झाल्यास दूरच्या बाजूने कॅप्चर घ्या आणि तिला काय मिळाले याची तुलना करा. पत्ता आणि ओळख जुळल्यावरही मार्ग चुकीचा असेल तेव्हाच दुवा निवडीचा एखादा पर्याय उमेदवार होतो.

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

दोन्ही टोके जुळवा आणि नोंद ठेवा

समर्थित रचना मिळाल्यावर बाह्य पोहोच, पीअर टोकबिंदूची संरचना आणि ओळखीची सहमती एकत्र, एक करार म्हणून तपासा. नंतर तीन प्रकरणांसाठी स्वीकृतीची योजना करा: सुरुवातीचे कनेक्शन, दूरच्या बाजूने सुरू केलेले कनेक्शन, आणि मार्ग तुटल्यावर अपेक्षित असलेला अपयश.

निरीक्षण केलेले बाह्य पत्ते सक्रिय व्हर्च्युअल-सिस्टम संदर्भाजवळ साठवा. मग पुढील मार्ग बदल कोणाच्या डीफॉल्टच्या आठवणीशी नाही, तर नोंदवलेल्या कराराशी तुलना करेल.