Клієнт 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 близько часу запуску майстра каже, що демон так і не було перезапущено.
| 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 |
Робочий пакет, працюючий демон і доступний ресурс — це три окремі результати, і список завершено лише тоді, коли всі три виконуються. Після схваленої зміни запитайте хост, який існує лише за шлюзом, а потім відкрийте на ньому звичайну службу. Якщо тунель піднято, а ресурс ні, залишкова несправність у маршруті шлюзу або правилі міжмережевого екрана, а не в клієнті, який ви щойно переналаштували.
Запишіть стан, у якому ви закінчили: випуск пакета, архітектуру, чи було відбиток перевірено іншим каналом і яке перезавантаження чи перезапуск ви виконали. Саме ця нотатка робить першу перевірку наступної людини дешевою.