Kerio VPN კლიენტი Linux-ზე: ხუთი შემოწმება თანმიმდევრობით

Linux-ზე Kerio VPN კლიენტის დაყენების შემდეგ სამუშაო მაგიდაზე არანაირი ხატულა არ ჩნდება და კერძო ქსელი მიუწვდომელი რჩება. ეს ამ კლიენტის ნორმალური ფორმაა და არა გატეხილი ინსტალაცია: GFI-ის Linux-ის ინსტრუქციები აღწერს ბრძანების ხაზიდან კონფიგურაციას და სერვისის სკრიპტს, ყოველგვარი GUI-ს გარეშე. გაიარეთ ქვემოთ მოცემული შემოწმებები თანმიმდევრობით, რადგან თითოეული სხვადასხვა ფენას აშორებს. პირველი წარუმატებლობა გეუბნებათ, სად გაჩერდეთ, და წინ გადახტომა ჩვეულებრივ ნიშნავს იმ პაკეტის ხელახლა აწყობას, რომელიც არასდროს ყოფილა პრობლემა.

დაადასტურეთ, რომ აწყობა მანქანას შეესაბამება

დაიწყეთ იმით, რასაც dpkg ფიქრობს მანქანაზე და რისთვის აშენდა პაკეტი. ჩვეულებრივ 64-ბიტიან სისტემაში dpkg --print-architecture ბეჭდავს amd64, და მომწოდებლის გვერდი amd64 პაკეტს ჩვეულებრივი Debian-ის გვერდით ჩამოთვლის. წაიკითხეთ გამოშვების სტრიქონი იმ ფაილის სახელში, რომელიც ნამდვილად დააყენეთ, იმის ნაცვლად, რომ ჩათვალოთ, რომ ორივე ემთხვევა.

2013 წლის, i386-ისთვის აწყობილი არქივი 64-ბიტიანი არ ხდება მხოლოდ იმიტომ, რომ გადასცით --force-architecture დაყენებისას. იძულებითი დაყენება უცხო ბინარებს ამონტაჟებს, დამოკიდებულების ჩავარდნას მალავს ჯერ კიდევ მოქმედი გამშვების მიღმა და შეიძლება დაემონმა არასწორი ბიბლიოთეკები ჩატვირთოს. თუ თქვენი გამოშვება მხოლოდ 32-ბიტიანია, გაუშვით ის 32-ბიტიან გარემოში ან სთხოვეთ კარიბჭის მფლობელს ახალი აწყობა.

შეამოწმეთ დამოკიდებულების ხაზიც. dpkg -s kerio-control-vpnclient | grep -i depends აჩვენებს, თუ რას ელის პაკეტი, და შეუსრულებელი ვერსიის შეზღუდვა ან დაკარგული გაშვების ბიბლიოთეკა აქ ვლინდება, არა კლიენტის ჟურნალში.

კონფიგურაცია ჩაატარეთ პაკეტის ოსტატით

დიზაინით კლიენტს პროგრამების უჯრაში ჩანაწერი არ აქვს, ამიტომ დაკარგული ხატულა არაფერს ამბობს იმაზე, წარმატებული იყო თუ არა კონფიგურაცია. ხელახლა გახსენით ოსტატი ბრძანებით sudo dpkg-reconfigure kerio-control-vpnclient და უპასუხეთ მის კითხვებს: VPN-ის საბოლოო წერტილი, ანგარიშის მონაცემები და სერვერის სერტიფიკატის თითის ანაბეჭდი.

თითის ანაბეჭდის კითხვა მიიჩნიეთ ერთადერთ ადგილად, სადაც არასწორ სერვერს შეუძლია გაიმარჯვოს. შეადარეთ მნიშვნელობა კარიბჭის ოპერატორისგან მიღებულ სერვერის ინფორმაციას, და არა იმას, რასაც საბოლოო წერტილი წარმოადგენს. იმ ანაბეჭდის მიღება, რომელსაც ვერ ამოწმებთ, ამ სიის დანარჩენს მხოლოდ მორთულობად აქცევს, რადგან მტრული სერვერი pin-ის შენახვის შემდეგ ნამდვილის იდენტური ჩანს. თუ მნიშვნელობის სხვა არხით დადასტურება შეუძლებელია, გაჩერდით და იკითხეთ, მაშინაც კი, როცა გვირაბი სხვაგვარად ასდგებოდა.

ოსტატის ხელახლა გაშვება ცვლის კონფიგურაციას და შეიძლება კლიენტი გადატვირთოს, ამიტომ შეინარჩუნეთ მეორე გზა მანქანამდე, როცა სესია, რომელზეც მუშაობთ, ამ VPN-ზეა დამოკიდებული. აკრიფეთ პაროლი ჩვეულებრივ მოთხოვნაზე, ნაცვლად იმისა, რომ ჩასვათ ის ბრძანებაში, რომელიც shell-ის ისტორიაში მოხვდება.

იცოდეთ ფაილი, რომელსაც ოსტატი წერს

კონფიგურაცია მდებარეობს /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 ფაილში ოსტატის გაშვების დროის ირგვლივ არსებული უფსკრული გეუბნებათ, რომ დემონი არასდროს გადატვირთულა.

ვალიდური პაკეტი, მომუშავე დემონი და მისაწვდომი რესურსი სამი ცალკე შედეგია, და სია დასრულებულია მხოლოდ მაშინ, როცა სამივე სრულდება. დამტკიცებული ცვლილების შემდეგ მოითხოვეთ ჰოსტი, რომელიც მხოლოდ კარიბჭის მიღმა არსებობს, შემდეგ გახსენით მასზე ჩვეულებრივი სერვისი. თუ გვირაბი აწეულია და რესურსი არა, დარჩენილი ხარვეზი კარიბჭის მარშრუტში ან firewall-ის წესშია, და არა იმ კლიენტში, რომელიც ახლახან ხელახლა დააკონფიგურეთ.

ჩაწერეთ მდგომარეობა, რომლითაც დაასრულეთ: პაკეტის გამოშვება, არქიტექტურა, დადასტურდა თუ არა თითის ანაბეჭდი სხვა არხით და რომელი გადატვირთვა ან გაშვება შეასრულეთ. სწორედ ეს ჩანაწერი ხდის შემდეგი ადამიანის პირველ შემოწმებას იაფს.