Client Kerio VPN a Linux: cinc comprovacions en ordre

Després d’instal·lar el client Kerio VPN a Linux no apareix cap icona a l’escriptori i la xarxa privada continua fora de l’abast. Aquesta és la forma normal d’aquest client i no pas una instal·lació trencada: les instruccions de GFI per a Linux descriuen configuració per línia d’ordres i un script de servei, sense cap interfície gràfica. Feu les comprovacions següents en ordre, perquè cadascuna elimina una capa diferent. El primer error us diu on aturar-vos, i saltar endavant sol significar reconstruir un paquet que mai no era el problema.

Confirmeu que la compilació coincideix amb la màquina

Comenceu amb què dpkg creu que és la màquina i per a què es va compilar el paquet. En un sistema normal de 64 bits, dpkg --print-architecture imprimeix amd64, i la pàgina del proveïdor llista un paquet amd64 al costat del Debian habitual. Llegiu la cadena de versió al nom del fitxer que realment vau instal·lar en lloc de suposar que tots dos coincideixen.

Un arxiu del 2013 compilat per a i386 no es converteix en 64 bits només perquè hàgiu passat --force-architecture en instal·lar-lo. Forçar-ho instal·la binaris estranys, amaga un error de dependència darrere d’un llançador que encara arrenca i pot deixar que el dimoni carregui les biblioteques equivocades. Si la versió que teniu només es distribueix en 32 bits, executeu-la en un entorn de 32 bits o demaneu al propietari de la passarel·la una compilació actual.

Comproveu també la línia de dependències. dpkg -s kerio-control-vpnclient | grep -i depends mostra què espera el paquet, i una restricció de versió no satisfeta o una biblioteca d’execució absent apareixen aquí, no al registre del client.

Configureu-lo amb l’assistent del paquet

Per disseny, el client no té cap entrada al calaix d’aplicacions, així que una icona absent no diu res sobre si la configuració va reeixir. Torneu a obrir l’assistent amb sudo dpkg-reconfigure kerio-control-vpnclient i responeu les seves preguntes: punt final de VPN, dades del compte i empremta del certificat del servidor.

Tracteu la pregunta de l’empremta com l’únic lloc on un servidor equivocat pot guanyar. Compareu el valor amb la informació del servidor que us doni l’administrador que gestiona la passarel·la, no amb el que presenti el punt final. Acceptar una empremta que no podeu verificar converteix la resta d’aquesta llista en decoració, perquè un servidor hostil sembla idèntic al real un cop desat el pin. Si el valor no es pot confirmar per un altre canal, atureu-vos i pregunteu, fins i tot quan el túnel s’aixecaria igualment.

Tornar a executar l’assistent canvia la configuració i pot reiniciar el client, així que tingueu un segon camí cap a la màquina quan la sessió amb què treballeu depèn d’aquella VPN. Escriviu la contrasenya al prompt habitual en lloc d’incrustar-la en una ordre que acabi a l’historial de l’intèrpret.

Conèixer el fitxer que escriu l’assistent

La configuració viu a /etc/kerio-kvc.conf i porta tant el compte com l’empremta fixada. Tracteu-lo com a material secret. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf no hauria de mostrar-lo com a llegible per a tothom.

Després d’una edició manual autoritzada, recarregueu el dimoni que posseeix el fitxer en lloc de reiniciar la pila de xarxa: sudo /etc/init.d/kerio-kvc reload. Una recàrrega rellegeix la configuració i deixa anar la sessió actual, així que no és una no-operació en una connexió viva.

Copieu el fitxer anterior abans de canviar res. Si l’autenticació falla després d’una edició, restaurar l’última còpia bona triga segons i aïlla l’edició de la xarxa, que és la manera més barata d’esbrinar quina de les dues s’ha mogut.

Separeu la sessió viva del comportament d’arrencada

El script de servei controla la connexió actual: sudo /etc/init.d/kerio-kvc stop atura el túnel ara i start el torna a aixecar. Cap de les dues ordres decideix què passarà a la propera arrencada, i aquesta diferència importa en una màquina que administreu remotament.

Esbrineu qui posseeix l’arrencada abans de treure enllaços o emmascarar res. El paquet pot instal·lar el seu propi script init, generar una unit o fer les dues coses, i desactivar el nom equivocat fa tornar el client després de reiniciar. Comproveu systemctl status kerio-kvc contra el nom que fa servir la documentació del paquet i després desactiveu el camí que el procés d’arrencada llegeix de debò.

No substituïu una unit d’OpenVPN perquè la configuració s’assembla. Aquest client parla el seu propi protocol amb la passarel·la Kerio, així que un altre dimoni apuntat al mateix fitxer no s’autenticarà, i l’error extra fa més difícil llegir les proves. El client de GFI per a Linux també manté una sola connexió VPN alhora; aquest límit s’aplica al client, no a la capacitat d’usuaris de la passarel·la.

Llegiu els registres i llavors verifiqueu el recurs

Tres fitxers sota /var/log/kerio-kvc expliquen la història del dimoni: init.log per als esdeveniments de cicle de vida, error.log per a les fallades crítiques i debug.log per al detall. Llegiu el fragment més petit que respongui la vostra pregunta i traieu els punts finals i els noms d’usuari abans d’enganxar-lo enlloc. Un buit a init.log al voltant de l’hora en què vau executar l’assistent us diu que el dimoni no es va reiniciar mai.

Un paquet vàlid, un dimoni en marxa i un recurs abastable són tres resultats separats, i la llista només s’acaba quan es compleixen tots tres. Després d’un canvi aprovat, demaneu un amfitrió que només existeixi darrere la passarel·la i obriu-hi un servei normal. Si el túnel està aixecat i el recurs no, la fallada restant és en una ruta de la passarel·la o en una regla del tallafoc, no en el client que acabeu de reconfigurar.

Anoteu l’estat amb què heu acabat: versió del paquet, arquitectura, si l’empremta es va verificar per un altre canal i quina recàrrega o reinici vau executar. Aquesta nota és el que fa barata la primera comprovació de la persona següent.