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

सुरुङ टिके पनि ट्राफिक रोकिँदा दोस्रो सञ्जाल डेमन पनि जाँच्नुहोस्। राउटिङ तालिका लेख्ने दुई प्रबन्धकले डेस्कटपबाट त्यही लक्षण र पूर्ण रूपमा फरक लग बनाउँछन्।