一台 Azure VM 需要隧道：客户机客户端还是 VPN 网关？

一台 Azure VM 里的一个工作负载必须通过隧道访问专用网络。决定设计的问题不是哪个 VPN 产品更好，而是是否会有其他机器也需要这条路径。先回答这个问题，其余架构通常会自行确定。判断错了，你会继承一台悄悄变成路由器却没人记录的 VM。

两个看起来相似的任务

一台 VM 既可以是端点，也可以是中转点；区别不在于你安装的软件，而在于谁在使用这条隧道。作为端点时，客户机为自身的进程运行客户端；作为中转点时，它转发其他工作负载的数据包，从而成为网络拓扑的一部分。

大多数针对单台 VM 的需求，其实是第一个任务套用了第二个任务的说法。有人说「这台 VM 就是我们的 VPN」，实际意思却是上面某个应用需要访问另一侧的数据库。

条件一：还有别的东西需要远端吗？

如果答案是否，就把客户端装在客户机里，别再继续设计。这个选择不需要托管网关，也不会让这台 VM 成为邻居的网关。你只是在一个操作系统内部加了一条路由。

如果答案是是，或者一年内很可能是，那就现在把它当作网络设计来做。其他 VM 只有在子网路由表把它们发往那里、并且网卡接受转发的流量时，才能到达中转 VM，所以要做的是 路由表和转发权限，而不是再装一个客户端。

条件二：你能保住管理通道吗？

安装宽泛路由的 VPN 客户端可能抢占你用来管理 VM 的路径。如果隧道的目标列表与管理网络重叠，客户端一连接，你的 SSH 或 RDP 会话就会中断，只能通过串行控制台或重建来修复。

连接前后都要检查。在 Linux 上，ip route get <management-ip> 会显示内核此刻会使用哪个接口和源地址；拿它与隧道开启时的结果对比。带有明确目标列表的分流隧道比默认路由更容易说明，而且通常正是工作负载真正需要的。

条件三：半夜谁来打补丁？

客户机客户端意味着你的操作系统、你的客户端版本和你的证书。如果你本来就在运维这台 VM 及其补丁周期，这没问题。如果这台 VM 只是为了维持隧道而存在，那就是笔糟糕的交易。在说客户机客户端更便宜之前，先数一数打补丁的工时。需要重启的客户端升级，就是为一台只为保持隧道畅通而存在的机器排定的停机。

托管网关把这项维护移交给平台。身份、授权以及它背后的网络路径仍由你负责，但你不必为了应用客户端更新而重启机器。

托管网关不做什么

Azure VPN Gateway 是一项 VNet 连接服务，有自己的站点到站点和点到站点方案。它不是禁止客户机安装 VPN 软件的规则，也不是单个应用所需客户端的直接替代品。

它提供的是网络层连接，许多工作负载可以通过路由到达。它不提供的是只有一台 VM 上的一个进程使用、并限定在该进程身份范围内的隧道。这种限定不是需要道歉的缺陷，而正是客户机客户端设计的要点。一个应用、一条路由、一套凭据，对同一子网里的其他 VM 毫无影响。

所以比较不是托管对软件，而是网络范围连接对进程范围连接；当只有一个进程需要时，后者完全正当。

在需要之前先规划成长路径

如果需求从一台 VM 扩展到一个子网，就重新设计方案，而不是放宽客户端允许的前缀。把一个方便的会话当作未记录的路由器复用，会让每个使用方都绑在这台 VM 的生命周期、凭据和补丁窗口上。

一旦连接属于网络范围而不是工作负载范围，正确的起点就是 Azure VPN Gateway 概述。

选择之前，先写下三行：谁需要远端、谁管理这台 VM、谁给隧道打补丁。如果三个答案都指向一个工作负载，客户机客户端就是诚实的方案。只要有一个指向子网，就现在设计网络层。