Linux वर Kerio VPN क्लायंट: क्रमाने पाच तपासण्या
क्रमाने पाच तपासण्या: पॅकेज आर्किटेक्चर, CLI विझार्ड, कॉन्फिग फाइल, सेवा स्क्रिप्ट आणि लॉग. पहिल्या अयशस्वी तपासणीवर थांबा.
Linux वर Kerio VPN क्लायंट इन्स्टॉल केल्यानंतर डेस्कटॉपवर कोणतेही चिन्ह दिसत नाही आणि खाजगी नेटवर्क पोहोचाबाहेर राहते। ही या क्लायंटची सामान्य अवस्था आहे, तुटलेली इन्स्टॉल नाही: GFI च्या Linux सूचना कमांड-लाइन कॉन्फिगरेशन आणि सेवा स्क्रिप्टचे वर्णन करतात, कोणतेही GUI नाही। खालील तपासण्या क्रमाने करा, कारण प्रत्येक वेगळा थर काढते। पहिली अयशस्वी तपासणी कुठे थांबायचे ते सांगते, आणि पुढे उडी मारणे म्हणजे सहसा अशा पॅकेजची पुनर्बांधणी जे कधीच समस्या नव्हते।
बिल्ड मशीनशी जुळते याची खात्री करा
सुरुवात करा dpkg मशीन काय आहे आणि पॅकेज कशासाठी बांधले गेले हे दाखवते। सामान्य 64-बिट सिस्टमवर dpkg --print-architecture छापते amd64, आणि विक्रेत्याचे पृष्ठ सामान्य Debian पॅकेजच्या शेजारी amd64 पॅकेज सूचीबद्ध करते। प्रत्यक्षात इन्स्टॉल केलेल्या फाइलच्या नावातील रिलीज स्ट्रिंग वाचा, दोन्ही जुळतात असे गृहीत धरण्याऐवजी।
2013 चे i386 साठी बांधलेले आर्काइव्ह केवळ --force-architecture दिल्यामुळे 64-बिट होत नाही। जबरदस्तीने इन्स्टॉल केल्यास परकीय बायनरी बसतात, अजूनही सुरू होणाऱ्या लाँचरमागे अवलंबित्वाचा अपयश लपते, आणि डीमन चुकीच्या लायब्ररी लोड करू शकतो। तुमची रिलीज केवळ 32-बिट असल्यास, ती 32-बिट वातावरणात चालवा किंवा गेटवे मालकाकडे नवीन बिल्ड मागा।
अवलंबित्व ओळही तपासा। dpkg -s kerio-control-vpnclient | grep -i depends पॅकेज काय अपेक्षिते दाखवते, आणि अपूर्ण आवृत्ती पिन किंवा गहाळ रनटाइम लायब्ररी येथे दिसते, क्लायंट लॉगमध्ये नाही।
पॅकेज विझार्डद्वारे ते कॉन्फिगर करा
रचनेनुसार क्लायंटची अ‍ॅप ड्रॉवरमध्ये नोंद नाही, त्यामुळे गहाळ चिन्ह कॉन्फिगरेशन यशस्वी झाले का याबद्दल काहीही सांगत नाही। विझार्ड पुन्हा उघडण्यासाठी sudo dpkg-reconfigure kerio-control-vpnclient चालवा आणि त्याच्या प्रश्नांची उत्तरे द्या: VPN एंडपॉइंट, खाते तपशील आणि सर्व्हर प्रमाणपत्राची फिंगरप्रिंट।
फिंगरप्रिंटच्या प्रश्नाकडे चुकीचा सर्व्हर जिंकू शकतो असे एकमेव स्थान म्हणून पहा। मूल्याची तुलना गेटवे चालवणाऱ्या प्रशासकाने दिलेल्या सर्व्हर माहितीशी करा, एंडपॉइंट जे सादर करतो त्याशी नाही। तपासता न येणारी फिंगरप्रिंट स्वीकारल्यास या यादीचा उर्वरित भाग केवळ सजावट होतो, कारण पिन साठवल्यानंतर शत्रुत्वाचा सर्व्हर खऱ्यासारखाच दिसतो। मूल्य दुसऱ्या मार्गाने पुष्ट करता येत नसेल, तर टनेल अन्यथा उभा राहिला असता तरी थांबा आणि विचारा।
विझार्ड पुन्हा चालवल्यास कॉन्फिगरेशन बदलते आणि क्लायंट पुन्हा सुरू होऊ शकतो, म्हणून तुम्ही ज्या सत्रावर काम करत आहात ते त्या VPN वर अवलंबून असल्यास मशीनपर्यंत दुसरा मार्ग ठेवा। पासवर्ड शेल इतिहासात जाणाऱ्या कमांडमध्ये न घालता सामान्य प्रॉम्प्टवर टाइप करा।
विझार्ड जी फाइल लिहितो ती जाणून घ्या
कॉन्फिगरेशन येथे आहे: /etc/kerio-kvc.conf आणि त्यात खाते व पिन केलेली फिंगरप्रिंट दोन्ही आहेत। त्याला गुप्त सामग्री माना। sudo stat -c '%a %U %G' /etc/kerio-kvc.conf ते सर्वांना वाचनीय म्हणून दाखवू नये।
अधिकृत हस्तचलित संपादनानंतर, नेटवर्क स्टॅक पुन्हा सुरू करण्याऐवजी फाइलचा मालक डीमन पुन्हा लोड करा: sudo /etc/init.d/kerio-kvc reload। पुन्हा लोड केल्यास कॉन्फिगरेशन पुन्हा वाचले जाते आणि सध्याचे सत्र सोडले जाते, त्यामुळे जिवंत कनेक्शनवर ही निष्क्रिय क्रिया नाही।
काहीही बदलण्यापूर्वी मागील फाइलची प्रत घ्या। संपादनानंतर प्रमाणीकरण अयशस्वी झाल्यास, शेवटची कार्यरत प्रत पुनर्संचयित करण्यास सेकंद लागतात आणि संपादन नेटवर्कपासून वेगळे होते, दोन्हींपैकी कोण हलले हे जाणून घेण्याचा हा सर्वात स्वस्त मार्ग आहे।
जिवंत सत्र बूट वर्तनापासून वेगळे करा
सेवा स्क्रिप्ट सध्याचे कनेक्शन नियंत्रित करते: sudo /etc/init.d/kerio-kvc stop आता टनेल संपवते आणि start ते परत आणते। कोणतीही कमांड पुढील बूटवर काय होईल हे ठरवत नाही, आणि दूरून व्यवस्थापित मशीनवर हा फरक महत्त्वाचा आहे।
लिंक काढण्यापूर्वी किंवा काही मास्क करण्यापूर्वी स्टार्टअप कोणाचा आहे ते तपासा। पॅकेज स्वतःची init स्क्रिप्ट इन्स्टॉल करू शकते, unit तयार करू शकते, किंवा दोन्ही, आणि चुकीचे नाव निष्क्रिय केल्यास रीबूटनंतर क्लायंट परत येतो। systemctl status kerio-kvc पॅकेज दस्तऐवजात वापरल्या जाणाऱ्या नावाशी तपासा, नंतर बूट प्रक्रिया प्रत्यक्षात वाचत असलेला मार्ग निष्क्रिय करा।
कॉन्फिगरेशन सारखे दिसते म्हणून OpenVPN unit बदलू नका। हा क्लायंट Kerio गेटवेशी स्वतःच्या प्रोटोकॉलमध्ये बोलतो, म्हणून त्याच फाइलकडे निर्देशित दुसरा डीमन प्रमाणीकरण करणार नाही, आणि अतिरिक्त अपयश पुरावे वाचणे कठीण करते। GFI चा Linux क्लायंटही एका वेळी एकच VPN कनेक्शन ठेवतो; ही मर्यादा क्लायंटला लागू आहे, गेटवेच्या वापरकर्ता क्षमतेला नाही।
लॉग वाचा, नंतर स्त्रोत तपासा
तीन फाइलीं /var/log/kerio-kvc डीमनची कथा सांगतात: init.log जीवनचक्र घटनांसाठी, error.log गंभीर अपयशांसाठी आणि debug.log तपशिलांसाठी। तुमच्या प्रश्नाचे उत्तर देणारा सर्वात लहान उतारा वाचा, आणि कुठेही पेस्ट करण्यापूर्वी एंडपॉइंट व वापरकर्तानावे काढा। init.log मध्ये विझार्ड चालवल्याच्या वेळेच्या आसपास अंतर असल्यास डीमन कधीच पुन्हा सुरू झाला नाही हे कळते।
| File | Read it for | Skip it when |
|---|---|---|
init.log | start, reload and stop events | you already know the daemon restarted |
error.log | failed authentication and certificate problems | the tunnel is up and traffic still fails |
debug.log | protocol detail worth attaching to a ticket | the error is already named in error.log |
वैध पॅकेज, चालू डीमन आणि पोहोचण्यायोग्य स्त्रोत या तीन वेगळे निकाल आहेत, आणि तिन्ही पूर्ण झाल्यावरच यादी पूर्ण होते। मंजूर बदलानंतर गेटवेच्या मागेच असलेला होस्ट मागा, नंतर त्यावर सामान्य सेवा उघडा। टनेल उभा असून स्त्रोत नसेल, तर उर्वरित दोष गेटवे मार्गात किंवा फायरवॉल नियमात आहे, आत्ताच पुन्हा कॉन्फिगर केलेल्या क्लायंटमध्ये नाही।
तुम्ही ज्या स्थितीत संपले ती नोंदवा: पॅकेज रिलीज, आर्किटेक्चर, फिंगरप्रिंट दुसऱ्या मार्गाने तपासली गेली का, आणि कोणते पुन्हा लोड किंवा पुन्हा सुरू केले। तीच नोंद पुढच्या व्यक्तीची पहिली तपासणी स्वस्त करते।