Netgear OpenVPN：TUN 与 TAP 监听不同端口

一部手机毫无怨言地连上了路由器的 VPN，而用同一个下载页面里的配置文件的笔记本电脑却超时了。这两次尝试之间证书方面没有任何变化，因为笔记本根本没走到证书起作用的阶段。路由器为 TUN 和 TAP 分别发布监听器，能用的配置文件必须选对属于自己设备类型的那一个。

判断该追这三条候选故障中的哪一条，就是这里的全部工作：端口、设备类型，还是数据通道的加密协商。

必须一致的三件事

设备类型、配置文件的接口行和监听端口构成一个选择，而不是三个。声明 dev tun 却指向 TAP 监听器的配置文件无法完成会话，反过来也一样失败。就你手上的型号和固件而言，端口要从路由器自己的 VPN 页面读，而不是照抄指南，因为不同版本之间数字会变。把型号和固件版本写在那个数字旁边，下一个人才能核对。

现场报告提到过某个固件上 TUN 是 12973、TAP 是 12974 这样一对，另一个固件上又是别的数字。要把这当成版本各不相同的证据，而不是可以照抄的常数。接着配置文件需要与距离相称的主机名：用路由器的动态 DNS 名，而不是会变的 WAN 地址。

把端口和接口行改对之后，配置文件看起来就是一份普通的客户端配置，只有一行 remote 和一行 dev。两者对不上时，重试多少次也建立不了会话。

按日志打印的顺序读

OpenVPN 客户端按事件发生的顺序报告，所以沉默之前的最后一行就指明了该检查的层。当运行停在 TLS Error: TLS key negotiation failed，或者只是等第一个响应然后放弃，说明证书比对根本没发生。这指向可达性、监听器，或者一个后面什么都没有的端口。这些都不是换掉 CA 文件能修的。

能走到 VERIFY OK 再失败的运行，问题完全在别处，原因也另有一套。在动文件之前先把这两种结果分开，可以避免那个经典的绕路：去翻根本没被查询过的证书包。握手完成却起不来隧道时，要看加密协商，而不是可达性。

补上现代客户端期望的加密列表

较新的 OpenVPN 客户端会拒绝家用固件仍在提供的旧默认值，症状就是握手成功后立刻协商失败。修法是配置文件里的一行，写明客户端接受什么：把 data-ciphers 按这个顺序设为 AES-256-GCM、AES-128-GCM、CHACHA20-POLY1305 和 AES-128-CBC。路由器没实现的算法本来就不会被选中，所以列表长一点只多花一点点协商时间。

列加密算法并不能让路由器多出它没有的算法。如果协商还是失败，就检查路由器页面上有没有自己的加密设置，以及那个设置里是否至少有一项客户端接受。两份毫无交集的列表造成的失败与端口写错完全相同，所以两端都值得看一眼。

导入一次，而不是手工改一堆副本

把改好的文件导入 NetworkManager，就能避免一个装满略有差异的配置文件的文件夹：nmcli connection import type openvpn file client.ovpn，然后按名字把它起起来。把导入后的配置文件当作你唯一编辑的那一份，重复下载堆积出来的副本要删掉。

然后从 LAN 外面测试。在同一个网络里连上几乎证明不了什么，因为流量可能根本不走隧道。要确认请求确实从路由器出去了，而不只是客户端显示已连接。

决定怎么处理警告

家用固件通常会自签自己的证书颁发机构，客户端对验证的抱怨方式又是固件压不下去的。与其把每条警告都当成致命问题，不如判断这条抱怨对你保护的东西是否重要；也不要为了消掉一条消息就全局关掉验证。经过评估的警告是有记录的风险，被你关掉的验证设置则是没有记录的。

当固件没有提供受支持的办法去修正一条确实要紧的警告时，这个缺口本身就说明该把 VPN 放到别处。在修配置文件、接受警告和迁移端点之间做选择，是关于你有多信任那张证书的决定。要有意识地做，并写下你选了哪一种，而不是一路点对话框直到图标变绿。