IKEv2 मृत साथी पत्ता लगाउने कामले तपाईंको एप परीक्षण गर्दैन

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

टाइमर बदल्नु अघि दुई प्रकारका प्रमाण अलग-अलग पढ्नुहोस्।

जीवन्तता जाँचले वास्तवमा के सोध्छ

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

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

ब्राउजर अघि सुरक्षा संघहरू पढ्नुहोस्

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

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

गुनासोको क्षणको काउन्टरसहित अवस्थाका नामहरू टिकटमा जस्ताको तस्तै लेख्नुहोस्। सुरुङ तल भन्ने जस्तो विवरणले दुई संघमध्ये कुन समाप्त भयो भन्ने लुकाउँछ, र सामान्यतया त्यही नै राख्न लायक एकमात्र तथ्य हो।

मार्ग असफलता ठ्याक्कै मृत साथी जस्तै देखिन्छ

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

सुरुङ चालु छ कि भनेर जाँच्नुको सट्टा लक्षित एप्लिकेसनलाई सिधै परीक्षण गर्नुहोस् र यसले प्रयास गरेको ठेगाना बताउनुहोस्। गेटवेमा पिङले गेटवे जवाफ दिन्छ भनी प्रमाणित गर्छ; यसले एप्लिकेसनले दियो भनी कहिल्यै प्रमाणित गरेन। एप्लिकेसनले प्रयास गरेको ठ्याक्कै ठेगाना रेकर्ड गर्नुहोस्। त्यो स्ट्रिङले पछि खोजी साँघुरो बनाउँछ, र टिकटले सामान्यतया छुटाउने एकमात्र तथ्य त्यही हो।

टाइमरहरूलाई निदानबाट टाढा राख्नुहोस्

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

NAT म्यापिङ रिफ्रेसहरू पनि उही श्रेणीमा पर्छन्। तिनीहरूले अनुवादित मार्ग प्रयोगयोग्य राख्छन्, र टाढाको एप्लिकेसन काम गर्छ भन्ने प्रमाण होइनन्।

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