Azure 点对站点已连接，但私有资源无响应

已连接是隧道的状态，不是关于可达性的结论。点对站点客户端可以完成 IKE、拿到地址，却仍然什么都访问不到，因为网关只转发 VNet 已知网段的流量。按顺序做完这五项检查，在第一次失败处停下。跳过步骤，正是 DNS 问题被当成防火墙问题折腾一小时的原因。

顺序比清单更重要。

检查 1：先确定隧道该承载什么

Azure VPN Gateway 终止隧道并转发属于 VNet 的流量；它不是通用的互联网出口。如果用户指望浏览流量从 Azure 出去，那么在涉及任何客户端设置之前，设计就已经错了。启用拆分隧道，让本地互联网继续走本地路径；确实需要固定出口地址时，使用 NAT 实例或站点到站点隧道。

在测试任何东西之前，先写清客户端应当能到达什么。没有这份清单，每个部分结果看起来都像进展。

检查 2：先比较地址空间，再谈证书

重叠是按更大的范围判断的，所以两个在子网层面看似不同的网络，只要父级地址块重叠就仍然冲突。网关子网必须专用，并且大到足以支撑所选 SKU；客户端地址池不得与 VNet 或对等互连可达的任何地址冲突。改方案并重新部署，因为靠加路由来补偿，只会得到一个对部分目标可用、对另一些目标莫名其妙不可用的隧道。这里的预配会大声失败，而那属于好情况。

身份验证是下一道门。证书、RADIUS 和 Entra ID 配置文件不能互换，每种方式的客户端包也不一样。

检查 3：从内部解析私有名称

除非下载的配置文件带上 VNet 的 DNS 服务器，否则客户端会保留自己的解析器；而那份列表是在下载时嵌入的。在 VNet 内添加转发器，把它设为 VNet 的 DNS 服务器，然后重新下载并导入客户端包。沿用旧包，测的只是旧的解析器列表。

先测地址，因为这一步能把路由和名称解析分开：Test-NetConnection 10.20.1.4 -Port 3389。

如果地址通、名称不通，直接用 Resolve-DnsName files.corp.example -Server 10.20.0.4 询问解析器。如果两者都不通，问题就不在 DNS，你应该停止修改 DNS 设置。168.63.129.16 上的 Azure 平台 DNS 只从 VNet 内部应答，所以外面的客户端不能把该地址当作解析器。

检查 4：测试隧道后面的服务

健康的隧道和关闭的端口，从客户端看完全一样。先查客户机防火墙，再查子网或网卡上的网络安全组，然后看服务是否监听私有地址而不是只监听回环。把客户端地址池作为来源放行，而不是向互联网开放规则；还要记住，访问 Azure Files 的 SMB 需要让私有终结点路径走隧道。当资源能按 IP 访问却不能按名称访问时，回到检查 3，别去动网关。

工作时用一张表把层次分开：

检查 5：升级之前先记录配置文件

把网关类型、隧道类型、身份验证方式和客户端操作系统写进工单。证书型 IKEv2 配置文件和 RADIUS 配置文件失败的原因不同；为另一种隧道类型构建的客户端，只有在网关提供兼容协议时才能连上。

对小团队来说，耐久的设计是一个 VNet、一个 DNS 转发器，以及有文档的拆分隧道客户端。如果需求是固定的公网出口，就在你控制的防火墙上终止站点到站点隧道，把互联网流量导到那里，而不是让点对站点网关去做它从未被设计来做的事。