Client Kerio VPN su Linux: cinque controlli in ordine

Dopo l’installazione del client Kerio VPN su Linux non compare alcuna icona sul desktop e la rete privata resta fuori portata. È la forma normale di questo client, non un’installazione rotta: le istruzioni GFI per Linux descrivono configurazione da riga di comando e uno script di servizio, senza alcuna interfaccia grafica. Eseguite i controlli seguenti in ordine, perché ciascuno rimuove uno strato diverso. Il primo errore dice dove fermarsi, e saltare avanti di solito significa ricostruire un pacchetto che non è mai stato il problema.

Verificate che la build corrisponda alla macchina

Partite da ciò che dpkg pensa della macchina e per cui il pacchetto è stato compilato. Su un normale sistema a 64 bit, dpkg --print-architecture stampa amd64, e la pagina del fornitore elenca un pacchetto amd64 accanto a quello Debian ordinario. Leggete la stringa di versione nel nome del file che avete davvero installato invece di supporre che i due coincidano.

Un archivio del 2013 compilato per i386 non diventa a 64 bit solo perché avete passato --force-architecture all’installazione. Forzarlo installa binari estranei, nasconde un errore di dipendenza dietro un lanciatore che parte comunque e può lasciare il demone a caricare le librerie sbagliate. Se la versione che avete esiste solo a 32 bit, eseguitela in un ambiente a 32 bit o chiedete al responsabile del gateway una build aggiornata.

Controllate anche la riga delle dipendenze. dpkg -s kerio-control-vpnclient | grep -i depends mostra cosa si aspetta il pacchetto, e un vincolo di versione non soddisfatto o una libreria di runtime mancante emergono qui, non nel log del client.

Configuratelo con la procedura guidata del pacchetto

Per concezione il client non ha alcuna voce nel cassetto delle applicazioni, quindi un’icona mancante non dice nulla sulla riuscita della configurazione. Riaprite la procedura guidata con sudo dpkg-reconfigure kerio-control-vpnclient e rispondete alle sue domande: endpoint VPN, dati dell’account e impronta del certificato del server.

Trattate la domanda sull’impronta come l’unico punto in cui un server sbagliato può vincere. Confrontate il valore con le informazioni sul server fornite dall’amministratore che gestisce il gateway, non con ciò che presenta l’endpoint. Accettare un’impronta che non potete verificare trasforma il resto di questa lista in decorazione, perché un server ostile è identico a quello vero una volta memorizzato il pin. Se il valore non può essere confermato per un altro canale, fermatevi e chiedete, anche quando il tunnel si alzerebbe comunque.

Rieseguire la procedura guidata cambia la configurazione e può riavviare il client, quindi tenete un secondo accesso alla macchina quando la sessione su cui lavorate dipende da quella VPN. Digitate la password al prompt normale invece di incorporarla in un comando che finisce nella cronologia della shell.

Conoscete il file che la procedura guidata scrive

La configurazione vive in /etc/kerio-kvc.conf e porta sia l’account sia l’impronta appuntata. Trattatelo come materiale segreto. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf non dovrebbe mostrarlo come leggibile da tutti.

Dopo una modifica manuale autorizzata, ricaricate il demone che possiede il file invece di riavviare lo stack di rete: sudo /etc/init.d/kerio-kvc reload. Un ricaricamento rilegge la configurazione e abbatte la sessione corrente, quindi non è un’operazione neutra su una connessione attiva.

Copiate il file precedente prima di cambiare qualcosa. Se l’autenticazione fallisce dopo una modifica, ripristinare l’ultima copia buona richiede secondi e isola la modifica dalla rete, che è il modo più economico per sapere quale delle due si è mossa.

Separate la sessione attiva dal comportamento all’avvio

Lo script di servizio controlla la connessione corrente: sudo /etc/init.d/kerio-kvc stop chiude il tunnel subito e start lo riporta su. Nessuno dei due comandi decide cosa accadrà al prossimo avvio, e quella differenza conta su una macchina che amministrate da remoto.

Verificate chi possiede l’avvio prima di rimuovere collegamenti o mascherare qualcosa. Il pacchetto può installare un proprio script init, generare una unit o fare entrambe le cose, e disattivare il nome sbagliato fa tornare il client dopo un riavvio. Controllate systemctl status kerio-kvc rispetto al nome usato dalla documentazione del pacchetto, poi disattivate il percorso che il processo di avvio legge davvero.

Non sostituite una unit OpenVPN solo perché la configurazione sembra simile. Questo client parla il proprio protocollo con il gateway Kerio, quindi un altro demone puntato allo stesso file non si autenticherà, e l’errore in più rende le prove più difficili da leggere. Il client GFI per Linux tiene anche una sola connessione VPN alla volta; quel limite vale per il client, non per la capacità utenti del gateway.

Leggete i registri, poi verificate la risorsa

Tre file sotto /var/log/kerio-kvc raccontano la storia del demone: init.log per gli eventi del ciclo di vita, error.log per i guasti critici e debug.log per il dettaglio. Leggete l’estratto più piccolo che risponde alla vostra domanda, e togliete endpoint e nomi utente prima di incollarlo ovunque. Un vuoto in init.log intorno all’ora in cui avete eseguito la procedura guidata vi dice che il demone non è mai stato riavviato.

Un pacchetto valido, un demone in esecuzione e una risorsa raggiungibile sono tre risultati separati, e la lista è completa solo quando tutti e tre valgono. Dopo una modifica approvata, richiedete un host che esista solo dietro il gateway, poi apriteci un servizio normale. Se il tunnel è su e la risorsa no, il guasto residuo sta in una route del gateway o in una regola del firewall, non nel client che avete appena riconfigurato.

Annotate lo stato in cui avete finito: versione del pacchetto, architettura, se l’impronta è stata verificata per un altro canale e quale ricaricamento o riavvio avete eseguito. È quella nota che rende economico il primo controllo della persona successiva.