Linux पर Kerio VPN क्लाइंट: क्रम से पाँच जाँचें

Linux पर Kerio VPN क्लाइंट इंस्टॉल करने के बाद डेस्कटॉप पर कोई आइकन नहीं दिखता और निजी नेटवर्क पहुँच से बाहर रहता है। यह इस क्लाइंट का सामान्य रूप है, टूटा हुआ इंस्टॉल नहीं: GFI के Linux निर्देश कमांड-लाइन कॉन्फ़िगरेशन और सेवा स्क्रिप्ट का वर्णन करते हैं, बिना किसी GUI के। नीचे दी गई जाँचें क्रम से करें, क्योंकि हर एक अलग परत हटाती है। पहली विफलता बताती है कि कहाँ रुकना है, और आगे कूदना आम तौर पर ऐसा पैकेज फिर से बनाना है जो कभी समस्या नहीं था।

पुष्टि करें कि बिल्ड मशीन से मेल खाता है

शुरू करें dpkg मशीन को क्या मानता है और पैकेज किसलिए बना था, इससे। सामान्य 64-बिट सिस्टम पर dpkg --print-architecture छापता है amd64, और विक्रेता का पेज सामान्य Debian पैकेज के साथ amd64 पैकेज सूचीबद्ध करता है। असल में इंस्टॉल की गई फ़ाइल के नाम में रिलीज़ स्ट्रिंग पढ़ें, यह मानने के बजाय कि दोनों मेल खाते हैं।

2013 का i386 के लिए बना आर्काइव केवल इसलिए 64-बिट नहीं हो जाता कि आपने --force-architecture पास किया। ज़बरदस्ती इंस्टॉल करने से विदेशी बाइनरी बैठती हैं, अभी भी चलने वाले लॉन्चर के पीछे निर्भरता की विफलता छिपती है, और डेमन गलत लाइब्रेरी लोड कर सकता है। अगर आपकी रिलीज़ केवल 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 में विज़ार्ड चलाने के समय के आसपास अंतराल होने का मतलब है कि डेमन कभी पुनः आरंभ नहीं हुआ।

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

जिस स्थिति में आपने अंत किया उसे दर्ज करें: पैकेज रिलीज़, आर्किटेक्चर, क्या फ़िंगरप्रिंट दूसरे चैनल से सत्यापित हुई, और कौन सा पुनः लोड या पुनः आरंभ किया। यही नोट अगले व्यक्ति की पहली जाँच सस्ती बनाता है।