当解析器位于对等 VNet 时 Azure P2S DNS 解析失败

客户端能访问自己的虚拟网络，却无法解析对等网络中的名称。除非双方都同意，对等连接不提供网关传输。

向 VM 发 ping 能通；询问其名称，客户端却说主机未知。当解析器位于对等虚拟网络而非承载 VPN 网关的那个网络时，这一对结果就是预期行为，再怎么排查解析器也改变不了。缺少的是一条路由契约，而对等连接默认不会提供它。两种拓扑在纸面上几乎一样，能用与不能用之间只差一对方向正确的对等连接开关。

设想一台笔记本电脑通过隧道连到 VNet2 中的网关，而提供 DNS 的域控制器位于 VNet1。

两种拓扑，一处差异

把解析器放进网关自己的虚拟网络，隧道一建立名称就能解析。这次查询不涉及任何对等连接设置。

把同一个解析器移到对等连接的另一侧，客户端仍能从 VM 得到响应，名称却依然未知。证书、隧道和客户端都没有变化。唯一移动的是解析器的位置。对等连接给它的是通往该地址的路由，而不是让网关把流量送到那里的授权。

A 侧：在网关所有者上允许网关传输

对等连接把两个虚拟网络连在一起，但对经由网关到达的流量并不具备传递性，而点到站点请求正是这样到达的。因此在设计允许之前，VNet2 中的网关无权把查询交给 VNet1。授权就是网关所在网络所拥有的对等连接上的一个开关。

在 VNet2 指向 VNet1 的对等连接上设置 Allow gateway transit。该属性属于对等连接对象，而不属于网关资源，所以要在对等连接边栏中读取和修改。A 侧全部内容就是这些。

B 侧：在对端使用远程网关

另一半是镜像：在 VNet1 指回 VNet2 的对等连接上启用 Use remote gateways。在两端或只在一端打开同一个标志，只会留下一条半成品路径和原封不动的症状。只有带 VPN 网关的网络才允许传输，而对端才是使用它的那一侧。

在两个网络上分别读取这两个属性，而不是相信你上次打开的 Portal 边栏。

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

并排查看这一对开关是发现设置反向的最快方法。如果对等连接在网关一侧报告 AllowGatewayTransit false，无需抓包就能解释整个故障。

客户端还必须收到什么

路由是必要条件而非充分条件，因为点到站点配置文件还必须交给客户端一个在传输生效后能应答的 DNS 地址。平台解析器不是那个地址：它只应答链接到虚拟网络的 Azure Private DNS 区域，对你自建目录服务器上托管的区域一无所知，而本部署用的正是后者。把客户端指向它，公网名称会愉快解析，内部主机却依旧未知。

在改动其他东西之前，先从已连接的笔记本查询该解析器。

nslookup dc01.corp.example 10.1.0.4

超时说明路径仍然缺失。权威应答则把问题推回客户端，通常是某个从未被追加的后缀，于是短名称被送到一个公网解析器，在那里愉快地失败。

在站点到站点一侧比较同一份契约

这些并不专属于笔记本。把客户端换成分支机构的站点到站点连接，双向要求依然成立：分支机构直接到达网关网络，而隔了两个网络的服务仍在是对等连接之后。

传输必须在两个对等连接上同时授予，而授予它的开关位于对等连接上，不在客户端类型上。

在归咎网关之前

Windows 为每个适配器保存一份解析器列表，所以在归咎网关之前，先确认隧道接口实际收到的是什么。

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

否定应答会在缓存中比路由修复活得更久，而过期的后缀列表会继续把查询送到从未托管该区域的地方。清空缓存、再次查询，并记录是哪个服务器在应答。

还有两个更小的条件决定路径是否成立：地址空间不得重叠，且解析器子网上的网络安全组必须放行客户端池，它只是又一个源地址段。用 VM 侧的有效路由检查加上客户端的一次直接查询来验证，这样区域问题、后缀问题或过滤规则就不会被误认为缺少传输。

相关文章