vpnc 24 मिनट पर क्यों डिस्कनेक्ट होता है और क्या बदलें

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

तीन शर्तें तय करती हैं कि कौन-सा टाइमर आपका है: क्या क्लाइंट निष्क्रिय सत्र छोड़ देता है, क्या रीकी की अदला-बदली अस्वीकार होती है, और क्या किसी अनुवादक गेटवे ने एनकैप्सुलेशन फिर से लिखा है।

कौन-सा टाइमर इस टूटन का मालिक है

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

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

पहला मामला: क्लाइंट निष्क्रिय सत्र छोड़ देता है

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

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

क्लाइंट DPD बंद करना एक झूठा अलार्म हटाता है और आपकी एकमात्र स्थानीय पहचान भी हटा देता है, इसलिए इसे अकेले लागू करें और देखें कि अंतराल बिल्कुल बदलता है या नहीं।

दूसरा मामला: रीकी अस्वीकार होती है

यदि अंतराल DPD बदलाव के बाद भी टिका रहे, तो चरण 1 की रीकी उम्मीदवार बनती है। पुराने vpnc बिल्ड रीकी को मौजूदा की तुलना में कम सावधानी से संभालते थे, और सामान्य मतभेद Diffie-Hellman ग्रुप है। ऐसा ग्रुप थोपना जिसे हेड-एंड पहले ही स्वीकार करता है, एक पंक्ति और एक पुनःकनेक्शन का खर्च है, जो इसे नीति परिवर्तन के बजाय सस्ता प्रयोग बनाता है।

IKE DH Group dh5

मान्य ग्रुप नाम dh1, dh2 और dh5 हैं। कंसन्ट्रेटर जिस ग्रुप को अस्वीकार करता है वह तत्काल विफलता देता है, और वह भी जानकारी है: यह बताता है कि हेड-एंड नखरीला है और मूल ग्रुप शायद सही था।

तीसरा मामला: अनुवाद एनकैप्सुलेशन फिर से लिखता है

किसी अनुवादक गेटवे के पीछे Cisco का UDP एनकैप्सुलेशन और मानक-आधारित मोड एक-दूसरे के बदले नहीं लगाए जा सकते। गलत चुनाव अक्सर ऐसा टनल बनाता है जो स्थापित होता है, ट्रैफ़िक गुज़ारता है और फिर भार में समाप्त हो जाता है, जो बैंडविड्थ समस्या जैसा पढ़ा जाता है और नहीं है। केवल मोड बदलें, फिर दोबारा कनेक्ट करें और टूटन का समय फिर मापें। दूसरा मोड तभी आज़माएँ जब पहले दो मामले बाहर हो जाएँ।

फ्रंटएंड यहाँ अपनी उलझन जोड़ते हैं। NetworkManager तब तक vpnc कनेक्शन प्रकार नहीं देगा जब तक प्लगइन पैकेज स्थापित न हो, और गायब प्लगइन त्रुटि के बजाय धूसर Add बटन के रूप में दिखता है। KDE का फ्रंटएंड वही मान अपनी अलग प्रोफ़ाइल में रखता है, इसलिए पुष्टि करें कि डेमन वही पढ़ रहा है जो आपने संपादित किया।

ऐसी प्रोफ़ाइल जो कमांड लाइन से ठीक जुड़ती है पर डेस्कटॉप से नहीं, फ्रंटएंड की समस्या है, टाइमर की नहीं।

तीसरे बदलाव से पहले उस अदला-बदली की जाँच करें जो विफल होती है

क्लाइंट को डिबग आउटपुट के साथ चलाएँ और टूटन से पहले की अंतिम अदला-बदली पढ़ें। डिस्कनेक्ट से ठीक पहले चरण 1 का डिलीट मतलब क्लाइंट ने रीकी की और अस्वीकार कर दिया गया। उसी बिंदु पर चरण 2 का डिलीट मतलब टनल दूसरी ओर से ढहा दिया गया, और आपकी क्लाइंट सेटिंग्स कारण नहीं हैं।

vpnc --debug 3 office

जब टनल बचा रहे पर ट्रैफ़िक रुक जाए तो दूसरे नेटवर्क डेमन की भी जाँच करें। रूटिंग तालिका लिखने वाले दो प्रबंधक डेस्कटॉप से वही लक्षण और बिल्कुल अलग लॉग पैदा करते हैं।