除非指定端口 443，否则 SSL 上的“净使用”会失败

Question

我们正在尝试通过 SSL使用net use连接到 WebDAV 服务器。在某些服务器上，我们看到一个问题，即只有在 URL 中指定端口 443 时，此连接才能成功。

做地图

net use * "https://example.com:443/folder"
net use * "\\example.com@SSL@443\folder"

而且，奇怪的是，这也是： net use * "\\example.com@SSLasdf\folder"

不映射

net use * "https://example.com/folder"
net use * "\\example.com@SSL\folder"

在非工作情况下，我们始终收到以下错误：

System error 67 has occured.
The network name cannot be found.

我们注意到一些可能有用的信息：

• 我们有一个测试服务器，它的配置方式与生产服务器相同，并且按预期工作。
• 在非工作情况下，在生产服务器上从未看到来自故障主机的传入请求。
• 所有客户端都基于相同的图像。
• 这个问题并没有在所有客户端上一致地表现出来——有些工作，有些没有。
• 客户端 DNS 缓存中存在 example.com 的现有有效条目。
• 刷新受影响服务器的客户端 DNS 缓存并不能解决问题。
• 一旦问题出现，它似乎坚持。也就是说，如果我执行其中一个工作映射，将其删除，然后立即执行其中一个非工作映射，问题仍然存在。

我们完全被难住了。有什么理论吗？

Answer 1

我们最终确定我们误解了返回的System Error 67结果net use。我们发现了两件有趣的事情：

1. 如果 WebDAV 在初始根文件夹上返回 404 或 50x PROPFIND，net use将（正确地）将此解释为根文件夹不可用。事实上，它说找不到网络名称，让我们相信问题出在名称解析上，但它实际上只是说，“嘿，我在这条路径上找不到任何东西。”

2. 如果“net use”由于 404/50x 而失败，则似乎在短时间内它会自动使同一主机的任何其他映射失败，而无需发出请求。例如，如果net use http://me.com/foo返回 404，那么net use http://me.com/bar如果快速连续执行第一个调用，则将立即失败，并且在 WebDAV 服务器日志中不会看到任何请求记录。

我最好的猜测是附加@443端口并没有产生任何真正的区别。它可能所做的就是欺骗人们net use认为它正在与不同的主机交谈，至少是为了其“自动失败”功能的目的。但这只是一个猜测。