Linux 上的 Kerio VPN 客户端：按顺序做五项检查
按顺序做五项检查：软件包架构、命令行向导、配置文件、服务脚本和日志。在第一个失败的检查处停下。
在 Linux 上装好 Kerio VPN 客户端后，桌面不出现任何图标，私有网络仍然无法访问。这是该客户端的正常形态，而不是安装损坏：GFI 的 Linux 说明只描述命令行配置和一个服务脚本，完全没有图形界面。请按下面的顺序逐项检查，因为每一项清掉的是不同的层。第一个失败点就告诉你该在哪里停下，而贸然往后跳，通常只是重装一个从来不是问题的软件包。
确认构建与机器匹配
先从 dpkg 对机器的判断，以及这个软件包是为哪种架构编译的开始。在普通的 64 位系统上，dpkg --print-architecture 会输出 amd64，而厂商页面会在普通 Debian 包旁边列出 amd64 包。请读你实际安装的那个文件名里的发行字符串，而不是假设两者一致。
为 i386 编译的 2013 年归档不会因为--force-architecture就变成 64 位。强行安装会装入外来的二进制文件，把依赖失败藏在仍能启动的启动器后面，还可能让守护进程加载错误的库。如果你手上的发行版只有 32 位，就在 32 位环境里运行，或者向网关负责人要一个当前的构建。
依赖那一行也要看。dpkg -s kerio-control-vpnclient | grep -i depends 会显示软件包期望什么，未满足的版本要求和缺失的运行时库会在这里暴露，而不是在客户端日志里。
用软件包向导配置它
按设计，客户端在应用抽屉里没有条目，所以图标缺失并不能说明配置是否成功。用下面的命令重新打开向导，sudo dpkg-reconfigure kerio-control-vpnclient 然后回答它的提问：VPN 端点、账号信息以及服务器证书的指纹。
把指纹这一问当成错误服务器唯一能取胜的地方。要把取到的值与运行网关的管理员提供的服务器信息比对，而不是与端点自己出示的东西比对。接受一个你无法验证的指纹，会让这份清单剩下的部分变成摆设，因为一旦固定下来，恶意服务器看起来和真的完全一样。如果无法通过其他渠道确认这个值，就停下来问清楚，哪怕隧道本来也能建立。
重新运行向导会改动配置，还可能重启客户端，所以当你正在使用的会话依赖这条 VPN 时，务必留一条进入机器的第二条路。密码要在正常提示处输入，而不是嵌进一条会留在 shell 历史里的命令。
认识向导写出的那个文件
配置就放在 /etc/kerio-kvc.conf，里面既有账号，也有固定下来的指纹。把它当作机密材料。sudo stat -c '%a %U %G' /etc/kerio-kvc.conf 不应该把它显示成所有人可读。
在获得授权的手工修改之后，重新加载拥有该文件的守护进程，而不是重启网络栈：sudo /etc/init.d/kerio-kvc reload。重新加载会重新读配置并断开当前会话，所以对一条活跃连接来说，它不是无操作。
动任何东西之前先备份原文件。如果修改后认证失败，恢复最后一份可用的副本只需几秒，也能把改动与网络隔离开，这是查清两者中究竟哪一个变了的最省事的办法。
把活动会话和开机行为分开
服务脚本控制当前连接：sudo /etc/init.d/kerio-kvc stop 立刻结束隧道，start 把它重新带起来。这两条命令都不决定下次开机时发生什么，而这个区别在你远程管理的机器上很重要。
在移除链接或屏蔽任何东西之前，先查清开机项归谁管。软件包可能安装自己的 init 脚本、生成 unit，或者两者都做；停用错误的名字会让你重启后客户端又回来。把systemctl status kerio-kvc 和软件包文档使用的名字对照一下，然后停用开机流程真正读取的那条路径。
不要因为配置看起来相似就换成 OpenVPN 的 unit。这个客户端用自己的协议和 Kerio 网关通信，所以另一个指向同一文件的守护进程不会通过认证，多出来的这一层失败反而让证据更难读。GFI 的 Linux 客户端同一时间也只保持一条 VPN 连接；这个限制说的是客户端，不是网关的用户容量。
先读日志，再验证资源
三个文件位于 /var/log/kerio-kvc 之下，讲述守护进程的经历：init.log 记录生命周期事件，error.log 记录严重故障，debug.log 记录细节。读能回答你问题的最小片段，并在粘贴到任何地方之前删掉端点和用户名。如果在init.log 里，运行向导前后出现空档，就说明守护进程根本没有重启过。
| File | Read it for | Skip it when |
|---|---|---|
init.log | start, reload and stop events | you already know the daemon restarted |
error.log | failed authentication and certificate problems | the tunnel is up and traffic still fails |
debug.log | protocol detail worth attaching to a ticket | the error is already named in error.log |
有效的软件包、运行中的守护进程和可达的资源是三件独立的结果，三者都成立时清单才算走完。在获批的变更之后，先请求一台只存在于网关背后的主机，再在它上面打开一个普通服务。如果隧道通了而资源不通，剩下的故障在网关路由或防火墙规则里，而不在你刚重新配置的客户端上。
把收尾时的状态记下来：软件包发行版、架构、指纹是否通过其他渠道验证过，以及你执行了哪次重新加载或重启。正是这条记录让下一个人第一次检查变得便宜。