步骤 5 测试来自 Internet 和群集的 DirectAccess 连接

适用范围:Windows Server 2022、Windows Server 2019、Windows Server 2016

CLIENT1 现已准备好用于 DirectAccess 测试。

  • 测试来自 Internet 的 DirectAccess 连接。 连接CLIENT1 到模拟 Internet。 连接到模拟 Internet 时,会为客户端分配公共 IPv4 地址。 为 DirectAccess 客户端分配公共 IPv4 地址时,它会尝试使用 IPv6 转换技术与远程访问服务器建立连接。

  • 通过群集测试 DirectAccess 客户端连接。 测试群集功能。 在开始测试之前,建议关闭 EDGE1 和 EDGE2 至少五分钟。 有多种原因导致这种情况,其中包括 ARP 缓存超时和与 NLB 相关的更改。 在测试实验室中验证 NLB 配置时,需要耐心等待,因为配置更改不会立即反映在连接中,直到经过一段时间。 执行以下任务时,必须记住这一点。

    提示

    建议在执行此过程之前以及每次通过其他远程访问服务器测试连接时清除 Internet Explorer 缓存,以确保测试连接,而不是从缓存中检索网页。

测试来自 Internet 的 DirectAccess 连接

  1. 从 corpnet 交换机中拔下 CLIENT1,将其连接到 Internet 交换机。 等待 30 秒。

  2. 在提升的Windows PowerShell中,键入ipconfig /flushdns,然后按 ENTER。 这会从客户端计算机连接到公司网络时刷新客户端 DNS 缓存中可能仍然存在的名称解析条目。

  3. 在"Windows PowerShell"窗口中,键入Get-DnsClientNrptPolicy 并按 Enter。

    该输出显示名称解析策略表 (NRPT) 的当前设置。 这些设置指示所有到 .corp.contoso.com 的连接都应由远程访问 DNS 服务器解析,IPv6 地址为 2001:db8:1::2。 另外,请注意,NRPT 条目表明该值指示名称 nls.corp.contoso.com 存在免除条目;免除列表上的名称不由远程访问 DNS 服务器应答。 可以 ping 远程访问 DNS 服务器 IP 地址以确认与远程访问服务器的连接;例如,可以 ping 2001:db8:1::2。

  4. 在"Windows PowerShell"窗口中,键入ping app1并按 Enter。 应会看到来自 APP1 的 IPv6 地址的回复,本例中为 2001:db8:1::3。

  5. 在"Windows PowerShell"窗口中,键入ping app2 并按 Enter。 你应该看到由 EDGE1 分配给 APP2 的来自 NAT64 地址的答复,在本例中为 fdc9:9f4e:eb1b:7777::a00:4。

    ping APP2 的能力非常重要,因为成功表示你能够使用 NAT64/DNS64 建立连接,因为 APP2 是一个仅 IPv4 资源。

  6. 让Windows PowerShell窗口保持打开状态,以执行下一个过程。

  7. 打开Internet Explorer,在Internet Explorer栏中,输入 并 https://app1/ 按 Enter。 在 APP1 上,你将看到默认的 IIS 网站。

  8. 在"Internet Explorer栏中,输入 https://app2/ 并按 ENTER。 在 APP2 上,你将看到默认网站。

  9. 在" 开始" 屏幕上,键入\\App2\Files,然后按 Enter。 双击“新文本文档”文件。

    这演示了你能够使用 SMB 连接到仅 IPv4 服务器,以获取资源域中的资源。

  10. 在" 开始" 屏幕上,键入wf.msc,然后按 Enter。

  11. "Windows安全防火墙"控制台中,请注意,只有"专用"或"公共配置文件"处于活动状态。 必须Windows防火墙,DirectAccess 正常工作。 如果Windows防火墙,DirectAccess 连接将不起作用。

  12. 在控制台的左窗格中,展开"监视 " 节点,然后单击" 连接安全规则" 节点。 应会看到活动连接安全规则 :DirectAccess Policy-ClientToCorp、DirectAccessPolicy-ClientToDNS64NAT64PrefixExemption、DirectAccessPolicy-ClientToInfraDirectAccess Policy-ClientToNlaExempt。 将中间窗格滚动到右侧以显示" 第一个 身份验证方法"和" 第二个身份验证方法" 列。 请注意,第一条规则 (ClientToCorp) 使用 Kerberos V5 建立 Intranet 隧道,第三条规则 (ClientToInfra) 使用 NTLMv2 建立基础结构隧道。

  13. 在控制台的左窗格中,展开" 安全关联" 节点,然后单击" 主模式" 节点。 请注意使用 NTLMv2 的基础结构隧道安全关联和使用 Kerberos V5 的 Intranet 隧道安全关联。 右键单击显示"Kerberos V5 (用户") 第2 个身份验证方法"的条目,然后单击"属性"。 在" 常规" 选项卡上,请注意第二个身份验证本地 IDCORP\User1,表示 User1 能够使用 Kerberos 成功对 CORP 域进行身份验证。

通过群集测试 DirectAccess 客户端连接

  1. 在 EDGE2 上正常关闭。

    运行这些测试时,可以使用网络负载均衡管理器查看服务器的状态。

  2. 在 CLIENT1 的"Windows PowerShell"窗口中,键入ipconfig /flushdns,然后按 Enter。 这会刷新客户端 DNS 缓存中可能仍然存在的名称解析条目。

  3. 在"Windows PowerShell"窗口中,ping APP1 和 APP2。 应会收到来自这两个资源的回复。

  4. 在" 开始" 屏幕上,键入 \\app2\files。 APP2 计算机上应显示共享文件夹。 在 APP2 上打开文件共享的能力指示第二个隧道(要求用户进行 Kerberos 身份验证)正常工作。

  5. 打开Internet Explorer,然后打开网站 https://app1/ 和 https://app2/. 打开这两个网站的功能可确认第一个和第二个隧道已启动并正常运行。 关闭 Internet Explorer。

  6. 启动 EDGE2 计算机。

  7. 在 EDGE1 上执行正常关闭。

  8. 等待 5 分钟,然后返回到 CLIENT1。 执行步骤 2-5。 这确认在 EDGE1 不可用后,CLIENT1 能够透明地故障转移到 EDGE2。