IKEv2 की जीवंतता जाँच आपके ऐप का परीक्षण नहीं करती

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

टाइमर बदलने से पहले दोनों तरह के साक्ष्य अलग-अलग पढ़ें।

जीवंतता जाँच वास्तव में क्या पूछती है

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

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

ब्राउज़र से पहले सुरक्षा संबंध पढ़ें

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

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

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

मार्ग विफलता ठीक मृत साथी जैसी दिखती है

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

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

निदान से टाइमर दूर रखें

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

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

पूरी रिकवरी नीति बताती है कि साथी को मृत घोषित होने पर क्लाइंट को क्या करना चाहिए: पुनः आरंभ, बंद या होल्ड, और उस दौरान अन्य ट्रैफ़िक क्या कर सकता है। इसके बिना, वही घटना हर तिमाही में शुरू से फिर से निदान होती है।