Synology 上 OpenVPN 握手失败？检查 LAN 转发

笔记本电脑报告 TLS 握手失败，于是人很想重建证书。先问一个更无聊的问题：Synology 实际在哪个 Ethernet 端口上监听？双 LAN 端口的 NAS 有两个地址，DSM 的 VPN Server 套件只把 OpenVPN 监听器绑定在其中一个上。当路由器把 1194 转发到另一个地址时，没有任何数据包能到达服务，客户端也就无从协商。

错误文本会误导人，因为它描述的是客户端最后尝试的动作，而不是最先出问题的地方。花两分钟对比套件页面和路由器规则就能定案。

找到监听器绑定的地址

DSM 把端口称为 LAN 1 和 LAN 2，每个端口各有一个地址和子网。打开 VPN Server，读取 OpenVPN 选项卡上写明的网卡，再打开控制面板，记下 DSM 在同一网卡上的 IPv4 地址。转发要写的是这两个值，而不是 NAS 的主机名。

再插一根网线并不会多出一个监听器。两条链路都可能显示已连接，但只有一个地址接受流量；当两个网卡位于同一子网时，两个地址只差一位数字，而保存规则前没有人会再核对一遍。

通过 SSH 看 socket 本身，因为只有这里能看出守护进程真正绑定了什么，而不是设置页面想表达什么。

sudo netstat -anp | grep 1194

修改现有转发，而不是再加一条

一个外部端口有两条规则，路由器就可以随意选择，而它选哪一条可能在固件更新或重启后改变。打开已有的规则，改掉内部地址，保存，再打开读回这个值。给规则按服务命名会有帮助，因为五条一模一样的转发正是错误规则得以存活的原因。

external 1194/udp  ->  192.0.2.20:1194/udp

让内部端口等于监听端口，并保持协议一致。UDP 1194 是默认监听器，而 TCP 配置文件需要套件侧有自己的监听器和路由器上对应的转发。把 TCP 转发给只监听 UDP 的服务，得到的是沉默，而不是错误。

如果 NAS 地址来自 DHCP，要在保存规则前把它预留。租约到期会重新分配地址，转发仍指向旧值，于是会在没人动过 NAS 的那天开始握手失败。NAS 侧改用静态配置也能解决同样的问题，前提是该地址在路由器的 DHCP 范围之外。

证明数据包到底有没有到达

先在 NAS 上开始抓包，再从客户端连接，然后读取输出中的源地址。失败之后才开始抓包，什么都看不到，也什么都证明不了。

sudo tcpdump -i any -n udp port 1194

沉默意味着流量在到达服务之前就死了：内部地址错误、DSM 防火墙关闭了端口，或者网卡被管理员关闭。输出中有数据包说明转发是通的，剩下的故障在网络层之上，搜索范围要小得多。

抓包还会写出数据包从哪个网卡进来，正是这一细节把指向错误端口的规则和指向未启用端口的规则区分开。同一次尝试中，如果路由器自己显示计数器，也一并观察。抓包一直为空而计数器不动，指向路由器；抓包为空而计数器在动，指向两台设备之间的路径。

数据包到达后，别再怪转发

下一个嫌疑对象是配置文件，常见原因是太旧。导出的 .ovpn 文件包含导出那一刻的权威与材料，所以后来换过证书的套件会拒绝仍带着旧副本的客户端。

传输方式是另一个值得明确检查的不一致，因为配置文件和套件在不同地方修改。把配置文件从 UDP 改成 TCP 却不切换套件，客户端就会等待一个并不存在的监听器，而它给出的仍是那句对什么都适用的通用握手提示。读文件里的 proto 行，再看服务器页面上选中的协议，然后才能断定两者一致。读 DSM 防火墙规则是第三项检查：允许本地子网访问端口、却不允许互联网访问的规则，很容易在测试后遗留，它会造出一条在厨房能用、在别处全都失败的连接。

测试远程用户真正走的路径

同一 LAN 内的客户端不经过转发也能连到 NAS，所以它证明不了任何与远程访问有关的事。用一台关掉 Wi-Fi 的手机，或者请网络外的人试试，并在那次尝试中观察路由器计数器。如果远程尝试失败而本地成功，转发或防火墙就仍在画面里。

在还能用的时候记录可用状态：外部端口、内部地址、协议、套件网卡，以及配置文件名称和导出日期。等握手再次失败，这份记录与当前配置的差异就是故障所在，谁都不用重新发现服务用的是两个端口中的哪一个。