NAT 后的 SoftEther：直接穿透还是 VPN Azure 中继？

动态 DNS、NAT 穿透与 VPN Azure 各司其职。先选定线路再修改用户，然后确认会话实际使用的传输方式。

你的 SoftEther 服务器位于无法改动的运营商路由器之后，客户端却仍能连接，于是你假设是中继承载了一切。是否如此取决于究竟是哪种机制起了作用：DNS 名称、协同打通的 UDP 路径，还是通往中继的出站隧道。三者都能让客户端显示已连接，但失败条件各不相同。在改动用户或 HUB 之前，先确定你要买的是哪条路。

三种机制，三种不同的承诺

动态 DNS 解决的是命名。它让主机名始终指向会变化的地址，人们不必再追着数字跑，除此之外什么也不做。原生 NAT 穿透是协同：两个 SoftEther 端点交换信息，尝试在中间的地址转换设备上打出一条可用的 UDP 路径。VPN Azure 是中继：服务器主动连向服务，客户端通过中继基础设施上的主机名到达。

三者是互补关系，而不是同一功能的几个版本。部署可以使用命名，而实际连接依赖穿透或中继。

从客户端和网络来决定

选择从客户端开始，因为穿透只存在于 SoftEther 原生连接机制中。同一服务器上的 OpenVPN、L2TP/IPsec 和 SSTP 监听并不继承它，尽管它们共用一台主机。先看用户会运行什么，再看网络允许什么。只放行 TCP 443 的企业网络会把你推向该端口上的中继，而放行穿透所需 UDP 端口的网络可以尝试直连；两者都要对照真实的出站策略确认。

当管理员能够发布监听时，手动可达的监听仍是合理设计，但那是另一个项目，需要单独的地址规划和防火墙工作。

确认会话最终选择了哪种传输

连接状态是判断实际路径的唯一可靠来源。在服务器上读取它，并解析客户端拿到的主机名。

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList 显示哪些会话已连接，对其中一个执行 SessionGet 会报告连接类型，包括会话是否经中继到达。解析到中继基础设施的记录说明会话经过第三方，你可以在测试中封禁该路径来确认。使用原生客户端时，UDP 加速可能让数据路径与控制路径分离，因此一次观测不足以描述整个会话。地址变更后过期的动态 DNS 名称，以及后端路径缺失却仍作应答的中继，是两种值得分别测试的故障模式。记录你实测到的结果，而不是设计本来的意图。

为所选路径的依赖项做规划

每条路径都带有依赖。直连穿透可能在网络切换或新增转换设备后改变，而中继会话会在服务或其可达端口失效时失败。换一个网络重连，确认客户端校验过的服务器身份，并把之前可用的路径留在同一测试中。然后测试 VPN 之后的私有资源，因为授权、HUB 成员关系、地址分配和回程路由无论如何都由你负责。

写下主机名、协议、功能设置和观测到的传输。正是这份四段记录让下一个人能够复现可用的连接。

相关文章