Client Kerio VPN sous Linux : cinq vérifications dans l’ordre

Après l’installation du client Kerio VPN sous Linux, aucune icône n’apparaît sur le bureau et le réseau privé reste hors de portée. C’est la forme normale de ce client, et non une installation cassée : les instructions de GFI pour Linux décrivent une configuration en ligne de commande et un script de service, sans aucune interface graphique. Déroulez les vérifications ci-dessous dans l’ordre, car chacune lève une couche différente. Le premier échec vous dit où vous arrêter, et sauter en avant revient le plus souvent à reconstruire un paquet qui n’a jamais été le problème.

Vérifiez que la compilation correspond à la machine

Commencez par ce que dpkg pense de la machine et par ce pour quoi le paquet a été compilé. Sur un système normal en 64 bits, dpkg --print-architecture affiche amd64, et la page du fournisseur liste un paquet amd64 à côté du paquet Debian ordinaire. Lisez la chaîne de version dans le nom du fichier que vous avez réellement installé au lieu de supposer que les deux concordent.

Une archive de 2013 compilée pour i386 ne devient pas 64 bits simplement parce que vous avez passé --force-architecture à l’installation. Le forçage installe des binaires étrangers, cache un échec de dépendance derrière un lanceur qui démarre quand même et peut laisser le démon charger les mauvaises bibliothèques. Si la version dont vous disposez n’existe qu’en 32 bits, exécutez-la dans un environnement 32 bits ou demandez au responsable de la passerelle une compilation à jour.

Vérifiez aussi la ligne des dépendances. dpkg -s kerio-control-vpnclient | grep -i depends montre ce que le paquet attend, et une contrainte de version non satisfaite ou une bibliothèque d’exécution manquante apparaît ici, et non dans le journal du client.

Configurez-le avec l’assistant du paquet

Par conception, le client n’a aucune entrée dans le tiroir des applications, donc une icône absente ne dit rien du succès de la configuration. Rouvrez l’assistant avec sudo dpkg-reconfigure kerio-control-vpnclient et répondez à ses questions : point de terminaison VPN, informations du compte et empreinte du certificat du serveur.

Traitez la question de l’empreinte comme le seul endroit où un mauvais serveur peut gagner. Comparez la valeur aux informations de serveur fournies par l’administrateur qui gère la passerelle, pas à ce que présente le point de terminaison. Accepter une empreinte que vous ne pouvez pas vérifier transforme le reste de cette liste en décoration, car un serveur hostile est identique au vrai une fois l’épingle enregistrée. Si la valeur ne peut pas être confirmée par un autre canal, arrêtez-vous et demandez, même si le tunnel devait se monter malgré tout.

Relancer l’assistant modifie la configuration et peut redémarrer le client, gardez donc un second accès à la machine lorsque la session sur laquelle vous travaillez dépend de ce VPN. Saisissez le mot de passe à l’invite habituelle au lieu de l’intégrer à une commande qui finira dans l’historique du shell.

Connaître le fichier qu’écrit l’assistant

La configuration réside dans /etc/kerio-kvc.conf et porte à la fois le compte et l’empreinte épinglée. Traitez-le comme un secret. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf ne devrait pas le montrer comme lisible par tous.

Après une modification manuelle autorisée, rechargez le démon qui possède le fichier au lieu de redémarrer la pile réseau : sudo /etc/init.d/kerio-kvc reload. Un rechargement relit la configuration et abandonne la session en cours, ce n’est donc pas une opération neutre sur une connexion active.

Copiez le fichier précédent avant de changer quoi que ce soit. Si l’authentification échoue après une modification, restaurer la dernière copie valide prend quelques secondes et isole la modification du réseau, ce qui est le moyen le moins coûteux de savoir laquelle des deux a bougé.

Séparez la session active du comportement au démarrage

Le script de service contrôle la connexion courante : sudo /etc/init.d/kerio-kvc stop termine le tunnel maintenant et start le rétablit. Aucune des deux commandes ne décide de ce qui se passera au prochain démarrage, et cette différence compte sur une machine que vous administrez à distance.

Vérifiez qui possède le démarrage avant de retirer des liens ou de masquer quoi que ce soit. Le paquet peut installer son propre script init, générer une unit ou faire les deux, et désactiver le mauvais nom laisse le client revenir après un redémarrage. Vérifiez systemctl status kerio-kvc par rapport au nom utilisé par la documentation du paquet, puis désactivez le chemin que le processus de démarrage lit réellement.

Ne remplacez pas une unit OpenVPN parce que la configuration se ressemble. Ce client parle son propre protocole à la passerelle Kerio, donc un autre démon pointé sur le même fichier ne s’authentifiera pas, et l’échec supplémentaire rend les preuves plus difficiles à lire. Le client GFI pour Linux ne tient par ailleurs qu’une seule connexion VPN à la fois ; cette limite vaut pour le client, pas pour la capacité d’utilisateurs de la passerelle.

Lisez les journaux, puis vérifiez la ressource

Trois fichiers sous /var/log/kerio-kvc racontent l’histoire du démon : init.log pour les événements de cycle de vie, error.log pour les défaillances critiques et debug.log pour le détail. Lisez le plus petit extrait qui répond à votre question, et retirez les points de terminaison et les noms d’utilisateur avant de le coller quelque part. Un trou dans init.log autour du moment où vous avez lancé l’assistant vous dit que le démon n’a jamais redémarré.

Un paquet valide, un démon en cours d’exécution et une ressource joignable sont trois résultats distincts, et la liste n’est terminée que lorsque les trois tiennent. Après un changement approuvé, demandez un hôte qui n’existe que derrière la passerelle, puis ouvrez-y un service ordinaire. Si le tunnel est monté et la ressource non, la panne restante siège dans une route de la passerelle ou une règle de pare-feu, et non dans le client que vous venez de reconfigurer.

Notez l’état dans lequel vous avez terminé : version du paquet, architecture, si l’empreinte a été vérifiée par un autre canal et quel rechargement ou redémarrage vous avez exécuté. C’est cette note qui rend la première vérification de la personne suivante peu coûteuse.