双 LAN 口的 Synology NAS：VPN 握手为什么失败

笔记本电脑报出 TLS 握手失败，听起来像证书问题，通常却不是。在有两个以太网口的 NAS 上，最常见的原因是路由器把转发指向了软件包并未监听的地址，而客户端在这两种情况下给出的报错一模一样。两根网线都插着，并不代表软件包会在第二个网口上应答。在任何人重新签发证书之前，先证明数据包到底有没有到达 NAS。

客户端报了什么，实际又发生了什么

OpenVPN 客户端报出的握手失败是一个笼统说法。它涵盖证书不匹配、传输方式不匹配、监听在别的端口，以及一个什么都没送到的转发规则。正因如此，这条消息作为起点毫无用处，只能当作确认。把它理解为“会话没有建立”，不要赋予更具体的含义。

端口和绑定地址，才是决定数据包能否到达的两个事实。

动手改任何东西之前，先把这两项记下来，因为看似合理的修复一旦用错层次，十五分钟的问题就会变成一整个下午。记下接口、接口上的地址、端口和传输方式。这四个值构成整个入站路径，下一节会说明它们各自在哪里。

找到软件包监听的地址

DSM 会给以太网口编号，每个口各有自己的地址。VPN Server 页面会写明 OpenVPN 服务使用哪个接口，网络面板则显示该接口上配置的地址。按这个顺序、从服务向外读，你描述的才是实际在监听的东西，而不是你以为它应该用的东西。

服务只绑定一个地址。两个口都连着、都处于活动状态，并不会让服务在第二个口上应答。一个接口配静态地址、另一个接口走 DHCP，会得到两个看起来相近的值，扫一眼就很容易弄混，尤其是只有最后一个字节不同的时候。请从面板里复制地址，不要凭记忆输入。然后在 NAS 上确认端口实际绑定到了哪里。

sudo ss -lunp | grep 1194

如果命令输出里出现的地址不是你预期的那个，说明转发指向了错误的接口，后面的一切都只是记账。先改规则再往下读，否则你会为一个根本没离开路由器的数据包去折腾证书。

修好转发，再盯住计数器

改现有那条转发规则，而不是为同一个外部端口再加一条。两条规则可以并存在路由器的表里，但永远只有一条生效，于是排查就变成了争论哪条才算数。把内部地址改成你从 NAS 上读到的值，内部端口则与服务的监听端口保持一致。

如果 DSM 通过 DHCP 拿到这个地址，先做地址保留。租约一变，昨天还正常的转发会无声地坏掉。

sudo tcpdump -i any -n udp port 1194

在客户端尝试连接之前就开始抓包，出现什么就看什么里的源地址。什么都没有，说明路上有东西把它丢了：转发、DSM 防火墙，或者它指向的那个接口；在这一点成立时，证书不可能是原因。有东西从客户端公网地址过来却没有回应，说明 NAS 收到了请求并选择不回答。这是两种不同的结论，只有第二种才把你送回软件包自身的设置。

到这一步才去看证书和传输方式

数据包能到达之后，每次改动证书都重新导出一次配置文件，因为旧文件仍然带着创建它时的那个签发机构。为另一种传输方式手工改过的配置，会让客户端一直等一个并不存在的监听者，报出来的还是同一条笼统失败。把配置里的传输方式与软件包实际提供的方式对照一下。两套配置对应两种传输方式是合理设计，而改一套配置去兼顾两者不是。

最后一步，从你自己的网络之外测试，因为从内网连上去可能走的是一条根本不经过转发的路径。

把导出的配置、接口地址和转发规则放在同一条记录里。地址一变，这条记录就是“修好了”和“又来一次”的区别。这条路径上没有任何一步需要重装软件包，在把下一次重启当成罪魁祸首之前，这一点值得记住。