Клиент 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 около времени запуска мастера говорит о том, что демон так и не был перезапущен.

Рабочий пакет, работающий демон и доступный ресурс — это три отдельных результата, и список завершён только тогда, когда верны все три. После одобренного изменения запросите хост, который существует только за шлюзом, а затем откройте на нём обычную службу. Если туннель поднят, а ресурс нет, оставшаяся неисправность кроется в маршруте шлюза или правиле межсетевого экрана, а не в клиенте, который вы только что перенастроили.

Запишите состояние, в котором вы закончили: выпуск пакета, архитектуру, был ли отпечаток проверен по другому каналу и какую перезагрузку или перезапуск вы выполнили. Именно эта заметка делает первую проверку следующего человека дешёвой.