Cliente Kerio VPN no Linux: cinco verificações em ordem

Depois de instalar o cliente Kerio VPN no Linux não aparece qualquer ícone no ambiente de trabalho e a rede privada continua fora de alcance. É a forma normal deste cliente e não uma instalação avariada: as instruções da GFI para Linux descrevem configuração pela linha de comandos e um script de serviço, sem qualquer interface gráfica. Percorra as verificações abaixo por ordem, porque cada uma remove uma camada diferente. A primeira falha diz-lhe onde parar, e saltar à frente significa geralmente reconstruir um pacote que nunca foi o problema.

Confirme que a compilação corresponde à máquina

Comece pelo que o dpkg pensa que a máquina é e para que foi compilado o pacote. Num sistema normal de 64 bits, o dpkg --print-architecture imprime amd64, e a página do fornecedor lista um pacote amd64 ao lado do pacote Debian habitual. Leia a cadeia de versão no nome do ficheiro que instalou realmente em vez de assumir que ambos coincidem.

Um arquivo de 2013 compilado para i386 não se torna de 64 bits só porque passou --force-architecture na instalação. Forçá-lo instala binários alheios, esconde uma falha de dependência atrás de um lançador que ainda arranca e pode deixar o daemon carregar as bibliotecas erradas. Se a versão que tem só existe em 32 bits, execute-a num ambiente de 32 bits ou peça ao responsável pelo gateway uma compilação atual.

Verifique também a linha de dependências. dpkg -s kerio-control-vpnclient | grep -i depends mostra o que o pacote espera, e uma restrição de versão não satisfeita ou uma biblioteca de execução em falta aparecem aqui, não no registo do cliente.

Configure-o com o assistente do pacote

Por conceção, o cliente não tem entrada na gaveta de aplicações, por isso um ícone em falta não diz nada sobre o sucesso da configuração. Volte a abrir o assistente com sudo dpkg-reconfigure kerio-control-vpnclient e responda às perguntas: ponto final de VPN, dados da conta e impressão digital do certificado do servidor.

Trate a pergunta da impressão digital como o único local onde um servidor errado pode ganhar. Compare o valor com a informação do servidor dada pelo administrador que gere o gateway, não com o que o ponto final apresenta. Aceitar uma impressão digital que não pode verificar transforma o resto desta lista em decoração, porque um servidor hostil parece idêntico ao real depois de o pin ser guardado. Se o valor não puder ser confirmado por outro canal, pare e pergunte, mesmo quando o túnel fosse subir de qualquer forma.

Voltar a executar o assistente altera a configuração e pode reiniciar o cliente, por isso mantenha um segundo caminho para a máquina quando a sessão em que trabalha depende dessa VPN. Escreva a palavra-passe no pedido habitual em vez de a incorporar num comando que acabe no histórico da shell.

Conheça o ficheiro que o assistente escreve

A configuração vive em /etc/kerio-kvc.conf e transporta tanto a conta como a impressão digital fixada. Trate-o como material secreto. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf não o deve mostrar como legível por todos.

Após uma edição manual autorizada, recarregue o daemon que é dono do ficheiro em vez de reiniciar a pilha de rede: sudo /etc/init.d/kerio-kvc reload. Uma recarga relê a configuração e descarta a sessão atual, pelo que não é uma não-operação numa ligação viva.

Copie o ficheiro anterior antes de mudar seja o que for. Se a autenticação falhar depois de uma edição, restaurar a última cópia boa leva segundos e isola a edição da rede, que é a forma mais barata de saber qual das duas se moveu.

Separe a sessão viva do comportamento de arranque

O script de serviço controla a ligação atual: sudo /etc/init.d/kerio-kvc stop termina o túnel agora e start fá-lo voltar. Nenhum dos comandos decide o que acontece no arranque seguinte, e essa diferença importa numa máquina que administra remotamente.

Verifique quem é dono do arranque antes de remover ligações ou mascarar algo. O pacote pode instalar o seu próprio script init, gerar uma unit ou ambas as coisas, e desativar o nome errado faz o cliente voltar depois de um reinício. Verifique systemctl status kerio-kvc contra o nome que a documentação do pacote usa e depois desative o caminho que o processo de arranque lê de facto.

Não substitua uma unit de OpenVPN só porque a configuração parece semelhante. Este cliente fala o seu próprio protocolo com o gateway Kerio, por isso outro daemon apontado ao mesmo ficheiro não se autenticará, e a falha extra torna as provas mais difíceis de ler. O cliente da GFI para Linux também mantém apenas uma ligação VPN de cada vez; esse limite aplica-se ao cliente, não à capacidade de utilizadores do gateway.

Leia os registos e depois verifique o recurso

Três ficheiros em /var/log/kerio-kvc contam a história do daemon: init.log para eventos de ciclo de vida, error.log para falhas críticas e debug.log para detalhe. Leia o excerto mais pequeno que responde à sua pergunta, e remova pontos finais e nomes de utilizador antes de o colar em qualquer lado. Uma lacuna em init.log em torno da hora a que executou o assistente diz-lhe que o daemon nunca foi reiniciado.

Um pacote válido, um daemon em execução e um recurso alcançável são três resultados separados, e a lista só termina quando os três se verificam. Após uma alteração aprovada, peça um anfitrião que só exista atrás do gateway e depois abra nele um serviço normal. Se o túnel está de pé e o recurso não, a falha restante está numa rota do gateway ou numa regra da firewall, não no cliente que acabou de reconfigurar.

Registe o estado em que terminou: versão do pacote, arquitetura, se a impressão digital foi verificada por outro canal e que recarga ou reinício executou. É essa nota que torna barata a primeira verificação da pessoa seguinte.