DD-WRT 上的 OpenVPN 2.5 监听器死了？先读它生成的配置

DD-WRT 上的监听器“死了”，通常意味着守护进程在解析配置时就退出了，而不是防火墙规则挡住了端口。OpenVPN 2.5 收紧了若干旧配置所依赖的默认值，原本在旧版本上能用的生成配置，可能在套接字打开之前就被拒绝。原因在路由器自己的日志里，输入在生成文件里。按这个顺序读两者，比任何抓包都快。

守护进程不是防火墙

这个区分很重要，因为从外面看两种故障一模一样：客户端发出握手，什么也没回来。一种是进程没在跑，另一种是进程在跑并在过滤。

在改动任何东西之前，用两项检查把两者分开，因为对一个已经死掉的进程改防火墙，只会多出第二个变量。

读 DD-WRT 生成的那份配置

DD-WRT 不会把你填在网页界面里的文字直接交给 OpenVPN。它把生成的配置写到 /tmp/openvpn/openvpn.conf，再用这个文件启动守护进程，所以界面字段和 Additional Config 里的任何文字，在 OpenVPN 看到之前就已经合并了。如果你调试的是表单而不是生成文件，你读的是意图，不是实际输入。在重启清掉 /tmp 之前，先把该文件复制到持久位置。

把生成文件和你原本的意图对比，尤其是界面写入了你从未选择的指令的地方。一个下拉项悄悄带出过时选项，在表单里看不见，对守护进程却是致命的。

如果生成文件是空的或不存在，守护进程根本没走到启动那一步，问题在 OpenVPN 上游。

OpenVPN 2.5 不再接受什么

OpenVPN 2.5 用 ncp-ciphers 取代了 data-ciphers，并把默认的最低 TLS 版本提高到 1.2。它还改变了压缩处理：提供压缩的对端会被拒绝，除非配置明确允许；同时把 ns-cert-type 之类的旧选项名标记为过时，改用 remote-cert-tls。这些变化中的每一项，都会把原本能用的配置变成解析或协商失败。

失败方式取决于指令。未知或已移除的选项会让守护进程在启动时停下，这就是你的“死监听器”。协商不匹配则让守护进程继续运行却拒绝客户端，从客户端看就像防火墙问题。

读日志里的第一个错误，而不是最后一个。解析在第一条坏指令处就停止，之后的内容都是关闭过程的噪声。

Broadcom 特有的前提条件

在 Broadcom 版本上，隧道设备必须存在，守护进程才能使用。确认 tun 模块已加载、/dev/net/tun 存在，因为设备缺失造成的启动失败与证书毫无关系。DD-WRT 为路由和 DNS 生成的辅助脚本也一样：如果缺失或不可执行，守护进程能启动，却仍然完不成设置。

需要真实报错时，针对生成配置以前台方式、更高详细度运行守护进程。前台运行会打印出 init 脚本吞掉的那条解析错误。

之后要恢复正常服务，因为前台守护进程会和 init 脚本抢端口。

在调试客户端之前，先证明监听器存在

分别确认进程和套接字：一条命令看运行中的守护进程，另一条看预期地址上已绑定的 UDP 端口。有进程没套接字，说明它还在设置中或绑错了接口。这一对之所以有用，正是因为缺了另一半，任何一半都不成立。

只有监听器存在之后，客户端侧的调试才有意义。那时再确认客户端的加密与 TLS 设置与服务器的 data-ciphers 列表和最低版本一致，并确认端口确实转发到了路由器。

把生成配置和证明修复的那行日志留下来。下一次固件升级可能再次改变默认值，而正是这份记录，让问题复发变成五分钟的检查。