步骤 5. 从 Internet 和通过群集测试 DirectAccess 连接
适用范围：Windows Server 2022、Windows Server 2019、Windows Server 2016
CLIENT1 现在已准备好进行 DirectAccess 测试。
测试来自 Internet 的 DirectAccess 连接性。 将 CLIENT1 连接到模拟的 Internet。 当连接到模拟互联网时，客户端被分配了公共 IPv4 地址。 当为 DirectAccess 客户端分配公共 IPv4 地址时，它会尝试使用 IPv6 转换技术建立与远程访问服务器的连接。
通过群集测试 DirectAccess 客户端连接。 测试群集功能。 在开始测试之前，我们建议你关闭 EDGE1 和 EDGE2 至少五分钟。 原因有很多，其中包括 ARP 缓存超时和与 NLB 相关的更改。 在测试实验室中验证 NLB 配置时，你需要耐心等待，因为配置更改要经过一段时间后才会立即反映在连接中。 在执行以下任务时，请务必牢记这一点。
提示
我们建议你在执行此过程之前，以及每次通过不同的远程访问服务器测试连接时，清除 Internet Explorer 缓存，以确保你正在测试连接，而不是从缓存中检索网页。
测试来自 Internet 的 DirectAccess 连接性
从公司网络交换机拔下 CLIENT1，并将其连接到 Internet 交换机。 等待 30 秒。
在提升的 Windows PowerShell 窗口中，键入 ipconfig /flushdns，然后按 Enter 键。 这将刷新名称解析条目，这些条目在从客户端计算机连接到公司网络时开始，可能仍然存在于客户端 DNS 缓存中。
在 Windows PowerShell 窗口中，键入 Get-DnsClientNrptPolicy，然后按 Enter 键。
该输出显示名称解析策略表 (NRPT) 的当前设置。 这些设置表明所有到 corp.contoso.com 的连接应由远程访问 DNS 服务器解析，并使用 IPv6 地址 2001:db8:1::2。 另外，请注意，NRPT 条目表明该值指示名称 nls.corp.contoso.com 存在免除条目；免除列表上的名称不由远程访问 DNS 服务器应答。 你可以对远程访问 DNS 服务器 IP 地址执行 ping 操作，以确认连接到远程访问服务器；例如，你可以对 2001:db8:1::2 执行 ping 操作。
在 Windows PowerShell 窗口中，键入 ping app1，然后按 Enter 键。 你应该看到来自 App1 的 IPv6 地址的回复，在本例中为 2001:db8:1::3。
在 Windows PowerShell 窗口中，键入 ping app2，然后按 Enter 键。 你应该看到由 EDGE1 分配给 APP2 的来自 NAT64 地址的答复，在本例中为 fdc9:9f4e:eb1b:7777::a00:4。
ping App2 的能力非常重要，因为成功表示你能够使用 NAT64/DNS64 建立连接，因为 APP2 是仅 IPv4 资源。
让 Windows PowerShell 窗口保持打开状态，以便执行下一过程。
打开 Internet Explorer，在 Internet Explorer 地址栏中，输入 https://app1/，然后按 ENTER 键。 在 APP1 上，你将看到默认的 IIS 网站。
在 Internet Explorer 地址栏中，输入 https://app2/，然后按 Enter 键。 在 APP2 上，你将看到默认网站。
在“开始”屏幕上，键入 \\App2\Files，然后按 Enter 键。 双击“新文本文档”文件。
此示例演示你能够连接到 IPv4 唯一的服务器是使用 SMB 来获取资源域中的资源。
在“开始”屏幕上，键入 wf.msc，然后按 Enter 键。
在“具有高级安全性的 Windows 防火墙”控制台中，请注意，只有专用或公用配置文件处于活动状态。 必须启用 Windows 防火墙，DirectAccess 才能正常工作。 如果禁用了 Windows 防火墙，DirectAccess 连接将不起作用。
在控制台的左窗格中，展开“监视”节点，然后单击“连接安全规则”节点。 你应该会看到活动的连接安全规则：DirectAccess Policy-ClientToCorp、DirectAccess Policy-ClientToDNS64NAT64PrefixExemption、DirectAccess Policy-ClientToInfra 和 DirectAccess Policy-ClientToNlaExempt。 向右滚动中间窗格，以显示“第一身份验证方法”和“第二身份验证方法”列。 请注意，第一个规则 (ClientToCorp) 使用 Kerberos V5 建立 Intranet 隧道，第三个规则 (ClientToInfra) 使用 NTLMv2 建立基础结构隧道。
在控制台的左窗格中，展开“安全关联”节点，然后单击“主模式”节点。 请注意使用 NTLMv2 的基础结构隧道安全关联和使用 Kerberos V5 的 Intranet 隧道安全关联。 右键单击将“用户 (Kerberos V5)”显示为“第二身份验证方法”的条目，然后单击“属性”。 在“常规”选项卡上，请注意“第二身份验证本地 ID”为“CORP\User1”，这指示 User1 能够使用 Kerberos 成功向 CORP 域进行身份验证。
通过群集测试 DirectAccess 客户端连接
在 EDGE2 上执行正常关机。
运行这些测试时，可以使用网络负载平衡管理器查看服务器的状态。
在 CLIENT1 上的 Windows PowerShell 窗口中，键入 ipconfig /flushdns，然后按 Enter 键。 这将刷新可能仍存在于客户端 DNS 缓存中的名称解析条目。
在 Windows PowerShell 窗口中，ping APP1 和 APP2。 你应该会收到来自这两个资源的回复。
在“开始”屏幕上，键入 \\app2\files。 你应该在 App2 计算机上看到共享文件夹。 在 APP2 上打开文件共享的能力表明第二个隧道（需要对用户进行 Kerberos 身份验证）工作正常。
打开 Internet Explorer，然后打开网站 https://app1/ 和 https://app2/. 打开两个网站的能力确认第一个和第二个隧道都已启动并运行。 关闭 Internet Explorer。
启动 EDGE2 计算机。
在 EDGE1 上执行正常关机。
等待 5 分钟，然后返回到 CLIENT1。 执行步骤 2 到 5。 这证实了在 EDGE1 变得不可用后，CLIENT1 能够透明地故障转移到 EDGE2。