हर बार कुंजियाँ बदलने पर आपका VPN क्यों टूटता है

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

लेबल नहीं, चरण पढ़ें

IKEv2 में IKE एसोसिएशन और CHILD एसोसिएशन अलग-अलग समय-सारणियों पर नवीनीकृत होते हैं। पहली बातचीत के लिए स्वीकार्य प्रस्ताव दूसरी के लिए स्वतः स्वीकार्य नहीं है। एक पूरा हो सकता है जबकि दूसरा अस्वीकार हो, जिससे आधी मौजूद सुरंग बनती है। क्लाइंट लॉग पंक्ति के बजाय उस उपकरण से विनिमय कैप्चर करें जो उसका मालिक है:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

OpenVPN के लिए समतुल्य घटना संस्करण और परिनियोजन सेटिंग्स द्वारा नियंत्रित पुनः बातचीत है। इसके प्रमाणीकरण व्यवहार के अपने विफलता तरीके हैं। महत्वपूर्ण संदेश विफल चरण का नाम बताता है, और आपको इसे टिकट में दोबारा लिखने के बजाय शब्दशः दर्ज करना चाहिए।

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

विफल होने वाले प्रस्ताव की तुलना करें

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

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

पुरानी प्रोफ़ाइल या प्रदाता टेम्पलेट ऐसा प्रस्ताव पिन कर सकता है जो वर्तमान संस्करण अब नहीं देता। असंगति केवल तब सामने आती है जब नई बातचीत को बाध्य किया जाता है।

क्रेडेंशियल समस्या को अगम्य साथी से अलग करें

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

दूर के सिरे ने जो दर्ज किया उससे तीनों को अलग करें। कारण के साथ अस्वीकृति, प्रमाणीकरण विफलता और मौन तीन अलग सुधार हैं। क्लाइंट को पुनः आरंभ करना उन्हें एक अनुपयोगी अवलोकन में समेट देता है।

नेटवर्क को दोष देने से पहले प्रमाणपत्र की तारीखें और खाता स्थिति जाँचें। दोनों जाँचने में सस्ते हैं और दोनों क्लाइंट के अपने संदेश में अदृश्य हैं।

एक नवीनीकरण बाध्य करें और परिणाम पढ़ें

अगले के लिए एक घंटा प्रतीक्षा करने के बजाय ऑपरेटर की समर्थित विधि से एक नवीनीकरण बाध्य करें। ऐसा करते समय आवश्यक विफलता नीति अक्षुण्ण रखें। सत्यापन बंद करना या जीवनकाल को एक दिन तक खींचना कुछ भी सुधारे बिना आपके लॉग से लक्षण गायब कर देता है। यह अगले व्यक्ति के लिए लंबा व्यवधान भी छोड़ देता है।

सुधार हो जाने के बाद, नवीनीकृत सुरंग जाँचें और फिर एप्लिकेशन से नई अनुरोध करें। जिस एप्लिकेशन सत्र के समय एसोसिएशन बदला वह जीवित था, उसे सुरंग फिर से स्वस्थ होने पर भी अपनी पुनर्प्राप्ति की आवश्यकता हो सकती है। उपयोगकर्ता इसे VPN के अभी भी टूटा होने के रूप में रिपोर्ट करेंगे।

रिलीज़ संस्करण, तय किए गए टाइमर और विफल चरण दर्ज करें। अगली पुनरावृत्ति की तुलना तब स्मृति से फिर वर्णन करने के बजाय इससे की जा सकेगी।