Cliente Kerio VPN en Linux: cinco comprobaciones en orden

Tras instalar el cliente Kerio VPN en Linux no aparece ningún icono en el escritorio y la red privada sigue fuera de alcance. Esa es la forma normal de este cliente y no una instalación rota: las instrucciones de GFI para Linux describen configuración por línea de comandos y un script de servicio, sin ninguna interfaz gráfica. Recorra las comprobaciones siguientes en orden, porque cada una despeja una capa distinta. El primer fallo le dice dónde detenerse, y saltar hacia delante suele significar reconstruir un paquete que nunca fue el problema.

Confirme que la compilación coincide con la máquina

Empiece por lo que dpkg cree que es la máquina y para qué se compiló el paquete. En un sistema normal de 64 bits, dpkg --print-architecture imprime amd64, y la página del proveedor lista un paquete amd64 junto al Debian habitual. Lea la cadena de versión en el nombre del archivo que instaló realmente en lugar de suponer que ambos coinciden.

Un archivo de 2013 compilado para i386 no se vuelve de 64 bits solo porque haya pasado --force-architecture al instalarlo. Forzarlo instala binarios ajenos, oculta un fallo de dependencia tras un lanzador que aún arranca y puede dejar que el demonio cargue las bibliotecas equivocadas. Si la versión que tiene solo se distribuye en 32 bits, ejecútela en un entorno de 32 bits o pida al propietario de la puerta de enlace una compilación actual.

Compruebe también la línea de dependencias. dpkg -s kerio-control-vpnclient | grep -i depends muestra qué espera el paquete, y una restricción de versión no satisfecha o una biblioteca de ejecución ausente aparecen aquí, no en el registro del cliente.

Configúrelo con el asistente del paquete

Por diseño, el cliente no tiene entrada en el cajón de aplicaciones, así que un icono ausente no dice nada sobre si la configuración tuvo éxito. Vuelva a abrir el asistente con sudo dpkg-reconfigure kerio-control-vpnclient y responda sus preguntas: punto final de VPN, datos de la cuenta y huella del certificado del servidor.

Trate la pregunta de la huella como el único lugar donde un servidor equivocado puede ganar. Compare el valor con la información del servidor que dé el administrador que gestiona la puerta de enlace, no con lo que presente el punto final. Aceptar una huella que no puede verificar convierte el resto de esta lista en decoración, porque un servidor hostil parece idéntico al real una vez guardado el pin. Si el valor no se puede confirmar por otro canal, deténgase y pregunte, incluso cuando el túnel fuera a levantarse igualmente.

Volver a ejecutar el asistente cambia la configuración y puede reiniciar el cliente, así que mantenga una segunda vía hacia la máquina cuando la sesión con la que trabaja dependa de esa VPN. Escriba la contraseña en el aviso normal en lugar de incrustarla en un comando que acabe en el historial del intérprete.

Conozca el archivo que escribe el asistente

La configuración vive en /etc/kerio-kvc.conf y lleva tanto la cuenta como la huella fijada. Trátelo como material secreto. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf no debería mostrarlo como legible para todos.

Tras una edición manual autorizada, recargue el demonio que posee el archivo en lugar de reiniciar la pila de red: sudo /etc/init.d/kerio-kvc reload. Una recarga relee la configuración y suelta la sesión actual, así que no es una no-operación en una conexión viva.

Copie el archivo anterior antes de cambiar nada. Si la autenticación falla tras una edición, restaurar la última copia buena tarda segundos y aísla la edición de la red, que es la forma más barata de averiguar cuál de las dos se movió.

Separe la sesión viva del comportamiento de arranque

El script de servicio controla la conexión actual: sudo /etc/init.d/kerio-kvc stop termina el túnel ahora y start lo devuelve. Ninguno de los dos comandos decide qué ocurre en el próximo arranque, y esa diferencia importa en una máquina que administra en remoto.

Averigüe quién posee el arranque antes de quitar enlaces o enmascarar algo. El paquete puede instalar su propio script init, generar una unit o hacer ambas cosas, y desactivar el nombre equivocado devuelve el cliente tras un reinicio. Compruebe systemctl status kerio-kvc contra el nombre que usa la documentación del paquete y luego desactive la ruta que el proceso de arranque lee de verdad.

No sustituya una unit de OpenVPN porque la configuración se parezca. Este cliente habla su propio protocolo con la puerta de enlace Kerio, así que otro demonio apuntado al mismo archivo no se autenticará, y el fallo extra hace más difícil leer las pruebas. El cliente de GFI para Linux también mantiene una sola conexión VPN a la vez; ese límite se aplica al cliente, no a la capacidad de usuarios de la puerta de enlace.

Lea los registros y luego verifique el recurso

Tres archivos bajo /var/log/kerio-kvc cuentan la historia del demonio: init.log para eventos del ciclo de vida, error.log para fallos críticos y debug.log para el detalle. Lea el fragmento más pequeño que responda a su pregunta y quite los puntos finales y los nombres de usuario antes de pegarlo en cualquier parte. Un hueco en init.log alrededor de la hora en que ejecutó el asistente le dice que el demonio nunca se reinició.

Un paquete válido, un demonio en marcha y un recurso accesible son tres resultados separados, y la lista solo termina cuando se cumplen los tres. Tras un cambio aprobado, solicite un host que solo exista detrás de la puerta de enlace y luego abra un servicio normal en él. Si el túnel está levantado y el recurso no, el fallo restante está en una ruta de la puerta de enlace o en una regla del cortafuegos, no en el cliente que acaba de reconfigurar.

Anote el estado con el que terminó: versión del paquete, arquitectura, si la huella se verificó por otro canal y qué recarga o reinicio ejecutó. Esa nota es lo que hace barata la primera comprobación de la persona siguiente.