5

我们正在尝试通过 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.

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

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

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

4

2 回答 2

3

您会看到不同的行为，因为您使用不同的名称进行连接。一旦名称被尝试并失败，WebClient（这是启用 WebDAV 的服务）将缓存响应一段时间。要清除缓存，请在服务控制台中找到 WebClient 服务并重新启动它。或者从管理命令提示符执行以下命令：

net.exe stop webclient && net.exe start webclient
于 2016-06-15T17:22:01.703 回答
2

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

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

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

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

于 2013-01-31T21:10:24.000 回答