IKEv2 मृत सहकारी शोध तुमचे ॲप तपासत नाही

IKEv2 जिवंतपणा तपासणी एकच प्रश्न विचारते: संरक्षित नियंत्रण संबंधावर दुसरा सहकारी अजूनही प्रतिसाद देत आहे का। अंतर्गत ॲप्लिकेशन निरोगी आहे का, गेटवेच्या मागे मार्ग आहे का, किंवा ब्राउझिंग वेगवान वाटते का हे ती मोजत नाही। बोगद्याच्या मागील सर्व उपयुक्त गोष्टी अयशस्वी झाल्या तरी तपासणी उत्तीर्ण होऊ शकते।

टाइमर बदलण्यापूर्वी दोन्ही प्रकारचे पुरावे वेगवेगळे वाचा।

जिवंतपणा तपासणी प्रत्यक्षात काय विचारते

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

सत्र शांत झाल्यावर कुठे पाहावे हे तोच फरक ठरवतो। डेटा मार्ग तुटलेला असतानाही प्रतिसाद देत राहणारा सहकारी धोरण, मार्गनिर्देशन किंवा खालील सेवेकडे निर्देश करतो। प्रतिसाद देणे थांबवणारा सहकारी पोहोच किंवा दूरच्या टोकाच्या स्वतःच्या स्थितीकडे निर्देश करतो।

ब्राउझरपूर्वी सुरक्षा संघटना वाचा

डेमनला विचारल्यावर नियंत्रण स्थिती आणि डेटा स्थिती वेगवेगळ्या सूचीबद्ध होतात, आणि काउंटर सांगतात की काही प्रयत्न झाला होता का। कधीही स्थापित न झालेली चाइल्ड संघटना स्थापित होऊन नंतर पॅकेट जाणे थांबवलेल्या संघटनेसारखी मुळीच दिसत नाही, जरी दोन्ही एकच वापरकर्ता तक्रार निर्माण करतात।

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

तक्रारीच्या क्षणीच्या काउंटरसह स्थितींची नावे टिकेटमध्ये जशी आहेत तशी लिहा। बोगदा खाली असे वर्णन दोन संघटनांपैकी कोणती संपली हे लपवते, आणि सहसा तोच ठेवण्यासारखा एकमेव तथ्य असतो।

मार्ग अयशस्वी होणे मृत सहकाऱ्यासारखेच दिसते

खाजगी सर्व्हर ऑफलाइन असताना, पाठवलेला मार्ग गहाळ असताना किंवा अंतर्गत नाव निराकरण पूर्णपणे अयशस्वी झाल्यावर गेटवे नियंत्रण देवघेवींना प्रतिसाद देऊ शकतो। क्लायंटच्या दृष्टीने यापैकी प्रत्येक सत्र सुरू आहे आणि गंतव्य सुरू नाही असे दिसते। परतीचा मार्ग पुढच्या मार्गाइतकाच काळजीपूर्वक तपासा, कारण दूरच्या बाजूचे असममित मार्गनिर्देशन केवळ एका दिशेने शांतता निर्माण करते।

बोगदा सुरू आहे का हे तपासण्याऐवजी इच्छित ॲप्लिकेशन थेट तपासा आणि त्याने प्रयत्न केलेला पत्ता सांगा। गेटवेला पिंग गेटवे प्रतिसाद देतो हे सिद्ध करते; ॲप्लिकेशनने दिला हे त्याने कधीही सिद्ध केले नाही। ॲप्लिकेशनने प्रयत्न केलेला नेमका पत्ता नोंदवा। ती स्ट्रिंग नंतर शोध मर्यादित करते, आणि टिकेट सहसा वगळत असलेले एकमेव तथ्य तेच आहे।

टाइमर निदानापासून दूर ठेवा

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

NAT मॅपिंग रीफ्रेशही त्याच श्रेणीत येतात। ते अनुवादित मार्ग वापरण्यायोग्य ठेवतात, आणि दूरचे ॲप्लिकेशन काम करते याचा ते पुरावा नाही।

संपूर्ण पुनर्प्राप्ती धोरण सांगते की सहकाऱ्याला मृत घोषित केल्यावर क्लायंटने काय करावे: पुन्हा सुरू करा, बंद करा किंवा धरून ठेवा, आणि त्या काळात इतर ट्रॅफिक काय करू शकते। त्याशिवाय तीच घटना प्रत्येक तिमाहीत सुरुवातीपासून पुन्हा निदान केली जाते।