SoftEther 服务器可以同时在原生 SSL 端口和兼容 OpenVPN 的端口上应答,于是两者看起来像同一个服务开了两扇门。它们其实是两个服务,客户端不同、配置格式不同、能力也不同。把原生配置文件塞进 OpenVPN 客户端会在解析阶段失败,而错误信息很少说明原因。

先选监听端口,再选客户端。

两个监听端口,两种配置格式

原生协议使用 SoftEther 客户端和一份写明服务器、端口、虚拟 Hub 与用户的连接定义。兼容 OpenVPN 的监听端期待的是带 remote 指令、TLS 材料以及若干选项的 OpenVPN 配置文件,这些选项来自一个比独立 OpenVPN 服务器小得多的受支持集合。SoftEther 称之为 OpenVPN 克隆功能,而“克隆”二字恰好提示了它的保真程度。

兼容性是版本问题。要查的是所部署的构建接受什么,而不是当前 OpenVPN 手册怎么记载。

第 1 步:弄清楚运维方启用了哪个监听端口

直接索要监听端口清单,别从端口号去猜。在 443 上应答 TLS 的服务器未必是 OpenVPN 端点,因为原生协议也可能用同一个端口。手册里关于兼容服务器功能的章节会说明存在哪些克隆、如何启用。

如果你能接触到主机,就测试给你的端口,而不是教程里的端口:openssl s_client -connect vpn.example.com:443 -brief至少能告诉你那里有没有 TLS。

第 2 步:使用匹配的客户端和配置文件

原生接入需要安装 SoftEther 客户端,用运维方提供的信息建立连接并挂上虚拟网卡。兼容监听端则要导入运维方从服务器导出的 OpenVPN 配置文件,因为其中带着该监听端所期待的 CA 与客户端材料。不要照着通用示例手工拼配置文件,也不要把原生连接定义粘进 OpenVPN 配置里。

导入时的解析错误是格式问题,不是网络问题,不该把你引向防火墙。

第 3 步:让比较保持公平

如果运维方同时公布两条路,比较时要让设备、接入网络和任务保持不变。两条路径可能在认证方式、所接入的子网以及服务器此后如何处理你的流量上都不相同。共用一台主机不等于共用一套策略。任务也要保持不变,因为复制文件和视频通话压的是同一条路径的不同部位。

不要采用导入失败时冒出来的那些偏方。关掉证书校验或用旧密码套件硬把配置文件塞过去是倒退,不是兼容功能。

第 4 步:连上之后验证路径

连上以后,检查拿到的地址、随之而来的路由、DNS 以及一个内部资源。原生一侧要查看的是虚拟网卡;OpenVPN 一侧则是客户端创建的 tun 或 tap 设备。无论哪边,问题都在于你选的监听端是否给出了你需要的访问权限,这与隧道是否建立是两回事。把前后的地址记下来做对比。

记下是哪个监听端口、哪个客户端版本跑出了可用结果。否则下一个人还得从端口号开始重新摸索。

相关文章