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 |
मान्य प्याकेज, चलिरहेको डेमन र पुग्न सकिने स्रोत तीन अलग नतिजा हुन्, र तीनवटै मिलेपछि मात्र सूची पूरा हुन्छ। स्वीकृत परिवर्तनपछि गेटवेको पछाडि मात्र रहेको होस्ट माग्नुहोस्, त्यसपछि त्यसमा सामान्य सेवा खोल्नुहोस्। टनेल उठेको तर स्रोत नभएको अवस्थामा बाँकी दोष गेटवे मार्ग वा फायरवाल नियममा हुन्छ, अहिले पुनः कन्फिगर गरिएको क्लाइन्टमा होइन।
तपाईंले अन्त्य गरेको अवस्था लेख्नुहोस्: प्याकेज रिलिज, आर्किटेक्चर, फिंगरप्रिन्ट अर्को माध्यमबाट जाँचियो कि भएन, र कुन पुनः लोड वा पुनः सुरु गर्नुभयो। त्यही नोटले अर्को व्यक्तिको पहिलो जाँच सस्तो बनाउँछ।