SoftEther VPN Azure：一条中继路径，而不是开放端口

你的服务器位于一台你无法配置的路由器之后，因此显而易见的端口转发方案并不可行。VPN Azure 正是为这种情况而存在，它通过反转首个连接的方向来解决问题：服务器主动向外拨号连接到中继，客户端则连接中继而不是服务器。理解这种反转，就能同时明白该服务解决了什么，以及你日后会遇到的每一项限制。

路径上发生了什么变化

使用传统监听器时，客户端向一个公网地址发起 TCP 连接，由你的路由器转发到服务器。使用中继时，服务器维护一条指向中继基础设施的出站连接，中继接受客户端的连接并把负载转交给等待中的服务器。不开放任何入站端口，不需要静态地址，路由器也保持原样。从防火墙的角度看，服务器只是一个普通的出站客户端，这正是受限网络允许它的原因。

中继为该服务器分配一个位于其自有域名下的名称，客户端被配置为连接那里。

该名称属于中继服务，而不是 Microsoft Azure VPN Gateway，尽管两者都叫 Azure 什么。把二者混为一谈，会得到一份根本无法工作的配置。

哪些协议能通过中继

中继传输的是 SoftEther 协议，项目文档把 SSTP 列为客户端选项，这很有用，因为 Windows 自带 SSTP 客户端。但它不会成为主机上每个监听器的通用载体：一个 OpenVPN 监听器、一个 IPsec 响应端和一个 L2TP 服务各自需要可达的端点，不会仅仅因为 SoftEther 服务器已连接就都能经由中继传输。

因此客户端配置指向中继名称而非服务器地址，为直连而建的现有配置无法原样使用。在设计依赖某个协议之前，请查看你所运行版本支持的客户端列表，确认中继是否承载该协议。

中继不会替你做的事

中继只是传输通道。它不创建用户、虚拟集线器、访问策略或路由，也不了解你服务器背后的私有网络。如果远程客户端必须访问某个 LAN 子网，服务器仍然需要桥接或路由配置、回程路径以及让这一切生效的防火墙策略。两端地址规划重叠的问题对中继同样不可见，仍然需要你自己解决。

受支持的安全设置同样由你决定。项目文档中包含较旧平台的示例，而从旧截图里照搬过时的加密或证书设置，很容易造出一条无人能审计的隧道。请使用你所运行版本的当前指引。

证书校验和用户认证仍由服务器负责，中继永远不能替代其中任何一项。

把它当作一项依赖来运营

可用性现在牵涉到第三方。当中继不可达时，无论你的服务器多么健康，客户端都无法连接，而从外部看，故障像是客户端的问题。请把中继路径与服务器自身健康分开监控，并保留一份有记录的兜底方案，例如在另一个地址上的直连监听器，以备真正需要的那一天。

延迟取决于中继的地理位置，而不是用户与你的距离，因此在承诺基于它的交互式性能之前，值得先做测量。

先验证服务器身份，再验证一条真实的应用路径，而不只是一个连接成功的横幅；同时检查你需要的资源是否能通过中继所承载的地址族访问。记录中继名称、所用协议和兜底方案，因为这三点能回答今后关于这条链路的大多数问题。