vpnc 为何在 24 分钟时断线，以及该改什么

你的隧道在固定间隔反复断开，这是一个自我报告的定时器，而不是坏掉的网线。二十四分钟等于 1440 秒，正是配置文件或头端策略会携带的整数。随后同一套配置每次都在同一台集中器上失败，而其他网络全部正常，再怎么测链路也改变不了。

三个条件决定你的定时器是哪一个：客户端是否放弃空闲会话、密钥更新交换是否被拒绝，以及翻译网关是否改写了封装。

哪个定时器导致掉线

在改动设置之前，至少测三次重连的间隔。间隔差几秒说明是链路丢包或无线漫游；每次都落在同一刻度前后几秒，则说明是某个策略值。会话时长还能说明是谁结束的，因为客户端超时和服务端删除会在调试输出里留下不同的最后一行。三次重连还能看出间隔是否会漂移，而单次测量看不出来。

把数字记在你所对话的头端旁边。一旦间隔稳定，剩下的工作就是在三个原因中做选择，而每次重连只改一个设置，才能让它们保持可区分。

情形一：客户端放弃空闲会话

vpnc 会运行自己的死对端检测，而这个检测可能杀掉集中器仍认为存活的会话，尤其是两者之间还有翻译网关时。文档给出的客户端做法是在本地关掉定时器，让头端决定对端何时消失。下面两行都属于 vpnc 配置文件或命令行，而且都与加密设置无关。

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

禁用客户端 DPD 能去掉误报，同时也去掉了你唯一的本地检测手段，所以应当单独应用，并观察间隔是否有任何变化。

情形二：密钥更新被拒绝

如果间隔在改动 DPD 后依旧，阶段 1 密钥更新就成了候选。旧版 vpnc 处理密钥更新不如现在谨慎，常见的分歧是 Diffie-Hellman 组。强制使用头端本来就接受的组只花一行配置和一次重连，因此这是廉价实验，而不是策略变更。

IKE DH Group dh5

有效的组名是 dh1、dh2 和 dh5。集中器拒绝的组会立即失败，这同样是信息：它说明头端很挑剔，原来的组多半是对的。

情形三：翻译改写了封装

在翻译网关后面，Cisco 的 UDP 封装与基于标准的模式不能互换。选错时，隧道常常能建立、能传流量，随后在负载下超时，看起来像带宽问题，其实不是。只改模式，然后重连并重新计时掉线。只有在前两种情形都排除后，才尝试另一种模式。

前端还会添一层混乱。NetworkManager 在插件包安装之前不会提供 vpnc 连接类型，缺少插件时表现为灰色的“添加”按钮，而不是报错。KDE 的前端把同样的值放在自己的配置文件里，所以要确认守护进程读的是你改过的那份。

从命令行能连、从桌面却连不上的配置文件，是前端问题，不是定时器问题。

在第三次改动前核实失败的交换

带调试输出运行客户端，读取掉线前的最后一次交换。断开前紧接着出现阶段 1 删除，说明客户端做了密钥更新并被拒绝。同一位置出现阶段 2 删除，说明隧道是被对端拆掉的，你的客户端设置并不是原因。

vpnc --debug 3 office

隧道还在但流量停止时，也要检查第二个网络守护进程。两个管理器同时写路由表，会产生同样的症状和完全不同的日志。