Cliente Kerio VPN en Linux: cinco comprobacións por orde

Despois de instalar o cliente Kerio VPN en Linux non aparece ningún icono no escritorio e a rede privada segue fóra de alcance. Esa é a forma normal deste cliente e non unha instalación rota: as instrucións de GFI para Linux describen configuración por liña de ordes e un script de servizo, sen ningunha interface gráfica. Percorra as comprobacións seguintes por orde, porque cada unha elimina unha capa distinta. O primeiro fallo dille onde deter, e saltar cara adiante adoita significar reconstruír un paquete que nunca foi o problema.

Confirme que a compilación coincide coa máquina

Comece polo que dpkg cre que é a máquina e para que se compilou o paquete. Nun sistema normal de 64 bits, dpkg --print-architecture imprime amd64, e a páxina do provedor lista un paquete amd64 xunto ao Debian habitual. Lea a cadea de versión no nome do ficheiro que instalou realmente no canto de supor que ambos coinciden.

Un arquivo de 2013 compilado para i386 non se converte en 64 bits só porque pasase --force-architecture ao instalalo. Forzalo instala binarios alleos, agocha un fallo de dependencia tras un lanzador que aínda arranca e pode deixar que o daemon cargue as bibliotecas equivocadas. Se a versión que ten só se distribúe en 32 bits, executeda nun contorno de 32 bits ou pida ao propietario da pasarela unha compilación actual.

Comprobe tamén a liña de dependencias. dpkg -s kerio-control-vpnclient | grep -i depends mostra que espera o paquete, e unha restrición de versión non satisfeita ou unha biblioteca de execución ausente aparecen aquí, non no rexistro do cliente.

Configureo co asistente do paquete

Por deseño, o cliente non ten entrada no caixón de aplicacións, así que unha icona ausente non di nada sobre se a configuración tivo éxito. Volva abrir o asistente con sudo dpkg-reconfigure kerio-control-vpnclient e responda as súas preguntas: punto final de VPN, datos da conta e pegada do certificado do servidor.

Trate a pregunta da pegada como o único lugar onde un servidor equivocado pode gañar. Compare o valor coa información do servidor que dea o administrador que xestiona a pasarela, non co que presente o punto final. Aceptar unha pegada que non pode verificar converte o resto desta lista en decoración, porque un servidor hostil parece idéntico ao real unha vez gardado o pin. Se o valor non se pode confirmar por outra canle, detéñase e pregunte, mesmo cando o túnel ía levantarse igualmente.

Volver executar o asistente cambia a configuración e pode reiniciar o cliente, así que manteña unha segunda vía cara á máquina cando a sesión coa que traballa dependa desta VPN. Escriba o contrasinal no aviso normal no canto de incrustalo nunha orde que acabe no historial da consola.

Coñeza o ficheiro que escribe o asistente

A configuración vive en /etc/kerio-kvc.conf e leva tanto a conta como a pegada fixada. Tráteo como material secreto. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf non debería mostralo como lexible para todos.

Tras unha edición manual autorizada, recargue o daemon que posúe o ficheiro no canto de reiniciar a pila de rede: sudo /etc/init.d/kerio-kvc reload. Unha recarga volve ler a configuración e solta a sesión actual, así que non é unha non-operación nunha conexión viva.

Copie o ficheiro anterior antes de cambiar nada. Se a autenticación falla tras unha edición, restaurar a última copia boa leva segundos e illa a edición da rede, que é a forma máis barata de saber cal das dúas se moveu.

Separe a sesión viva do comportamento de arranque

O script de servizo controla a conexión actual: sudo /etc/init.d/kerio-kvc stop remata o túnel agora e start tráeo de volta. Ningunha das dúas ordes decide que ocorre no seguinte arranque, e esa diferenza importa nunha máquina que administra en remoto.

Averigüe quen posúe o arranque antes de retirar ligazóns ou enmascarar algo. O paquete pode instalar o seu propio script init, xerar unha unit ou facer ambas as cousas, e desactivar o nome equivocado devolve o cliente tras un reinicio. Comprobe systemctl status kerio-kvc contra o nome que usa a documentación do paquete e logo desactive a ruta que o proceso de arranque le de verdade.

Non substitúa unha unit de OpenVPN porque a configuración se pareza. Este cliente fala o seu propio protocolo coa pasarela Kerio, así que outro daemon apuntado ao mesmo ficheiro non se autenticará, e o fallo extra fai máis difícil ler as probas. O cliente de GFI para Linux tamén mantén unha soa conexión VPN á vez; ese límite aplícase ao cliente, non á capacidade de usuarios da pasarela.

Lea os rexistros e logo verifique o recurso

Tres ficheiros baixo /var/log/kerio-kvc contan a historia do daemon: init.log para eventos do ciclo de vida, error.log para fallos críticos e debug.log para o detalle. Lea o fragmento máis pequeno que responda á súa pregunta e quite os puntos finais e os nomes de usuario antes de pegralo en calquera parte. Un oco en init.log arredor da hora en que executou o asistente dille que o daemon nunca se reiniciou.

Un paquete válido, un daemon en marcha e un recurso accesible son tres resultados separados, e a lista só remata cando se cumpren os tres. Tras un cambio aprobado, solicite un host que só exista detrás da pasarela e logo abra un servizo normal nel. Se o túnel está levantado e o recurso non, o fallo restante está nunha ruta da pasarela ou nunha regra da devasa, non no cliente que acaba de reconfigurar.

Anote o estado co que rematou: versión do paquete, arquitectura, se a pegada se verificou por outra canle e que recarga ou reinicio executou. Esa nota é o que fai barata a primeira comprobación da persoa seguinte.