![您怎样弄清楚 Windows 机器如何解析共享名称?](https://linux22.com/image/552134/%E6%82%A8%E6%80%8E%E6%A0%B7%E5%BC%84%E6%B8%85%E6%A5%9A%20Windows%20%E6%9C%BA%E5%99%A8%E5%A6%82%E4%BD%95%E8%A7%A3%E6%9E%90%E5%85%B1%E4%BA%AB%E5%90%8D%E7%A7%B0%EF%BC%9F.png)
在将域从一个林迁移到另一个林时,我们遇到了一些奇怪的问题。我们尝试关闭旧域的域控制器,突然间,我们曾经在另一个域上访问的共享消失了。
我无法理解 Windows 客户端如何解析共享。例如,当我输入 \XXXXXX\yyy\zzzz 时,Windows 究竟会做什么来找出要连接的服务器?请注意,我们以前在旧域上也有 DFS 共享,因此这起着一定作用。
是否有任何工具可以帮助您跟踪 Windows 正在做什么?例如,如果我给它路径 \XXXXXX\yyy\zzzz,它会记录类似这样的内容 检查本地 NETBIOS 中的名称。在 netbios 中找不到名称。检查 DFS 缓存...在 DFS 缓存中找到,使用 \computer.domain.com\share 查找 \XXXXX\yyy\zzzz
整个故事是这样的。我们正在从一个域 D1.xxxx.com 迁移到另一个林中的 D2.yyyy.com。我们建立了跨域信任,除 DFS 之外的所有内容都已移动。由于我们遇到的所有麻烦,我们决定停止在域 2 中使用 DFS。相反,我们将在 D2 中拥有一个名为 D1 的主机,它将为整个 DFS 提供服务。我们已经设置了它并复制了所有文件。然后,我们关闭 D1 的所有域控制器并删除信任。现在,当我输入 \D1\root\things 时,我希望 D2 域上的机器转到 D1.yyyy.com 上名为 root 的共享。出于某种原因,这似乎没有发生,我不明白为什么。我尝试在客户端计算机上使用 dfsutil /pkflush,但仍然没有解决。
我现在想做的是确切地了解我的客户端计算机在尝试连接到 \D1\root\things 时正在做什么。查看网络上发生的事情没有帮助。我知道(或相当肯定)它仍在尝试转到旧的 DFS 共享。
答案1
您应该问的问题是 Windows 如何解析计算机或 DFS 名称。
举个例子
服务器名称 = 服务器
域名 = dom.local
服务器的 FQDN = server.dom.local
您的电脑的 DNS 后缀 = dom.local
共享路径由两部分组成。服务器或主机名“\servername”和共享本身“share1”。首先让我们以 ping 为例,看看当 Windows 将名称解析为 IP 时会发生什么。
您运行ping server
以获取 IP。此时您的 PC 查看其 TCP/IP 配置并获取 DNS 服务器的 IP。然后它查询此 DNS 服务器以解析名称...或者它可能使用 WINS(如下所述)。
现在很多人认为“哦,是的,这很简单,它会查询 DNS 服务器,我知道这是显而易见的”。事实并非如此!它并不总是查询 DNS 服务器,这就是人们感到困惑的地方。以下是实际发生的情况:
您的电脑将始终首先尝试将此名称解析为 DNS 名称。如果失败,它将尝试查询 WINS 服务器(如果本地电脑已配置了 WINS 服务器),如果失败,它将进行 NetBIOS 广播。它始终按此顺序进行。
现在请注意我上面提到的 DNS 后缀。如果这是除 dom.local 之外的任何其他内容,此 ping 将失败。这是因为当我 ping 它时,我没有输入 server.dom.local 的 FQDN,而是使用了它的一部分,只是“服务器”。Windows 在后台所做的是在其上附加 DNS 后缀(这就是它的用途)。因此,当您键入 ping server 时,您实际上会看到 windows 然后显示“ping server.dom.local”,请注意它是 FQDN。希望您能明白我在这里使用 DNS 查询的目的。由于您有两个独立的域,DNS 后缀可能不同。例如,如果我的 dns 后缀是 dom2.local,当我 ping server 时,它会在其上附加该后缀并尝试 ping server.dom2.local。然而,再次引起混淆的是,它实际上并没有在屏幕上显示(因为它失败了),所以人们认为它正在查询 server.dom.local,而实际上并非如此。一旦 DNS 失败,它就会转到 WINS,然后是 NetBIOS。一旦通过其他方式解析,实际显示的是“ping server”。注意到两者之间的细微差别了吗?当查询使用 DNS 时,它会显示“ping server.dom.local”,当它失败并使用 WINS 或 NetBIOS 解析时,它会显示“ping server”。您应该对此进行测试,以查看它是否正确地通过 DNS 解析名称。大多数人 ping 名称并得到回复,并认为 DNS 正在工作,因为它解析了名称。他们从未注意到它没有解析 FQDN,这意味着 DNS 实际上失败了。在两个域中,这一点非常重要,如果您不警惕,很容易从名称解析的角度造成严重破坏。大多数人对此一无所知,因为他们只有一个域。他们永远不需要知道 DNS 后缀的用途。
此时您应该知道您的共享位于哪个 IP 上。DFS 树也适用同样的方法。Ping DFS 名称,返回的 IP 会告诉您 DFS 根目录的位置。暂时忘掉 DFS。回到 PC 上...如果您的 DNS 查询解析了机器名称,那么这就是您的共享所在的位置,简单明了。
如果查询针对的是 DFS 名称空间,请找到服务器并加载 DFS 管理控制台。假设它是 \dom.local\share1。在此示例中,您 ping 了 dom.local 并发现它解析为 192.168.5.4。您通过 RDP 访问它并加载 DFS 管理器,现在本地化为“share1”。DFS 管理器将告诉您它是在本地服务器上还是重定向到另一台服务器。从那里您只需按照线索找到实际服务器,然后进行后续共享。
现在明白了吧?
好的,回答您更多的附加细节...我认为您没有正确阅读我的帖子并且怀疑发生了什么..开始吧。
还记得我上面说过的 DNS 域后缀以及它们在传输域时为何如此重要吗?假设您尝试连接到共享的这台 PC 仍然具有旧域的 DNS 后缀,即 xxxx.com。当您键入或 ping D1 时,它会将此 DNS 后缀附加在末尾。因此它实际连接的是 d1.xxxx.com...当您删除 xxxx.com 域时,它不再存在。尝试连接到 \d1。yyyy.com\root\things,而不仅仅是 \d1\root\things。如果可行,请告诉我,然后我们就可以继续
答案2
我相信在这种特殊情况下,Wireshark 之类的工具可能会派上用场。它实际上也显示 DNS 查询。