Azure P2S VPN 无法解析专用终结点名称

按顺序逐项检查：DNS 返回哪个地址、区域链接、可达的解析器、证书中的主机名，以及临时的 hosts 条目。

你连接点到站点隧道，ping 专用地址，打开应用，结果拿到 403 或证书错误。两种症状都指向 DNS，但它们是不同的故障：一种表示客户端解析到了公共地址，另一种表示它解析到了专用地址，随后却提供了一个证书未覆盖的名称。请按下面的顺序逐项检查，并在第一个失败处停下，因为一条 hosts 条目或缓存中的应答会让后面每一项检查都以错误的理由通过。我把这个顺序记在 VPN 配置文件旁边的一个文本文件里，因为修复不改变隧道本身，却会改变客户端所知道的一切。

从客户端实际拿到的地址开始

直接问解析器，不要相信应用。在 Windows 上，nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net 会显示客户端拿到的是哪个视图。公共应答意味着下游没有任何东西能到达终结点；终结点专用地址意味着 DNS 已经完成，下一项检查就是连接本身。

专用终结点不会更改服务名。账户或应用保留其惯常的完全限定名称，终结点只改变该名称在虚拟网络内部客户端处解析到的地址。这就是为什么同一个主机名在网内 VM 上解析为专用地址，而在从未获得专用视图的笔记本上解析为公共地址。

在隧道之前检查区域、链接和记录

三个条件必须同时成立：专用区域存在，它链接到 VPN 网关和客户端进入 Azure 所用的虚拟网络，并且它含有指向专用地址的终结点 A 记录。把区域链接到无关网络，网关会继续解析公共记录，而隧道一侧看起来一切正常。

区域名称属于服务，而不是泛指专用链接。App Service 通常使用 privatelink.azurewebsites.net，存储和 SQL 有各自的命名空间，借用其他服务的区域只会得到一个存在却答不出有用内容的区域。

给客户端一个它真正能到达的解析器

168.63.129.16 从 Azure 虚拟机应答，并不是点到站点隧道另一端笔记本的 DNS 服务器。客户端需要一个可通过隧道到达的解析器：Azure DNS Private Resolver 的入站终结点、虚拟网络内部的转发器，或随 VPN 客户端配置文件下发的 DNS 服务器条目，让客户端直接向虚拟网络发问。

已配置但不可达的解析器表现与没有解析器完全一样，而症状是超时而不是错误应答，所以它常被误读为防火墙问题。用一个隧道本就应当承载的查询来测试它，而不要用本来就能经本地链路成功的公共名称。

如果你选择转发而不是推送设置，请只转发专用区域拥有的命名空间，即 privatelink.azurewebsites.net，而不是整个 azurewebsites.net。吞掉整个父后缀的条件转发器会把该服务的每次查询都送到 Azure，包括本应留在本地的查询。

使用证书为其签发的名称

地址正确之后，第二个故障就显露出来。存储和 App Service 会发布 privatelink 别名，而该别名不一定是证书里的名称。发往 privatelink.blob.core.windows.net 的一次 AzCopy 上传未通过验证；同样的上传发往 <account>.blob.core.windows.net/<container> 则解析到专用地址并通过，因此它在没有任何绕过的情况下留在了专用路径上。

这条规则在浏览器和 App Service 中都成立：用证书覆盖的主机名连接，让 DNS 提供专用地址。不要诉诸绕过验证，那会把命名失误变成安全退步。ping 成功只能证明路由，对握手中的名称一无所知，所以这些始终是分开的检查。

四个步骤，隔离每一层

  1. 确认 VPN 客户端持有来自点到站点地址池的地址，并且有到终结点专用地址的路由。
  2. 解析应用所用的确切名称，并把应答与终结点地址比较。
  3. 在服务端口上向终结点建立 TCP 连接，然后读取该连接上出示的证书名称。
  4. 到这时才测试授权，因为可用的路径和有效的证书仍然不会授予对资源的访问。

地址正确却连接被拒，指向网络安全组或专用终结点连接状态，而不是 DNS，所以再改解析器设置之前先查这两项。TLS 名称不匹配会把你带回 URL 中的主机名和证书的 subject。把解析输出、证书名称和确切的 URL 放在一起；这三个值能解释其中大多数情况，而且不必去动网关。

用虚拟网络内的 VM 作为对照。如果名称在那里解析为专用地址，而从隧道解析为公共地址，那么区域和记录都是对的，唯一差别就是客户端的解析器路径，这比再翻一遍终结点配置更快确认。

客户端也会缓存。十分钟前公共应答过的记录，在你修好区域后仍会继续应答，所以重测前先刷新。在 Windows 上，ipconfig /flushdns 会清除客户端缓存；名称解析策略规则依然存在，决定哪个后缀走哪台服务器，并且可能继续把该命名空间送到你刚刚替换掉的解析器。

hosts 条目应该放在哪儿

把终结点地址加进 hosts 文件是好的诊断、坏的设计。它证明名称到地址的映射就是缺失的那一环，也让你能测完后面的全部步骤，但它对用户不可见，终结点地址一变就失效，还会掩盖本应作答的区域。

残留的测试条目比过期的缓存更糟，因为它可能让修好的路径看起来是坏的，或让坏掉的路径看起来是修好的，取决于错误的方向。最后一次验证之前删掉它，只用生产解析器解析。

短名称需要搜索后缀，完全限定名则不需要，所以先测完全限定名，再决定工作流是否需要通过客户端配置文件下发后缀。Microsoft 在专用终结点 DNS 指南中记录了各服务的区域名称和记录形式；请阅读你自己服务的那一条，而不是从别的服务复制区域。

相关文章