Kerio VPN клиент под Linux: пет проверки по ред

След инсталиране на Kerio VPN клиента под Linux не се появява икона на работния плот и частната мрежа остава недостъпна. Това е нормалната форма на този клиент, а не счупена инсталация: инструкциите на GFI за Linux описват конфигуриране от командния ред и сервизен скрипт, без никакъв графичен интерфейс. Изпълнете проверките по-долу по ред, защото всяка премахва различен слой. Първият провал ви казва къде да спрете, а прескачането напред обикновено означава преизграждане на пакет, който никога не е бил проблемът.

Потвърдете, че сборката отговаря на машината

Започнете с това какво 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, данни за акаунта и отпечатък на сертификата на сървъра.

Отнасяйте се към въпроса за отпечатъка като към единственото място, където грешен сървър може да спечели. Сравнете стойността с информацията за сървъра от администратора, който управлява шлюза, а не с това, което крайната точка представя. Приемането на отпечатък, който не можете да проверите, превръща останалата част от този списък в украшение, защото враждебен сървър изглежда идентично на истинския, щом закрепването бъде запазено. Ако стойността не може да бъде потвърдена по друг канал, спрете и попитайте, дори когато тунелът иначе би се вдигнал.

Повторното пускане на съветника променя конфигурацията и може да рестартира клиента, затова дръжте втори път към машината, когато сесията, през която работите, зависи от този 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 срещу името, което документацията на пакета използва, след което изключете пътя, който процесът на зареждане действително чете.

Не подменяйте unit на OpenVPN, защото конфигурацията изглежда подобна. Този клиент говори със собствения си протокол към шлюза Kerio, така че друг демон, насочен към същия файл, няма да се удостовери, а допълнителният провал прави доказателствата по-трудни за четене. Клиентът на GFI за Linux също държи само една VPN връзка наведнъж; това ограничение важи за клиента, не за потребителския капацитет на шлюза.

Прочетете журналите, после проверете ресурса

Три файла под /var/log/kerio-kvc разказват историята на демона: init.log за събития от жизнения цикъл, error.log за критични повреди и debug.log за подробности. Четете най-малкия откъс, който отговаря на въпроса ви, и премахнете крайните точки и потребителските имена, преди да го поставите някъде. Пропуск в init.log около времето, когато сте пуснали съветника, ви казва, че демонът никога не се е рестартирал.

Валиден пакет, работещ демон и достъпен ресурс са три отделни резултата и списъкът е завършен само когато и трите са налице. След одобрена промяна поискайте хост, който съществува само зад шлюза, после отворете нормална услуга на него. Ако тунелът е вдигнат, а ресурсът не е, останалата повреда е в маршрут на шлюза или правило на защитната стена, а не в клиента, който току-що преконфигурирахте.

Запишете състоянието, с което завършихте: издание на пакета, архитектура, дали отпечатъкът е проверен по друг канал и кое презареждане или рестарт сте изпълнили. Тази бележка прави първата проверка на следващия човек евтина.