Клијент 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 око времена када сте покренули чаробњака каже вам да демон никада није био рестартован.

Важећи пакет, демон који ради и доступан ресурс су три одвојена резултата, и листа је завршена само када сва три важе. После одобрене промене, затражите домаћина који постоји само иза капије, затим отворите нормалну услугу на њему. Ако је тунел подигнут, а ресурс није, преостали дефект је у рути капије или правилу заштитног зида, а не у клијенту који сте управо реконфигурисали.

Запишите стање у коме сте завршили: издање пакета, архитектуру, да ли је отисак проверен преко другог канала и које поновно учитавање или рестартовање сте извели. Управо та белешка чини прву проверу следеће особе јефтином.