SharePoint 链接经 VPN 失效，罪魁是已发布的 URL

通过 VPN 加载的 SharePoint 页面仍可能返回客户端无法解析的文档链接。请检查 DNS、路由、TLS 和已发布的 URL。

SharePoint 页面经 VPN 打开，第一个文档链接却以一个从未出现在地址栏里的名称失败。这个落差就是全部问题：页面的来源是一个 URL，而服务按另一个 URL 构造了下一个请求。已发布的 URL 是服务器端的决定，所以在客户端修复是搞错了方向。在动 DNS 或路由之前，先确认服务返回的是哪个名称。

首页与下一个请求使用了不同的名称

用地址访问服务器的用户看到的是可用的主页。该页面的文档链接是按服务自认为正在发布的 URL 生成的，而不是按浏览器输入的地址生成的。两者不一致时，下一次点击就会走向客户端从未解析过的名称。

把地址输一遍并不能修好每一个生成的链接，而把这个地址存成书签只会把问题藏到打开文档的那一刻。

这个故障很容易被误读成 VPN 问题，因为它只在隧道启用之后才出现。实际上隧道完成了自己的工作：它把请求带到一个既没有可用路径、也没有匹配证书的名称上。改任何一边之前，先把两个问题分开。一是数据包去哪里，二是服务选择发布哪个名称。

四个控制，一个名称

每个已发布的名称都必须通过四项彼此独立的控制。DNS 必须为真实客户端解析它，路由与访问策略必须放行这条路径，TLS 必须为该名称完成校验，服务本身也必须配置为发布它。

改动其中一项控制并不会完成其余几项。接受证书警告并不等于修好了名称解析。

下面的表格就是检查单的先后顺序。在第一个失败的环节停下，因为后面的修补无法弥补前面的缺口。

ControlQuestionWhere to look
DNSCan the client resolve the published name?Client resolver and split-DNS policy
Route and policyDoes the permitted path exist to the service?VPN routes and firewall rules
TLS identityDoes the certificate match the name in use?Certificate subject names and trust store
Publishing configWhich URL does the service return?Web application settings and site model

改动发布模型之前，先读懂它

SharePoint Server 的部署各不相同。经典 Web 应用可以使用备用访问映射，其中内部 URL 是服务器实际收到的地址，公共 URL 是它用来拼接链接的地址。基于主机名的网站集走另一条路线，按 Microsoft 的指引不能使用 AAM。

Microsoft 的规划指引也把 AAM 相关功能标记为已弃用，并建议新规划采用基于主机名的网站集。这让部署模型成为其所有者要回答的问题，而不是你可以随手打补丁的默认值。

在提出改动映射之前，先确认正在使用哪一种模型。给基于主机名的部署加一条 AAM 记录毫无作用，而给经典部署加一条则会一次性改变所有返回的链接。两者都是影响范围很大的配置变更，所以要分阶段实施并保留回滚方案。这并不是建议把遗留映射带进现代环境。

沿着失败的操作用力追，而不是盯着主页

记录失败请求实际使用的目标、客户端应用、时间和错误。浏览器和桌面应用可能经由不同的代理、VPN 或身份验证路径访问同一份文档。

浏览器能成功而 Office 客户端失败，这种差异正好提示是哪个上下文在解析名称。

如果 URL 和网络交接都能工作，服务却仍然拒绝该操作，剩下的问题就在应用层。文档权限和签出状态属于服务所有者，而 VPN 路由提供的是连通性，不是授权。

把交接过程从头到尾查一遍

在失败的客户端上按顺序执行检查：解析已发布的名称、用该名称请求页面，再从页面源码里取出文档的 URL 并请求它。每一步只隔离一项控制。

三条命令覆盖解析、TLS 和文档路径：

nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspx

如果只有经过隧道时解析才失败，嫌疑就在拆分 DNS 策略。如果 TLS 失败，就把证书名称与已发布名称做比较，而不是直接点过去。如果两者都成功而文档仍然打不开，那么错误已经与 URL 无关了。

相关文章