SoftEther 连接配置文件：导入前核对六个字段

配置文件导入成功，随后认证失败，因为文件指向的 Virtual Hub 并非该账号加入过的那个。文件本身没有任何损坏，它描述的是一种凭证并未获发的配置。六个字段决定导入能否成功：主机名、端口、协议、Virtual Hub、用户身份，以及是否有人误把管理员凭证交给了你。检查一至三依次覆盖这些字段，最后两项覆盖文件本身与你实际加入的对象。

检查 1：主机名与端口

在导入任何东西之前，先读主机名、端口和声明的接入方式。原生 SoftEther 监听器通常应答 TCP 443，而 992 和 5555 是运营者为受限网络后的客户端开放的备选端口。指向网站或其他服务的端口的配置文件，会在认证之前就失败，并把失败报告成凭证错误。要把这组信息与该运营者针对此端点公布的内容作比较，而不是与去年某人抓取的目录清单比较。如果主机名解析到运营者从未提及的地址，就此停下，因为下一步会把凭证发往该地址。

443 端口是共享地带，因此仅凭端口并不能证明后面的服务是什么。SoftEther 客户端靠协议握手区分两者，所以配置文件可能指向正确的端口，最终却连到一台 Web 服务器。这种失败在客户端日志里看起来像密码错误，尽管从未校验过任何密码。

把端点按主机名、端口、方式三项记录下来，顺序如此。这三项是你在不连接的情况下就能核实的部分，也是你向运营者询问监听器是否仍在运行时要引用的部分。凡是无法从公开来源补齐的，都保持未核实，而不是当作已知。

检查 2：协议决定客户端

提供多种接入方式的服务器，不会把一个导出文件变成所有客户端都能打开的配置文件。 Each method has its own format, its own client and its own failure mode，把两者混用会产生看起来像凭证问题的错误。在决定由哪个客户端打开之前，先确定文件声明的是哪种方式。

下表列出常规端口以及每种方式实际需要什么。端口由运营者选择，因此应把它们当作默认值，而不是关于某台服务器的事实。原生 SoftEther 配置文件由 SoftEther 客户端导入，ovpn 包属于 OpenVPN，而 SSTP 或 L2TP 配置文件由操作系统本身处理。为了打开第一个客户端拒绝的文件而安装第二个客户端，通常会把清晰的错误变成令人困惑的错误。

要看文件内部的声明，而不是扩展名。以 OpenVPN 命名的文件按定义就是 OpenVPN 配置文件，而 SoftEther 配置文件是 SoftEther 客户端导入的一份小型配置，两者不能互换。如果声明的方式你无法提供，这就回答了导入的问题。

检查 3：Virtual Hub、用户与管理角色

对于原生接入，配置文件会指明一个 Virtual Hub 及其中的用户。 A hub is a logical VPN server instance with its own users and its own settings，而用户是该 Hub 的成员，拥有自己的认证。这两者都不是服务器管理，服务器管理控制监听器、各个 Hub 以及部署中的每个用户。客户端配置文件绝不应该带着这种管理权限到来。当有人为了让客户端工作而把管理员凭证发给你时，这种安排就是错的，无论它能否连上。

记录连接时要把这三者分开，因为它们的吊销方式不同。移除一个 Hub 用户会终止某个人的访问，而部署的其余部分不受影响；而轮换管理员凭证会触及所有东西。这一区别也是反对给团队共用一个 Hub 用户的理由，因为单一凭证意味着对所有人只有一次吊销事件。

检查 4：文件与它承载的内容同样敏感

视格式而定，配置文件可能携带已保存的密码、证书或预共享密钥。只要导出文件存在，就把它当作机密，因为你附在工单上的副本，是别人也能导入的副本。分享前先去掉凭证，或者分享一份带新密钥重新生成的配置文件。文件的敏感性来自其内容，而不是扩展名或大小。

通过运营者公布的渠道确认端点，并把目录标签视为未核实。公共节点列表里的国旗和主机名由提交条目的人选定，因此两者都不能确定谁在运营服务器。如果配置文件来自公共目录，那是需要更多核查的理由，而不是更少。

记录文件从何而来、你何时收到。当连接之后表现不同时，来源是你首先要与已核实的端点作比较的东西。没有来源的配置文件，是你无法审计的配置文件。

归档你核实过的那份副本，而不是后来找到的那份。两个同名但端点不同的文件，正是能用的导入变成支持工单的方式。把已核实的副本放在关于其来源的备注旁边。

检查 5：测试应用，而不是状态灯

导入之后，要测试你真正需要的应用，而不是连接指示灯。认证成功只能证明凭证可用，不能证明你预期的路由或 DNS 随会话一起到位。连上，然后使用这个配置文件本应到达的服务。

检查分配的路由和 DNS 服务器，并记下在采用分流设计时哪些目标绕过了隧道。然后用一个本应被排除的目标重测，因为把所有流量都送进隧道的分流失效配置，照样能通过单目标测试。如果某个私有资源失败，先怀疑路由，再怀疑凭证。把四项结果写下来：已认证、服务可达、路由符合预期、被排除的目标确实被排除。

把四项结果与该运营者对此 Hub 的承诺作比较。会话通过认证，而被排除的目标同样可达，说明分流并未生效，配置文件不是问题。修正预期或 Hub 策略，然后按同样顺序重跑这四项检查。