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

बोगदा टिकतो पण रहदारी थांबते तेव्हा दुसरा नेटवर्क डेमनही तपासा। राउटिंग टेबल लिहिणारे दोन व्यवस्थापक डेस्कटॉपवरून तेच लक्षण आणि पूर्णपणे वेगळा लॉग निर्माण करतात।