本章提供有关如何对 Internet 协议安全性 (IPsec) 问题（如服务器和域隔离方案中的安全性问题）进行疑难解答的信息，这些信息依赖于 Microsoft 信息技术 (IT) 小组的经验和方法。 在有可能的时候，本章将引用现有的 Microsoft 疑难解答过程及相关信息。

Microsoft IT 支持基于一个多层支持模型，咨询台被称为第 1 层支持。 汇报过程使咨询台职员能够汇报需要专家予以协助的事件。

本章中的过程引用了三个级别的支持：第 1 层、第 2 层和第 3 层。 为了确保提供的指南尽可能地实用并且精确，大部分内容是第 2 层的。 最初，提供了第 1 层指南以帮助组织机构尽快确定问题是否与 IPsec 相关，如果是，就生成必需的信息以帮助第 2 层支持工程师对问题进行疑难解答。

本章未提供支持第 3 层疑难解答工作所需的高度详细并且复杂的信息。 如果本章提供的信息无法解决 IPsec 问题，Microsoft 建议您与 Microsoft® Product Support Services 联系以获取其他帮助。

本章提供的许多由 Microsoft 使用的支持过程、工具和脚本仅供您参考。 您应该根据贵公司的特定需求来决定是否采用这些建议和工具。

当使用 IPsec 来保护网络中的传输控制协议 (TCP) 和用户数据报协议 (UDP) 通信流时，典型的 TCP/IP 网络疑难解答过程和工具就会变得无能为力了。 因此，规划并开发当使用（或尝试使用）IPsec 来进行通信的计算机之间发生问题时使用的 IPsec 专用疑难解答技术十分重要。

本页内容

	支持层和汇报
	第 1 层疑难解答
	第 2 层疑难解答准备
	IPsec 疑难解答过程
	第 3 层疑难解答
	总结

支持层和汇报

在 Microsoft 中，服务器和域隔离支持是一个标准产品，并且是在标准服务级别协议 (SLA) 中定义的。 下列各层提供了隔离支持：

下一节内容对第 1 层支持组织中的咨询台职员可以使用的疑难解答技术进行汇总。

返回页首

第 1 层疑难解答

此部分内容阐述咨询台职员（他们提供第 1 层支持）在对与 IPsec 相关的问题进行疑难解答时使用的整体过程。 通常，第 1 层支持人员是通过电话提供服务的咨询台职员，他们尝试以远程方式诊断问题。

问题是否出自 IPsec？

咨询台可能会接到诸如“我在打开 IPsec 之前无法连接到服务器 x”或“昨天一切正常，今天网络就瘫痪了！”之类的电话。根据 Microsoft IT 的经验，有关各类网络连接问题和“访问被拒绝”事件的 IPsec 电话咨询不断增加的原因是人们越来越对应用程序和网络行为加以关注。 如果客户认为问题可能与 IPsec 相关，他们就会致电咨询台。 服务器和域隔离实施方案应该包括一个电话分类系统，这样咨询台人员就能够提供一份清晰的有关 IPsec 相关问题数量和性质的报表。

在向呼叫者了解适当的管理信息之后，咨询台职员应该遵循已定义的疑难解答过程。 由于 IPsec 策略设计对通信的影响可能有所不同，并且由于配置过程可能需要几天或几个星期的时间，因此应该针对每一组正在实施的隔离更改来定义并更新流程图。 咨询台管理人员必须参与此项规划过程。

咨询台的目标应该是对问题进行分类，以便可以尝试已知的解决方案。 如果这些尝试无法解决问题，咨询台人员就可以确保收集正确的信息并将该问题汇报给第 2 层支持。 例如，咨询台应该能够按照以下方式确定问题的各种类型：

根据组织机构的不同，咨询台可能会使用“远程协助”或“远程桌面”来连接至呼叫者的计算机。 本章提供的指南不要求使用远程访问，尽管这些工具对于咨询台人员指导呼叫者使用 IPsec 监视器 Microsoft 管理控制台 (MMC) 管理单元或事件日志查看器来说可能非常方便。

在使用了服务器隔离而未使用域隔离的方案中，咨询台人员应该了解哪些服务器是隔离组的成员。

指定范围和严重性

第 1 层支持人员首先必须解决的其中一个问题是：哪些用户受问题影响？ 支持人员需要了解其他用户是否也遇到了同一问题，如果是，还需了解那些用户的数目以及所在位置。 然后，支持人员必须检查问题的范围。 例如，该问题是仅仅影响与单一服务器的连接性，还是存在更广泛的问题，如网络中发生大范围的登录或身份验证失败？

连接性问题可能涉及网络通信中使用的许多不同的层和技术。 支持工程师应该对 Windows TCP/IP 网络通信方式以及与解决方案相关的特定问题有一般的了解。 此部分内容回顾不同类型的问题以及第 1 层支持人员针对每种问题必须处理的常见情况。

另外两个在 IPsec 企业部署中也很常见的服务器和域隔离解决方案特征是：使用子网筛选器来定义内部网络中使用的地址范围并且应用基于域成员身份和组成员身份的 IPsec 策略，而不考虑计算机在内部网络中的所处位置。 因此，如果子网筛选器设计或者该计算机用来访问其他计算机的网络路径有问题，连接性问题就可能只在网络的某些区域出现（使用特定 IP 地址时出现问题，例如无线地址，而不是 LAN 地址），或者仅仅在某些计算机上发生连接性问题。

疑难解答流程图

本节提供的电话处理流程图是由 Microsoft IT 开发的，其目的在于帮助对第 1 层 IPsec 支持问题进行分类。 除了标准工具以外，其中两个流程图还提到了 IPsec 策略刷新脚本，此脚本的描述在本章随后的“支持脚本示例”一节提供。

图 7.1 用于进行初始诊断以及确定问题类型：

•	是网络连接性问题吗？ 如果是，尝试进行基本的网络疑难解答。 如果不成功，就汇报给第 2 层支持。
•	是名称解析问题吗？ 如果是，尝试进行基本的名称解析疑难解答。 如果不成功，就汇报给第 2 层支持。
•	是应用程序问题吗？ 如果是，就汇报给第 2 层支持。
•	是呼叫者计算机的 IPsec 问题吗？ 如果是，转到图 7.2。
•	是呼叫者尝试访问的目标计算机的 IPsec 问题吗？ 如果是，转到图 7.3。 图 7.1 无法与目标计算机进行通信时的疑难解答过程 查看大图

注：此流程图假定呼叫者计算机正在运行 IPsec，并且 DNS 逆向查找区域已被配置为允许 ping –a 命令正常工作。

图 7.2 旨在帮助确定与呼叫者自己的计算机相关的问题。 注意，除了进行诊断以外，此流程图还提到了使用 IPsec 策略刷新脚本（请参阅本章随后的“支持脚本示例”），该脚本可能能够在不需要确定问题的情况下解决问题。 图 7.2 中的步骤帮助确定呼叫者计算机的下列潜在问题：

•	是 RRAS 问题吗？ 如果是，或者停止 RRAS 服务（如果不需要 RRAS ），或者将问题汇报给第 2 层支持。
•	是策略问题吗？ 如果是，尝试刷新组策略和 IPsec 策略。
•	是域帐户问题吗？ 如果是，请为呼叫者计算机创建域帐户。
•	上述全都不是？ 如果无法通过刷新 IPsec 策略和/或创建域帐户解决问题，则将该问题汇报给第 2 层支持。 图 7.2 对与呼叫者计算机 IPsec 相关的问题进行疑难解答 查看大图

图 7.3 旨在帮助确定与特定目标计算机相关的问题。 注意，此流程图还提到了 IPsec 策略刷新脚本，该脚本可能能够在不需要确定问题的情况下解决问题。 图 7.3 帮助确定目标计算机（或通往目标计算机的路径）的下列潜在问题：

•	是 RRAS 问题吗？ 如果是，就汇报给第 2 层支持。
•	是 IPsec 策略问题吗？ 如果是，尝试刷新组策略和 IPsec 策略。 然后，检查网络连接。
•	是网络连接性问题吗？ 如果是，就汇报给第 2 层支持。
•	是登录权限问题吗？ 如果是，就汇报给第 2 层支持。 图 7.3 对与目标计算机 IPsec 相关的问题进行疑难解答 查看大图

在第 1 层支持人员处理完这些流程图之后，问题将具有下列其中一种状态：

预防社会工程攻击

在隔离解决方案中，咨询台人员可能会了解到 IT 环境中未受 IPsec 保护的特定区域，如免除列表所包含的计算机。 这些区域不能用来保护敏感信息，这是因为，在其他安全性解决方案中，此类关键信息只能由高级别支持小组使用。 因此，咨询台人员应该接受有关如何检测和抵御社会工程攻击的培训。

在社会工程攻击中，不受信任的人员尝试获取有关安全性实施方式以及安全性弱点的信息，这通常是简单地利用人们信任他人的特点进行的。 咨询台人员应该谨慎地管理下列信息：

咨询台人员还应该接受培训，当呼叫者请求他们连接至呼叫者计算机 IP 地址以了解是否发生问题时，他们应该有所警觉（例如，攻击者可能会请咨询台人员使用文件共享、远程桌面、Telnet 或其他网络协议来连接至他们的计算机）。 如果咨询台人员在不使用 IPsec 的情况下进行连接，攻击者的计算机就可以了解到有关密码的信息或者（在某些情况下，例如使用 Telnet 时）窃取密码。 发生这种情况的原因是，某些客户端网络协议在透露与用户身份或密码相关的信息前未首先进行身份验证（从而错误地信任目标计算机）或者未进行强密码保护。

支持脚本示例

对于大部分疑难解答方案来说，可以在确定适当的信息后快速地确定解决方案。 您可以使用各种 Windows 工具（如流程图中提到的工具）来获得此信息。 在 Woodgrove Bank 解决方案中，开发了许多脚本来提供关键信息，而不要求第 1 层支持人员详细了解工具操作和语法。 这些脚本在本指南的“工具和模板”下载文件夹中提供。

可供第 1 层支持使用的脚本

如果用户是他们的计算机的本地管理员，咨询台人员就可以请他们运行本解决方案附带提供的三个脚本其中之一。 这些脚本是本指南详细描述的 Woodgrove Bank 环境所使用的自定义脚本的示例。 本章阐述这些脚本的目的是说明如何使用脚本来对疑难解答过程进行支持。

注：这些脚本是经过测试的示例，但 Microsoft 不支持这些脚本。 机构应该将这些脚本用作自己的自定义解决方案的基础。

IPsec_Debug.vbs

除了提供调试信息以外，此脚本实际上可以解决一些问题。 此脚本停止并重新启动 IPsec 服务（这将删除所有当前 IKE 和 IPsec 安全关联）、强制进行组策略刷新以从 Active Directory® 目录服务重新加载当前域指派的 IPsec 策略并更新策略缓存。 为了避免丢失远程桌面会话连接，应该将此脚本下载到呼叫者的计算机并使用具有管理权限的帐户来以本地方式运行该脚本。 请在命令提示符处使用以下语法来运行该脚本：

    cscript IPsec_Debug.vbs

该脚本执行下列功能：

此脚本还启用所有与 IPsec 相关的记录，以便第 2 层支持进行疑难解答。

Detect_IPsec_Policy.vbs

此脚本通过在当前本地注册表缓存中检查域 IPsec 策略的策略版本信息来确定计算机是否正在运行正确的 IPsec 策略。 请在命令提示符处使用以下语法来运行该脚本：

    cscript Detect_IPsec_Policy.vbs

注：IPsec_Debug.vbs 也调用此脚本，因此，如果运行了该脚本，就不需要运行此脚本。

Refresh_IPsec_Policy.vbs

此脚本就是疑难解答流程图中提到的 IPsec 策略刷新脚本。 此脚本刷新计算机的 Kerberos 身份验证协议票证和组策略，如果问题是由不正确的 IPsec 策略指派或下载组策略失败而引起的，此脚本可能能够解决问题。 请在命令提示符处使用以下语法来运行该脚本：

    cscript Refresh_IPsec_Policy.vbs

汇报

当咨询台人员需要汇报可能的 IPsec 问题时，第 1 层支持应该收集下列信息并随服务请求一起传递：

服务器隔离方案通常有自己的支持小组来调查网络访问组的成员身份。

返回页首

第 2 层疑难解答准备

第 2 层支持扮演两个主要角色。 首先，作为所有第 1 层汇报的接收者，第 2 层支持对问题进行验证并回顾第 1 层支持执行的步骤，以确保未遗漏任何疑难解答步骤。 在这方面，第 2 层支持应该确认第 1 层支持汇报的任何问题都确实是由 IPsec 引起的，而不是误诊。 其次，作为熟练的网络支持工程师，第 2 层支持人员应该能够运用他们的技能和经验（在下一节列出）来通过日志分析成功地解决问题，而不必获取对计算机的管理控制权。 但是，日志仅捕获了信息，要完成纠正操作，就需要管理权限。 并不期望第 2 层支持人员应该是域管理员或者能够更改基于域的 IPsec 策略或计算机组成员身份。

第 2 层支持技巧

提供第 2 层 IPsec 支持的支持人员应该具备下列领域的技巧和经验：

使用 IPsec 时固有的问题

如上一节所述，服务器和域隔离解决方案的第 2 层支持人员需要了解受 IPsec 保护的通信的详细信息，但他们还必须能够隔离与其他技术组件相关的问题。

为了能够成功地在两台计算机之间进行 IPsec 通信，两台计算机通常需要相兼容的 IPsec 策略。 例如，当远程计算机不具有适当的 IPsec 策略时，IPsec 策略可能会将通信阻止。 尽管这在进行策略更改时可能是有意的或可接受的行为，但是否阻止了与一台或多台计算机的网络连接并引起应用程序警告或错误可能并不会立即有所表现。 在最糟糕的情况下，管理员可能意外地对所有域成员指派了阻止所有通信流的 IPsec 策略。 除非立即意识到错误并在进行原始指派之后快速地复制正确的指派，否则错误策略的复制不容易被停止。 此类错误将导致这样一种情况：客户端与域控制器之间的通信将需要使用 IPsec。 由于此解决方案使用的身份验证依赖于 Kerberos 协议，因此任何继承此策略的客户端都将无法完成登录过程 – 这是因为它们无法获取必需的 Kerberos 票证来保护通信。 管理员必须仔细地为任何策略更改作好规划并确保存在程序性的安全措施来减轻此类情况的严重性。

本章末尾的“更多信息”一节列出的疑难解答指南提供了有关 TCP/IP 疑难解答的背景信息。 然而，这些指南中提到的许多过程只有在 IPsec 提供了成功的连接时才能正常发挥作用。 如果 IKE 或 IPsec 发生故障，则很有可能这些过程和工具中的绝大部分都会失效。 在服务器和域隔离方案中，背景指南中记载的某些过程可能完全没有作用，即使 IPsec 提供了成功的连接亦如此。 支持机构应该更新并且自定义疑难解答工具和过程以使它们在服务器和域隔离环境中仍然有效。 由于可以通过许多不同的方法来部署 IPsec 策略以便控制并帮助保护通信流，所以机构不大可能只能依靠现有的过程和一般工具包。

对于支持人员来说，记录网络疑难解答工具在服务器和域隔离或某些其他 IPsec 部署工作正常的实验室环境中获取的预期输出示例十分重要。 在许多情况下，网络诊断工具不会预料到“回退到使用明文”所产生的三秒钟延迟或者 IPsec 安全关联 (SA) 的 IKE 初始协商所需的短暂延迟。 因此，这些工具可能会在最初运行时显示一种结果但在运行几秒钟之后显示另一结果。 此外，当 IPsec 故意拒绝网络访问时，这些工具将报告故障。 故障类型将取决于工具以及 IPsec 环境。

注：在有关第 1 层支持的内容中，术语“呼叫者”和“目标”用来帮助支持人员对常见问题进行疑难解答。 在有关第 2 层支持的内容中，最好使用 IPsec 术语“发起方”和“响应方”以使更高级的疑难解答过程更为清晰。 本章的余下部分将使用这两个 IPsec 术语。

组策略和组成员身份

基于域的 IPsec 策略依赖于组策略以及 GPO 的下载。 如果客户端组策略系统在检测 GPO 更改或者下载它们时发生错误，则 IPsec 连接性可能会受影响。 如果组策略指派是由组织单位 (OU) 成员身份控制的，并且计算机帐户被意外地移至另一 OU、被删除或者在错误的 OU 中被重新创建，就可能导致指派不适当的 IPsec 策略。

此解决方案使用域安全组来控制策略指派以及控制网络访问。 组成员身份包含在生存期相当长的 Kerberos V5 身份验证协议票证（既包括 TGT 票证也包括服务票证）中。 因此，管理员必须为计算机接收新的 Kerberos TGT 和服务票证凭据（它们包含组成员身份更新）所需的时间作好规划。 对于 Kerberos 协议来说，很难确定计算机的 Kerberos 票证是否包含正确的组成员身份。 这种困难是“故意”造成的，这是因为有关组成员身份的所有信息都以加密形式存储在票证中。 必须使用目录服务中的信息（而不是使用票证本身所包含的信息）来确定组成员身份。

Kerberos 身份验证

服务器和域隔离设计使用 Kerberos V5 协议来进行 IKE 身份验证。 由于 Kerberos 协议要求成功地建立网络连接并且需要使用 DNS 和域控制器提供的服务，所以，连接失败将导致 Kerberos 身份验证和 IKE 失败。 （如果 Kerberos 本身失败，IKE 也将失败。）因此，计算机 A 与计算机 B 之间的连接问题可能是由于计算机 A 与计算机 C 之间的网络连接被阻止引起的，这些问题是由于 Kerberos 协议无法针对域控制器进行身份验证导致的。 在此类情况下，Windows 审核与安全日志中的 547 事件所提供的信息通常能够提供有关问题根源的宝贵指南。

需要受 IPsec 保护的入站通信流

此服务器和域隔离解决方案指定需要使用受 IPsec 保护的通信才能进行入站访问。 此项要求将导致在不受信任计算机或专用网络监视设备上运行的远程监视工具报告远程计算机不可访问。 如果这些计算机或设备无法加入“受信任”环境，它们将无法执行监视功能，直到对设计添加某些特定的免除为止。 由于可能需要 IPsec 才能与受信任主机建立连接（这意味着管理员可能无法连接至受信任主机并接着停止 IPsec 服务而不丢失连接），所以疑难解答比较复杂。 如果管理员的 IPsec 策略允许“回退到使用明文”，则在远程计算机上停止服务之后，远程连接将出现 3 到 4 秒钟的延迟。 但是，如果在远程计算机上停止 IPsec 服务，就会删除当前已连接的所有其他计算机正在使用的 IPsec SA。 如果这些计算机无法“回退到使用明文”，通信就会停止，TCP 连接最终将超时。 由于 TCP 通信的突然中断会导致应用程序数据毁坏，所以停止 IPsec 服务只应该作为疑难解答过程中的最后一个选项使用。 在停止 IPsec 服务之前，计算机应该已准备好关机，以使所有已连接的用户和应用程序可以正确地终止通信。

通信方向问题

一种常见的疑难解答情况是：一个方向上的通信成功，但反方向的通信失败。 IKE 身份验证通常要求在计算机之间进行相互身份验证。 如果一台计算机在为远程计算机启动 IKE 主模式时无法获取 Kerberos 票证，则 IKE 将失败。 当启动计算机的 Kerberos 客户端无法访问目标计算机所在域中的域控制器时，就会发生这种情况。 如果计算机是并非相互信任（双向信任）的域的成员，则一台计算机发起通信时 IKE 主模式协商就会成功，而另一台计算机发起通信时 IKE 主模式协商就会失败。 同样，两台计算机上的入站网络登录权限可能不同。 IKE 主模式协商和快速模式协商有可能不仅仅是由于这些原因而在一个方向上失败的，失败原因也有可能是因为两端的 IPsec 策略设计不兼容。

在 IPsec 层上方拦截通信流的基于主机的防火墙可能限制了连接方向。 某些基于主机的防火墙在 IPsec 层下方拦截通信流。 在成功地建立 IPsec 通信之后，就有可能在一段时间内在两个方向上都允许受 IPsec 保护的通信流。

网络路由器或防火墙进行的状态筛选也会阻塞 IKE 重新生成密钥操作或 IPsec 通信流，而不会影响其他诊断协议，如 ICMP。 一台计算机上的 TCP 和 UDP 端口无法访问的原因是服务未运行，或者是因为在 IPsec 层上方工作的设备（如 Windows 防火墙或网络路由器）阻塞了访问。

网络跟踪和高级网络路径疑难解答

IKE 协商失败通常会导致发生故障的计算机停止响应 IKE 协商，或者，在某些情况下，计算机会重新发送上一条“正常”消息，直到达到重试限制为止。 IKE 必须能够发送包含 Kerberos 票证的片段 UDP 数据报，这是因为此类数据包的目标 IP 地址通常会超出路径的最大传输单位 (PMTU)。 如果未正确地支持片段，某条路径上的网络设备就可能会将此类分段丢弃。 此外，网络可能无法正确地传送 IPsec 数据包的 IPsec 协议数据包或片段。 IPsec 与 TCP 的集成使 TCP 能够减小数据包大小以容纳 IPsec 标头的开销。 但是，在 TCP 握手期间进行的 TCP 最大段大小 (MSS) 协商不考虑 IPsec 开销。 因此，在网络中还需要进行 ICMP PMTU 发现才能确保成功地进行受 IPsec 保护的 TCP 通信。 因此，对连接故障进行疑难解答时，可能会要求对通信的一端或两端进行网络跟踪，并且需要通信两端的日志。

技术支持工程师应该了解如何阅读网络跟踪，并且还需了解 IKE 协商。 服务器应该安装 Windows 网络监视器软件。 Windows 2000 的网络监视器能够对 IPsec AH 和 IKE 进行分析。 Windows Server 2003 添加了对分析 IPsec IPsec ESP-null、在未进行加密时分析 ESP 以及分析用于 NAT 遍历的 UDP-ESP 封装的支持。

疑难解答工具包

在开始进行疑难解答前，确定可以用来抽取信息以帮助您完成疑难解答过程的实用程序十分重要。 本节并不打算重复 Windows 2000、Windows XP 或 Windows Server 2003 的帮助所提供的信息或者您通过 Microsoft Windows Server™ 2003 网站的“Troubleshooting tools”页面可以获得的信息，网址为：www.microsoft.com/resources/documentation/
WindowsServ/2003/standard/proddocs/en-us/
sag_IPSec_tools.asp。

仅当通过参考的疑难解答工具页面确实找不到详细的工具信息，或者需要对各个操作系统版本进行总结时，本节才提供了该信息。

IP 安全策略管理 MMC 管理单元

IP 安全策略管理 MMC 管理单元用来创建和管理本地 IPsec 策略或存储在 Active Directory 中的 IPsec 策略。 此管理单元还可用来修改远程计算机上的 IPsec 策略。 Windows Server 2003、Windows XP、Windows 2000 Server 和 Windows 2000 Professional 操作系统都提供了 IP 安全策略管理 MMC 管理单元，此管理单元可用来查看和编辑 IPsec 策略详细信息、筛选器、筛选器列表和筛选器操作，并可用来指派和取消指派 IPsec 策略。

IP 安全监视器 MMC 管理单元

IP 安全监视器 MMC 管理单元能够显示 IPsec 统计信息和活动 SA。 此管理单元还用来查看有关下列 IPsec 组件的信息：

虽然这个管理单元是 Windows XP 和 Windows Server 2003 操作系统的部件，但它在 Windows XP 和 Windows Server 2003 版本中具有不同的功能和界面。 并且，Windows Server 2003 版本提供了下列附加功能：

Microsoft 知识库文章 818043“用于 Windows XP 和 Windows 2000 的 L2TP/IPSec NAT-T 更新”所描述的更新包含了用于 Windows XP 的管理单元更新，网址为 http://support.microsoft.com/?kbid=818043。 此更新使您能够从 Windows XP 查看 Windows Server 2003 计算机。 经过更新的 IP 安全监视器 MMC 管理单元也可以读取 Windows Server 2003 中创建的高级功能部件（例如 Diffie-Hellman 2048 组信息、证书映射和动态筛选器），但是无法编辑它们。 要了解更多信息，请参阅 KB 参考文章。

Netsh

Netsh 是一个命令行脚本实用程序，它允许您显示或修改网络配置。 另外，您可以本地方式或远程方式使用 Netsh。 Windows 2000、Windows XP 和 Windows Server 2003 都提供了 Netsh。 但是，Windows Server 2003 版本还提供了 IPsec 诊断和管理功能。 只有 Windows Server 2003 提供了用于 IPsec 的 Netsh 命令；这些命令替换了 Windows XP 中的 Ipseccmd 和 Windows 2000 中使用的 Netdiag。

Ipseccmd

Ipseccmd 是一个命令行工具，它用于替换 IP 安全策略 MMC 管理单元。 只有 Windows XP 提供了此工具，Windows XP Service Pack 2 为此工具提供了附加功能。

您必须从 Windows XP CD 上的“Support Tools”文件夹中安装 Ipseccmd。 Windows XP SP2 提供了此工具的更新版本，您必须从 Windows XP SP2 CD 上的“Support Tools”文件夹中安装此版本。 SP 以前的工具版本无法在经过更新的计算机上运行，并且更新后的版本也无法在 SP 以前的计算机上运行。

更新后的 Ipseccmd 实用程序具有下列功能：

要了解有关更新后的 Ipseccmd 实用程序的更多信息，请参阅前面提到的 Microsoft 知识库文章 818043。

要显示所有 IPsec 策略设置以及诊断统计信息，请使用以下语法：

ipseccmd show all

要显示当前指派的并且活动的 IPsec 策略（本地策略或 Active Directory 策略），请使用以下语法：

ipseccmd show gpo

注：此命令只适用于 SP2 版本。

要在 Windows XP SP2 中启用调试记录，请使用以下语法：

ipseccmd set logike（不需要重新启动 IPsec 服务）

要关闭调试记录，请使用以下语法：

ipseccmd set dontlogike（同样不需要重新启动 IPsec 服务）

注：您只能在 Windows XP SP2 中使用 Ipseccmd 来启用 Oakley 记录；上述命令在 SP2 版本以前的计算机上无法运行。

Netdiag

Netdiag 是一个命令行诊断工具，它用来测试网络连接和配置（包括 IPsec 信息）。 Windows 2000、Windows XP 和 Windows Server 2003 都提供了 Netdiag，但它在不同操作系统版本中的功能有所不同。 在 Windows Server 2003 中，Netdiag 不再具有 IPsec 功能；但是，您可以使用 netsh ipsec 上下文，并且还可以通过 Netsh 来进行基本网络测试。 对于所有操作系统版本来说，通过检查 Microsoft 下载中心确保您使用的是最新版本十分重要。 您必须从所使用的 Windows 操作系统 CD 的“Support Tools”文件夹安装 Netdiag。

注：安装 Windows XP SP2 时，不会更新 Netdiag。

Netdiag 在 IPsec 疑难解答方面的实用性随操作系统版本的不同而有所变化。 下表对功能方面的差别作了描述。

表 7.1：不同操作系统中的 Netdiag IPsec 功能

* 提供网络诊断信息，但仅显示 IPsec 策略名。 使用 Ipseccmd 可以获得其他 IPsec 信息。

** 提供网络诊断信息，但不显示任何 IPsec 信息。 您应该使用以下语法：netsh ipsec dynamic show all。

其他可以支持 IPsec 的有用工具

除了上述 IPsec 专用工具以外，下表列示的工具在疑难解答方面对您可能非常有用，您应该将它们包括在第 2 层疑难解答工具包中。

表 7.2：其他可用于进行 IPsec 疑难解答的有用工具

对 IPsec 使用基于 ICMP 的工具

Windows XP 和 Windows Server 2003 的 Ping、Pathping 和 Tracert 都支持 IPsec，但在建立软 SA 之前（如果允许“回退到使用明文”），它们无法正常工作。 如果已成功地进行了 IPsec SA 协商以便对这些实用程序使用的 ICMP 通信流进行封装，它们就无法检测到客户端与目标之间的任何中间跃点（路由器）。 在 IKE 成功地与目标完成 IPsec SA 对协商所需的时间内，Ping 进行的数据包丢失计算可能会显示丢失数据包。 当 IPsec 对 ICMP 通信流进行了封装时，无法计算每个中间跃点的数据包丢失情况。

这些 ICMP 实用程序可以检测 IPsec 驱动程序是否已将 IPsec 筛选器与出站 ICMP 回应请求数据包相匹配，从而允许被请求的 IKE 协商安全性。 在协商安全性时，实用程序将显示消息“协商 IP 安全”。 Windows 2000 中的一项已知错误导致 Ping 实用程序不等待足够的时间就重新尝试下一个回应请求，这意味着命令可能立即完成，而不是等待 3 秒钟以便建立软 SA。 Windows XP 和 Windows Server 2003 中的 Ping 实用程序将先等待所需的秒数，然后再发送下一个回应请求。

在下列情况下，不会显示“协商 IP 安全”消息：

返回页首

IPsec 疑难解答过程

如果第 1 层支持已经清楚地标识了问题，则第 2 层支持将能够快速地在下列各节中找到相关疑难解答过程。 在此模型中，第 1 层支持主要处理与客户端相关的访问问题。 据预计，服务器的管理所有者能够执行基本的网络连接诊断并可以跳过第 1 层支持。 但是，每个组织都应该针对他们的支持环境来调整此模型。 第 2 层支持应该侧重于确定通信故障的发生位置，然后在系统体系结构中调查相关的可能性。

如果您的组织正在使用作为疑难解答过程一部分提供的脚本，则您可以使用许多文本日志文件，这些日志文件可以帮助您诊断问题。 下表对脚本生成的文件作了描述。

表 7.3：IPsec_Debug.vbs 脚本创建的文件

由于有许多潜在的故障发生点，所以，本节从网络连接开始按顺序阐述每个体系结构组件。 阐述的过程能够帮助您执行下列任务：

考虑以下示例方案：客户端报告能够 ping 服务器，但无法连接到该服务器上的文件共享。 这是该客户端无法访问的唯一服务器。 通过在安全日志中快速检查 547 事件（IKE 协商失败，此事件包含服务器的 IP 地址），发现客户端拥有 IPsec 策略，并且正在启动 IKE。 如果客户端事件 547 指示客户端 IKE 协商超时，则可能是服务器 IKE 导致协商失败。 于是，第 2 层支持在 MOM 事件数据库中检查从指定服务器收集的 547 事件，这些事件包含当前客户端 IP 地址。

警告 - 正在启动和正在停止 IPsec 服务

Windows Server 2003 TCP/IP 疑难解答文档和其他参考资料描述了如何通过停止 IPsec 服务来确定连接问题是否由 IPsec 引起。 虽然这将在计算机上停止 IPsec 筛选，但也将禁用 IPsec 提供的保护，使计算机暴露在不受信任的网络访问之下，并禁用了数据包保护功能。 并且，在域隔离环境中，未受 IPsec 保护的 TCP 和 UDP 通信流将被其他隔离域成员丢弃。 如果在一台计算机上禁用 IPsec，就会导致该计算机与那些当前建立了 IPsec 安全关联的远程计算机之间的连接中断。 停止 IPsec 服务时，IKE 将针对所有 IPsec SA 以及 IKE SA 发送删除通知给所有当前连接着的计算机。 具有允许“回退到使用明文”的 IPsec 策略的远程计算机将在 3 秒钟的延迟之后重新建立连接。 具有不允许“回退到使用明文”的 IPsec 策略的远程计算机将无法进行通信。

因此，使用下列各节讨论的技术来在不停止 IPsec 服务的情况下对隔离方案进行疑难解答是十分重要的。 禁用 IPsec 服务的方法只应该作为下列情况下的最后一种 IPsec 相关问题排除手段使用。

在 Windows 2000 中，停止 IPsec 服务将取消 IPsec 驱动程序与 TCP/IP 的绑定，并且将从内存中卸载 IPsec 驱动程序。

在 Windows XP 和 Windows Server 2003 中，停止 IPsec 服务将从 IPsec 驱动程序中删除所有筛选器并将驱动程序模式设置为 PERMIT。 而不会从内存中卸载 IPsec 驱动程序。 必须禁用 IPsec 服务，并且必须重新启动计算机才能避免加载 IPsec 驱动程序。

在 Windows 2000 和 Windows XP SP1 中，对 Oakley.log 文件进行的 IKE 记录要求重新启动 IPsec 服务。 在 Windows XP SP2 和 Windows Server 2003 中，不需要停止服务就可以启用和禁用对 Oakley.log 文件进行的 IKE 记录。 在 Windows XP SP2 中，最新的 Ipseccmd 更新提供了语法
ipseccmd set logike 和 ipseccmd set dontlogike，以动态地启用和禁用对 Oakley.log 文件进行的 IKE 记录。 可以使用 Netsh 命令来动态地启用 Windows Server 2003 IKE 记录，如联机帮助所述。

验证网络连接

如果第 1 层支持标识了可能的网络连接问题，则第一步是确定是否存在基本的网络连接问题。 此项确认工作包括验证所使用的 IP 配置是否正确、在发起方计算机与响应方计算机之间是否存在有效的网络路径以及名称解析服务的工作是否正常。

网络 IP 地址配置问题

如果动态 IP 配置不成功，或者通信在计算机重新启动后被阻止（甚至在正常操作期间被阻止），则 IPsec 可能是问题的根源。 在 Windows Server 2003 中，此类问题可能与 IPsec 防故障行为相关（例如，计算机是以安全模式或 Active Directory 恢复模式启动的）。

注：有关 Windows Server 2003 防故障行为的详细信息，请参阅 Windows Server 2003 部署工具包中“Deploying IPsec”中的“Understanding IPSec Protection During Computer Startup”，网址为 www.microsoft.com/resources/
documentation/WindowsServ/2003/all/deployguide/
en-us/dnsbj_ips.asp。

当 IPsec 服务无法成功地启动或者无法应用指派的策略时，Windows Server 2003 就会执行防故障行为。 仅当对计算机指派了 IPsec 策略并且 IPsec 服务未被禁用时，防故障操作才适用。 因此，在正常操作期间，计算机连接可能会由于 IPsec 驱动程序无法强制实施基于域的 IPsec 策略而发生故障。 在确定引导模式以及永久配置所允许以及所阻止的通信流之后，通信故障可能就很容易解释了。 要获取替代信息或补充信息，您可以使用以下语法来从命令行查询当前状态：

    netsh ipsec dynamic show config

对于 Windows Server 2003 来说，IPsec 驱动程序是在计算机启动时随 TCP/IP 驱动程序一起加载的。 因此，要删除 IPsec 驱动程序防故障行为，必须禁用 IPsec 服务并重新启动计算机。 前面引用的 IPsec 部署章节提供了建议的引导免除配置，从而免除入站远程桌面协议连接，这将确保当其他通信流被阻止时还能够对服务器进行远程访问。

在服务器和域隔离解决方案中，广播通信流和发往 DHCP 服务器的通信流被免除，以确保动态 IP 配置工作正常。 但是，免除列表必须手动维护并有可能会过时。 如果计算机无法获取正确的 DHCP 配置（例如，如果它使用自动配置 IP 地址 169.254.x.x）或者在更新租约时发生问题，您就应该检查 IPsec 策略以了解免除内容是否正确。 当 IPsec 服务正在运行时，使用 Ipconfig 来确认获取地址时未发生问题：

对于 Windows XP SP2 和 Windows Server 2003 来说，如果只有在计算机启动期间才会发生地址配置问题，则应该检查免除配置（默认免除和引导免除）。

名称解析问题

服务器和域隔离方案所使用的 IPsec 策略设计不应该影响用来确定名称解析是否工作正常的典型过程。 例如，在 Woodgrove Bank 方案中，IPsec 策略设计免除了所有发往 DNS 和 WINS 服务器的通信流。 但是，有可能 DNS 和 WINS 服务器已被配置为不对 Ping 请求作出响应。 回答下列问题以确认当 IPsec 服务运行时，名称解析的工作是否正常：

名称解析问题的可能原因包括活动 HOSTS 文件的配置有问题、IP 属性中的 DNS 服务器条目配置有问题、DNS 记录注册内容不正确、区域文件更新有问题、Active Directory 复制有问题、对 DNS 服务器使用了“回退到使用明文”以及 DHCP 自动更新有问题。

NetBIOS 名称解析故障的可能原因包括活动 LMHOSTS 文件的配置有问题、IP 属性中 WINS 服务器条目的配置有问题、WINS 服务器不可用、WINS 记录不正确、WINS 复制有问题、WINS 代理故障以及访问 WINS 服务器时发生网络超时。

要了解与 Active Directory 集成的 DNS 的疑难解答过程，请参阅 Microsoft.com 上的“Troubleshooting Active Directory - Related DNS Problems”页面，网址为 www.microsoft.com/technet/prodtechnol/
windows2000serv/technologies/activedirectory/
maintain/opsguide/part1/adogd10.mspx。

某些高度安全的环境可能要求使用 IPsec 来保护 DNS 和 WINS 服务器，这可能会引起名称解析问题。 例如，如果 DNS 集成在 Active Directory 中，并且 IPsec 策略包含用于同一 IP 地址的重复筛选器，则一个筛选器可能要与 DNS 服务器协商安全性，而另一个筛选器可能免除域控制器。 有关更多信息，请参阅本章随后的“IPsec 策略疑难解答”一节。

如果名称解析问题仍存在，则您可以获取发起方的筛选器列表并检查是否存在重复的筛选器。 对于本任务来说，您可以使用下列命令行选项来查看筛选器列表：

Ipseccmd show filtersNetsh ipsec static show all 

如果名称解析问题仍存在，则应该在重复名称解析测试时暂时停止 IPsec 服务（如有可能）。 如果仅当 IPsec 服务运行时名称解析测试才会失败，则您应该继续进行调查以确定正在应用哪个 IPsec 策略，如本节随后所述。

对域控制器验证连接和身份验证

由于 IPsec 策略传递、IKE 身份验证以及大部分上层协议都依赖于对域控制器的访问，所以，在执行 IPsec 专用疑难解答步骤（如下一节所述）之前，应该执行网络连接测试并测试身份验证服务的操作成功与否。 在诸如 Woodgrove Bank 之类的方案中，IPsec 策略设计免除所有发往域控制器的通信流，因此，对域控制器进行的网络连接测试应该不会受到 IPsec 的影响。 但是，免除列表中的域控制器 IP 地址列表必须手动维护。 如果 IKE 协商似乎是对域控制器 IP 地址进行的，则可能是不正确地指派了 IPsec 策略，或者是未更新 IPsec 策略。

对 Active Directory 网络服务访问进行疑难解答

您可以使用 Windows 支持工具 klist.exe 来验证 Kerberos 登录和身份验证成功与否。 必须在本地系统上下文中运行 Klist 才能查看计算机的 Kerberos 票证。

查看已登录的域用户的 Kerberos 服务票证

klist tickets

查看域计算机票证

at 4:38pm /interactive cmd /k klist tickets

虽然 Kerberos 票证包含用户或计算机的组信息，则此信息是加密的，因此无法查看组。 所以，必须通过在 Active Directory 中检查组成员身份来手动确认组成员身份。 要确保计算机的 Kerberos 票证包含最新的组成员身份信息，请使用 klist 来清除当前 Kerberos 票证。 当再次尝试进行 IKE 协商时，将自动获取新的 Kerberos 票证。

清除计算机的 Kerberos 票证

（步骤 1 至 4 必须在本地系统上下文中运行）

at 4:38pm /interactive cmd

下列白皮书发布了其他的 Kerberos 疑难解答详细过程：

在 Active Directory 中验证 IPsec 策略的权限和完整性

可能有必要在 Active Directory 中验证关于 IPsec 策略容器的信息。 以下过程使用支持工具 ldp.exe。

验证关于 IPsec 策略容器的信息

对于策略检索和损坏问题的高级疑难解答来说，ldp.exe 可用来手动检查 IP 安全容器的内容以及各个 IPsec 策略对象之间的关系。 Windows 2000、Windows XP 和 Windows Server 2003 使用同一种 IPsec 策略基本目录架构，如 Windows Server 2003“How IPsec Works”技术参考中的 IPsec 策略结构图所示，网址为 www.microsoft.com/resources/documentation/
WindowsServ/2003/all/techref/en-us/w2k3tr_ipsec_how.asp。

下表显示了 Active Directory 对象名称与 IPsec 策略管理 MMC 管理单元中配置的 IPsec 策略组件名称之间的关系：

表 7.4：IPsec 策略组件到 Active Directory 对象名称映射

Ldp.exe 能够标识 IPsec 策略对象的上次修改时间，这有助于对对象版本问题和复制问题进行疑难解答。 可以在本地系统的上下文中从命令窗口中启动此工具，以便对 IPsec 服务的读取权限问题进行疑难解答。

注意：强烈建议您让 IP 安全容器中的所有对象都具有相同的权限。 Microsoft 不建议对单个的 IPsec 策略对象设置权限。 要对 IPsec 策略的读取和修改访问权限进行控制，应该对 IP 安全容器本身管理权限，如知识库文章 329194“IPSec Policy Permissions in Windows 2000 and Windows Server 2003”所述，网址为 http://support.microsoft.com/?kbid=329194。

当 IPsec 对象包含对不再存在的对象的 DN 引用时，最常见的原因是 IPsec 策略已损坏。 但是，如果对象名称包含控制字符、由于权限问题而无法读取单个的对象或者完全相同的对象名称导致 IPsec 策略设计不正确（例如，存在同一筛选器列表的两个版本），也会发生损坏。 请参阅下面的“IPsec 服务”疑难解答部分以了解更多有关如何解决 IPsec 策略损坏情况的信息。

注：这些对象的设计细节被视为内部专用数据结构，Microsoft 未发布此信息。 在不同的 Windows 版本中，这些对象的格式是有区别的，并且 Microsoft 可能随时对这些格式进行更改。 因此，只应该使用各个平台提供的 IPsec 策略管理 MMC 管理单元和命令行工具来管理这些对象。 仅当损坏导致无法使用 IPsec 策略管理 MMC 管理单元或命令行工具时，您才应该使用 LDP 来删除这些对象，这是您的最后一个选择。

网络路径连接

Microsoft 建议在服务器和域隔离解决方案中免除 ICMP 协议。 提出此建议的原因有好几个，包括诸如 Ping、Pathping 和 Tracert 之类的实用程序需要使用 ICMP 来进行路径测试。 因此，这些实用程序应该正常地工作，并且不会显示“协商 IP 安全”消息。 如果显示了此消息，则表示可能指派了不正确的 IPsec 策略。

确定问题是否与基本网络配置或路径连接相关

使用 ICMP 时路径连接测试可能会成功，但使用 IKE 或 IPsec 协议时此测试可能会失败。 特别是，包含 Kerberos 票证的 IKE 主模式身份验证数据包的 IPsec 开销通常大于目标 IP 地址的 PMTU，这要求进行分段。 因此，基于主机的防火墙、路由器中的筛选、网络防火墙以及目标主机上的筛选器必须打开下列协议和端口并支持分段：

建议不要在路径中进行状态筛选

由于状态通常基于活动超时，因此状态筛选可能会导致 IKE、AH 和 ESP 出现连接问题。 因为 IKE 对 IPsec SA 删除消息进行了加密，所以设备无法检查 IKE 通信流以确定 IPsec SA 何时被删除。 根据定义，IKE 需能够在任何一个方向上重新生成密钥，这表示可能在任何一个方向上发送删除消息。 如果一端未接收到删除消息，它可能会相信 IPsec SA 对仍存在，而此时对等端已不再识别该 SA 并且将废弃那些使用该 SA 的数据包。 IKE 重新生成密钥的方向取决于更早地使基于字节的生存期过期的通信流方向、基于时间的生存期过期时重新生成密钥的小幅偏移以及空闲 IPsec SA 被删除后的数据包流方向。 在发起连接（并因而发起 IKE 协商）的客户端上通过 Windows 防火墙进行的基于主机的 IKE 通信流状态筛选通常不会引起问题。 由于 IPsec 驱动程序处理数据包所在的层低于执行防火墙筛选所在的层，因此 Windows 防火墙不对 IPsec 数据包进行筛选。 但是，在主机防火墙中应该将 IKE 端口配置为打开，以便接收被允许通过防火墙的上层协议连接的传入 IKE 协商（例如，对于使用 SMB 协议通过 TCP 端口 445 进行的文件共享）。

对 TCP 所需的 ICMP PMTU 的支持

在 Windows 2000 及更新版本中，每个 TCP 数据包的默认设置是在 IP 标头中设置“Don't Fragment”位。 当使用 AH 或 ESP IPsec 传输模式来保护数据包时，仍使用此设置。 因此，在路由器上，太大的数据包将被丢弃，路由器应该返回“ICMP Destination Unreachable”消息，此消息指定了所允许的最大大小。 这种行为称为“TCP 路径 MTU 发现”。 客户端和目标计算机都必须能够接收针对太大的 IPsec 数据包发送的 ICMP PMTU 消息。 由于硬件加速通常不处理分段的数据包，因此，对于受 IPsec 保护的通信流来说，避免分段特别重要。 分段的 IPsec 数据包必须由软件中的 IPsec 驱动程序处理。

Windows 2000 和 Windows XP 不支持为使用 NAT 遍历封装（UDP 端口 4500）的 IPsec 传输模式数据包执行 ICMP PMTU 发现处理。 Windows Server 2003 不支持此项发现处理。 有关在不进行 PMTU 发现的情况下可使用的选项和工具，请参阅 Windows Server 2003 联机文档“TCP/IP Troubleshooting”部分中的“Troubleshooting Translational Bridging”页面，网址为 www.microsoft.com/resources/documentation/Windows/
2000/server/reskit/en-us/cnet/cnbd_trb_gdhe.asp。

注：在 NAT 外部的主机对 NAT 背后的主机发起 IPsec UDP-ESP 连接的 NAT 遍历方案中，有一个已知问题，即必须启用 TCP PMTU 检测才能让 IPsec 保护通信流。 如果需要使用此方案，则通过确保未定义以下注册表项或者在两端都将此项设置为 1，确认已启用 TCP PMTU 检测：
    HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Tcpip/
    Parameters/EnablePMTUDiscovery=1
    （此项可能显示成多行；在注册表中，此项是在一行上的。）
Microsoft Windows Server 2003 成员服务器基准安全策略模板和其他第三方配置可能会配置此注册表项以禁用 TCP PMTU。

分段所需的支持

网络路径和筛选器必须支持为 IKE、IPsec、AH 和 ESP 协议传递片段。 IKE 使用 UDP 数据包并允许根据需要对它们进行分段。 IPsec NAT 遍历实现添加了对避免进行 IKE 分段的支持，但此项支持只有在使用证书进行 IKE 身份验证时（例如在 L2TP/IPsec VPN 方案中）才有效。 使用 Kerberos 的 IKE 身份验证不支持避免进行分段，并且必须能够发送和接收包含 Kerberos 票证的分段 UDP 数据包。

由于 IPsec 在 IP 层进行出站分段之前对整个原始 IP 数据包进行保护，所以网络路径必须支持传递 AH 和 ESP 片段。 IPsec 与 TCP 集成，因此，当 TCP 数据包设置了 DF（不分段）标志时（默认设置），TCP 将减小数据包大小以适应由于进行 IPsec 封装而增加的字节。

IPsec 未与 UDP 集成，UDP 应用程序无法检测 IPsec 是否对它的通信流进行了保护。 因此，当应用了 IPsec AH 或 ESP 时，主机在发送 UDF 数据包时将对具有完整 MTU 大小的 UDP 数据包进行分段。 同样，如果 IPsec 策略筛选器未免除 ICMP，则使用 Ping 实用程序时可能会产生在线路上表现为分段 IPsec AH 或 ESP 数据包的 ICMP 数据包。

有关更多信息，请参阅 Microsoft 知识库文章 233256“如何使 IPSec 通讯能够通过防火墙”，网址为 http://support.microsoft.com/?kbid=233256。

广播或多播通信流所需的支持

服务器和域解决方案的 IPsec 策略设计使用“任何 IP 地址 <-> 子网”筛选器。 因此，出站筛选器“子网 -> 任何 IP 地址”将与从使用内部子网 IP 地址的主机发送的出站广播和多播通信流匹配。 但是，由于 IPsec 无法保护多播或广播通信流，所以如果与筛选器相匹配，它必须丢弃这样的通信流。 入站多播和大多数类型的广播将与相应的“任何 IP 地址 -> 子网”入站筛选器不匹配。 如果多播或广播通信流是必需的，则您可以设置注册表项 NoDefaultExempt=1，这允许多播和广播通信流绕过 Windows XP 和 Windows Server 2003 中的 IPsec 筛选。 此项配置能够预防实时通讯 (RTC) 客户端和 Windows Media Server 的一些已知问题，它们都使用多播通信流。 有关 NoDefaultExempt 注册表项的用法以及安全含义的详细信息，请参阅下列知识库文章：

在所有平台上都可以根据需要设置注册表项，以便控制默认免除。 IPsec 筛选不支持为特定广播地址或多播地址配置目标地址。

在网络设备中的诊断可能没有用

使用 IPsec 封装的其中一个影响是：假定 TCP/IP 通信流是明文形式的应用程序不能再检查网络中的通信流。 根据 TCP 和 UDP 端口来进行检查或提供报告的网络诊断工具不大可能拦截 IPsec 封装的数据包，即使未使用 AH 或 ESP 加密亦如此。 您可能需要请求供应商提供此类工具的更新以检查 IPsec AH 数据包或 ESP-null 数据包。

网络接口卡和驱动程序问题

IPsec 数据包丢失有时是由执行特殊功能的网络接口卡 (NIC) 导致的。 您应该对执行群集或“分组”的网络接口卡进行测试以了解它们是否兼容 IPsec。 对非 IPsec 功能进行加速的 NIC 驱动程序在处理受 IPsec 保护的通信流时可能会发生问题。 能够对 TCP 功能进行加速的 NIC 可能支持 TCP 校验和计算及验证 (checksum offload)，并能够有效地发送大型 TCP 数据缓冲区 (large send offload)。 Windows 2000 和更新版本在 IPsec 驱动程序包含筛选器时将自动禁用 TCP/IP 堆栈中的这些 TCP offload 功能，即使 IPsec 只执行允许和阻止功能亦如此。 当使用 IPsec 来保护通信流时，未经 Windows 硬件质量实验室 (WHQL) 验证和签署的网卡驱动程序可能会发生问题。 WHQL 执行一组广泛的测试来验证 NIC 驱动程序是否能够支持 IPsec offload。 为了帮助进行疑难解答，Windows 2000、Windows XP 和 Windows Server 2003 TCP/IP 堆栈支持使用一个注册表项选项来禁用所有形式的 TCP/IP offload。 某些 NIC 驱动程序还支持使用网络连接的“高级”属性禁用 offload。 要使驱动程序级别的配置更改生效，可能需要重新启动计算机。

对 IPsec 协议数据包丢失问题疑难解答

数据包可能会被丢弃，也可能会丢失，这会影响应用程序的连接。 本节阐述 IPsec 丢弃数据包的常见情况。 如上所述，某些网络设备可能不允许 IP 协议类型 50/51 或者 UDP 端口 500/4500 通行。 同样，IPsec 封装的数据包可能导致某些数据包分段并且无法通过网络发送。 在此类情况下，通常需要在通信两端进行网络监视跟踪以标识所发送的数据包以及所接收的数据包并使它们相关联。 您应该查找由重复出现的具有相同大小的数据包所指示的重新传送情况。 您可能需要捕获未使用 IPsec 时的典型协议行为跟踪，然后将其与受 IPsec 保护的通信流的协议行为进行比较。

事件错误 4285

事件标题：哈希身份验证失败

IKE 和 IPsec 保护数据包在通过网络传输时不会被修改。 如果某个设备修改了受完整性哈希保护的数据包的一部分，接收 IKE 或 IPsec 驱动程序就会丢弃此数据包并产生“哈希身份验证失败”错误，此错误作为事件 4285 记录在系统日志中。 经验表明，某些设备、网络驱动程序和第三方数据包处理程序偶尔会破坏具有特定大小的数据包、具有特定数目分段的数据包或具有特定协议类型的数据包，或者会在某些情况下（例如当设备拥塞、监视数据流或重新启动时）破坏数据包。 此错误也可能表示数据包被恶意应用程序或未意识到该数据包受保护的应用程序攻击。 此错误也可能指示拒绝服务攻击。

要检测被破坏的 IPsec 数据包的丢弃情况，可以使用下列技术。 但是，重要的是使这些观察结果与网络监视跟踪相关联以便能够找到造成损坏问题的原因。

虽然此事件文本指出重新启动 IPsec 服务可能解决问题，但是，大部分数据包丢失问题并不是由 IPsec 系统造成的。 重新启动 IPsec 服务不仅无法解决问题，而且还会引起更多的问题。 在确定问题是否与 IPsec 相关的过程中，停止 IPsec 服务只应该作为最后的手段使用。

要解决此错误，需要进行调查，以确定源 IP 地址的模式、当日时间、适配器或者错误发生的条件。 如果数据包数目较小，可能不必调查此错误。 重要的是从尝试排除本地系统上的数据包损坏根源入手。 禁用 IPsec offload，尝试使用“高级属性”提供的配置来禁用驱动程序的高级功能或性能，并使用供应商提供的最新 NIC 驱动程序，最好是使用 Windows 硬件质量实验室已验证并签署的驱动程序。 然后，调查传输数据包的网络路径的特征。 在 TCP/IP 数据包丢弃统计信息中以及在其他使用同一配置的计算机上查找其他数据包损坏证据。 IPsec 每次丢弃数据包时，“Datagrams Received Discarded”的 IP 计数器都会增加。

注意：要禁用 TCP/IP offload 功能，请在运行 Windows 2000、Windows XP 或 Windows Server 2003 的计算机上使用以下注册表项：
    HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/IPSEC/
    EnableOffload DWORD registry value to 0
    （此项可能显示成多行；在注册表中，此项是在一行上的。）
然后重新启动计算机。

事件错误 4268

事件标题：接收到带有不正确的安全参数索引 (SPI) 的数据包

IKE 的 Windows 2000 和 Windows XP（包括 SP1）实施具有一个已知问题，该问题将导致数据包在特定条件下会丢失。 在 Windows Server 2003 和 Windows XP SP2 中已解决了此问题。 由于各种协议已预期某些数据包会由于各种其他原因而丢失，所以，此问题对上层协议通信的影响通常可以忽略不计。 此问题由下列问题印证：

虽然此事件文本指出重新启动 IPsec 服务可能解决问题，但是，此类数据包丢失问题是由 IPsec 系统的设计引起的。 重新启动 IPsec 服务不仅无法解决问题，而且还会引起更多的问题。 如上所述，在确定问题是否与 IPsec 相关的过程中，停止 IPsec 服务只应该作为最后的手段使用。

IPsec 安全参数索引 (SPI) 是数据包中的一个标签，它告诉响应方应该使用哪个安全关联来处理该数据包。 如果某个 SPI 不被识别，它就被称为“错误 SPI”。此错误表明接收计算机接收到 IPsec 格式的数据包，但该计算机没有用于处理那些数据包的 IPsec SA。 因此，该计算机必须丢弃那些数据包。

尽管数据包被丢弃了，但这些错误消息是良性的。 生成的错误 SPI 事件的数目取决于计算机当时的繁忙程度以及重新生成密钥时传输受 IPsec 保护的数据的速度。 在下列情况下，有可能生成较多的此类事件：

产生的影响是，受 IPsec 保护的 TCP 连接的速度将降低几秒钟以便重新传输丢失的数据。 如果有若干个数据包丢失，则 TCP 在该连接上将进入拥塞避免模式。 几秒钟后，该连接的速度应该恢复正常。 文件复制、Telnet、终端服务器和其他基于 TCP 的应用程序应该不会发生这种少量丢失数据包的情况。 但是，在某些情况下，TCP 在快速链路上会丢失大量数据包并且必须重置连接。 重置连接时，套接字将关闭，应用程序将接收到连接中断通知，这可能会中断文件传输。

此错误的最常见原因是 Windows 2000 中的一个已知问题，该问题与 IKE 同步 IPsec SA 密钥的方式相关。 当 IKE 快速模式发起方比响应方速度快时，发起方发送新的受 IPsec SA 保护的数据包的速度可以会导致响应方来不及接收那些数据包。 正如 Internet 工程任务组 (IETF) IPsec 请求注释 (RFC) 中所指定的那样，当 IKE 建立新的 IPsec 安全关联对时，发起方必须使用新的出站 IPsec SA 来传输数据，低速响应方将接收到它还不识别的受 IPsec 保护的通信流。 由于 IKE 重新生成密钥既依赖于已用时间也依赖于在 IPsec SA 保护下发送的数据量，因此，您可能会定期看到不正确的 SPI 事件（尽管时间间隔并不一定固定不变）。

在第三方客户端互操作方案中，不正确的 SPI 错误可能表示 IPsec 对等端未接受并处理删除消息或者在完成 IKE 快速模式协商的最后一步时发生问题。 此错误也可能表示攻击者正在使用欺骗的或注入的 IPsec 数据包来淹没计算机。 IPsec 驱动程序对这些事件计数，并记录它们以记录不正确的 SPI 活动。

可以使用 LogInterval 注册表项来调查这些事件并将它们的数目降至最低。 在进行疑难解答时，请将其设置为最小值（每隔 60 秒），从而快速地记录事件。 在 Windows 2000 中，您可以停止并重新启动 IPsec 策略代理服务以重新加载 IPsec 驱动程序。 在 Windows XP 和 Windows Server 2003 中，必须重新启动计算机以重新加载 TCP/IP 和 IPsec 驱动程序。

在 Windows 2000 中，无法通过任何当前可用的注册表项设置或修补程序来消除这些事件。 Windows XP 和 Windows Server 2003 中的默认设置是不报告这些事件。 通过 netsh ipsec 命令行选项使用 IPsecDiagnostics 配置或者直接通过注册表项允许报告这些事件。

下列技术有助于最大程度地减少此类错误：

如果这些选项不起作用，并且不可能升级到 Windows XP SP2 或 Windows Server 2003，请与 Microsoft 产品支持服务联系以了解当前是否有其他选项可供选择。

事件错误 4284

事件标题：应该对明文数据包进行保护

此事件表示在接收到应该包含在 IPsec 安全关联中的明文数据包时，建立了 IPsec 安全关联。 为了预防受 IPsec 保护的连接上的数据包注入攻击，将丢弃这些数据包。 虽然“Datagrams Received Discarded”的 IP 计数器将增大，但是 IPsec 并没有计数器值用于记录由于此原因而丢弃的数据包。 此问题只能由系统日志中的错误事件 4284 标识，该事件的文本如下所示：

“从应当有安全措施的 <IP 地址> 上接收的 <数目> 数据包。

这可能是临时的问题；如果问题持续存在，请停止并重新启动此机器上的 IPSec 策略代理服务。”

对于上述错误，您不应该按照事件提供的建议执行操作。 重新启动 IPsec 服务不大可能更正错误。

此错误最有可能是由策略配置问题引起的，该问题导致通信的一端由于更特定的出站允许筛选器而以明文方式发送通信流。 例如，如果客户端有一个筛选器来保护它与服务器之间的所有通信流，并且服务器策略有一个更特定的筛选器来允许明文 HTTP 答复，则服务器将对它与客户端之间除出站 HTTP 数据包以外的所有通信流进行保护。 由于客户端期望它与服务器之间的所有通信流都在 IPsec SA 对中受保护，所以客户端接收到这些数据包后将丢弃这些数据包以确保安全。

此事件也可能在常规操作期间发生，此外，在第三方客户端互操作期间，如果一个对等端在两台计算机之间正有通信流流动时删除了 IPsec 安全关联或 IPsec 驱动程序中的筛选器，也会发生此事件。 例如，一端可能取消指派了 IPsec 策略，或者可能遇到了删除 IPsec SA 和筛选器的策略更新。 由于某个对等端在活动的上层协议通信进行过程中删除了筛选器，所以 IKE 删除消息在明文数据包到达之前不会到达，并由其他对等端处理，这将导致错误。 并且，处理删除消息所需的时间量取决于对等计算机上的当前负载。

此错误消息也可能会在大型策略加载期间出现，这是因为整套筛选器被应用到 IPsec 驱动程序之前会建立 IPsec 安全关联。 如果发生这种情况，就可能会为策略加载完成后将被免除的通信流协商 IPsec SA。

此错误消息也可能表示发生了注入攻击，即发送的明文通信流与特定活动入站安全关联的通信流选择器匹配（故意或意外）。

应该将此问题汇报给 IPsec 策略设计者。

当通过无线网络进行连接时，IPsec NAT-T 超时

最近发现一个问题，当基于 Windows Server 2003 或 Windows XP 的客户端计算机尝试通过使用 IPsec NAT-T 的无线网络连接至服务器时，会发生连接超时。 有关更多信息，请参阅 Microsoft 知识库文章 885267，网址为 http://support.microsoft.com/?kbid=885267。

验证 IPsec 策略是否正确

本节描述检测 Ipset 策略指派和解释问题的步骤。 IPsec 驱动程序必须包含被正确解释的 IPset 策略的筛选器，这样 IPset 才能允许和阻止数据包以及触发 IKE 与远程 IP 地址协商 IPset SA 以保护通信流。 还必须要有适当的筛选器来引导 IKE 作为响应方。 在此解决方案中，IPsec 策略设计要求所有通信流（ICMP 除外）都受 IPsec 保护。 此策略还包含用于免除列表中的每个 IP 地址的筛选器。

注：在 Windows 2000 中，IPsec 服务被称为“IPsec 策略代理”；在 Windows XP 和 Windows Server 2003 中，此服务被称为“IPsec 服务”。

支持工程师必须熟悉 IPsec 对组策略的使用、IPsec 策略优先顺序以及 IPsec 策略解释。 您可以在本章末尾的“更多信息”一节中找到有关这些主题的参考信息。

IPsec 组策略疑难解答

组策略提供了用于对域成员指派基于域的 IPsec 策略的机制。 域成员检索已指派的 GPO 指的就是将 IPsec 策略指派传递给主机。 因此，GPO 检索期间发生的任何问题都将导致计算机无法应用正确的 IPsec 策略。 在 IPsec 策略管理方面，组策略的常见问题包括：

由于 Active Directory 包含大量与 IPsec 相关的对象（如 IPsec 策略、GPO、GPO IPsec 策略指派与 IPsec 策略的属性更改以及安全组成员身份信息），所以复制可能会延迟。 您必须进行仔细的规划以评估 IPsec 配置更改对域成员逐渐产生的影响。

要了解组策略疑难解答过程，请参阅下列白皮书：

基于域的 IPsec 策略指派是由两个组件实现的：

IPsec 策略管理 MMC 管理单元通过将选择的 IPsec 策略信息存储在 GPO 的 IPsec 组件中来对该 GPO 指派策略，该组件是通过以下 LDAP 可分辨名称 (DN) 引用的：

CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID},
CN=Policies,CN=System,DC=domain,DC=Woodgrove,DC=com

所指派的 IPsec 策略的 LDAP DN 存储在 GPO 属性 ipsecOwnersReference 中。

当组策略检索应用于计算机的 GPO 列表时，包含 IPsec 策略指派的 GPO 存储在注册表中 IPsec 客户端扩展的 GUID 下面，位置如下：

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft
/Windows/CurrentVersion/Group Policy
/History/{e437bc1c-aa7d-11d2-a382-00c04f991e27}

无论何时 GPO 中存在 IPsec 策略指派时，安全策略 CSE 都会激活 IPsec CSE。 如果处理安全策略时发生问题，则处理 IPsec 策略时也可能会发生问题。 要找到每个组策略扩展的 GUID，请在注册表的以下位置下方查找：

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft
/WindowsNT/CurrentVersion/WinLogon/GPExtensions

组策略 CSE 的与 IPsec 部署相关的 GUID 如下所示：

IPsec CSE 复制以下注册表项中的 LDAP DN 以及有关已指派的 IPsec 策略的相关信息：

HKEY_LOCAL_MACHINE/SOFTWARE/Policies/Microsoft/Windows/
IPSec/GPTIPSECPolicy

如果有多个 GPO 包含 IPsec 策略指派，则针对每个 GPO 都调用一次 IPsec CSE。 GPO 优先顺序规则适用于 IPsec CSE 检索所要处理的 GPO 的顺序。 此顺序也可能受 GPO 本身的设置以及用于防止某些已指派的 GPO 被检索的“读 ACL”的影响。 IPsec CSE 每次被调用时，GPO 中与 IPsec 相关的信息（包括 DN）都将被覆盖到这个注册表项。 在处理所有 GPO 完毕之后，CSE 就通知 IPsec 服务已指派基于域的 IPsec 策略。 然后，IPsec 服务读取 GPTIPsecPolicy/DSIPSECPolicyPath 值以检索正确的 IPsec 策略。

IPsec 服务继续根据任何已指派的 IPsec 策略目录对象的上次更新时间来轮询已指派的 IPsec 策略的更改。 IPsec 服务将缓存的 IPsec 策略作为最新的域策略进行维护。

存在一个已知的问题，该问题允许已指派的 IPsec 策略的名称与实际使用（并缓存）的 IPsec 策略的名称不同步。 IPsec 服务不更新 GPTIPsecPolicy 注册表项中的信息，如 DSIPSECPolicyName，并且 IPsec 策略的名称只有在 IPsec CSE 被调用时才会更改。 但是，除非 GPO 中的 IPsec 策略指派 DN 属性发生更改，否则 IPsec CSE 不会被调用。 IPsec 监视器 MMC 管理单元和命令行工具使用此注册表值来报告当前已指派的 IPsec 策略的名称。 因此，IPsec 工具可能报告 CSE 上次处理的 IPsec 策略名称，而不是当前使用中的 IPsec 策略名称。 此错误有几种变通办法；有关更多信息，请参阅本指南第 5 章“为隔离组创建隔离策略”中的“确定策略版本”一节。

注：Microsoft 建议 IPsec 策略命名约定在名称中包括版本号，以便可以方便地找到当前应用的策略版本。 否则，如果策略名保持相同，就不可能方便地检测到版本更改。

如果未指派正确的 IPsec 策略，即使在强制刷新组策略之后，Userenv 或 SceCli 产生的应用程序日志错误也将指示组策略处理有问题。 必须启用组策略记录功能以便更详细地调查此问题。 有许多不同类型的组策略日志和记录级别。 为了查看任何错误处理安全策略以及 IPsec CSE 报告的任何错误，安全 CSE 的日志是必需的。 IPsec CSE 没有专门的日志。 可能需要执行网络监视器跟踪以捕获刷新组策略时的通信流，从而确认检索每个对象时使用的域控制器 IP 地址。 问题可能包括：

要为安全 CSE 创建详细的日志文件，请使用以下注册表项：

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft
/WindowsNT/CurrentVersion/CurrentVersion/Winlogon
/GpExtensions/{827d319e-6eac-11d2-a4ea-00c04f79f83a}/

将 ExtensionDebugLevel 条目设置为 REG_DWORD 值 0x2。

创建的日志文件位于 %windir%/Security/Logs/Winlogon.log。

注：无效的 DNS 条目可能表示未从 Active Directory 下载组策略，即使计算机和用户登录成功亦如此。 有关 DNS 问题的更多信息，请参阅前面的“名称解析问题”一节。

IPsec 服务疑难解答

您不需要运行 IPsec 服务就可以使用 IPsec 策略管理 MMC 管理单元。 但是，如果管理员接着指派了本地策略，则“策略已指派”列将显示错误。

下列常见问题会导致 IPsec 服务在启动期间发生故障：

Windows 2000 IPsec 实施使用一个称为 IPsec 策略存储的模块 (polstore.dll)，因此 IPsec 策略代理和 IPsec 策略管理 MMC 管理单元可以使用一个模块来访问全部三个受支持的策略存储位置：本地计算机、远程计算机和 Active Directory。 在 Windows XP 和 Windows Server 2003 中，此设计已改变并作了改进，添加了新的 IPsec 策略类型（启动策略和永久策略）以及安全策略数据库 (SPD) 组件，此组件为 IPsec 监视器查询和 IKE 查询维护 IPsec 策略的运行时状态。 此项体系结构更改意味着 Windows 2000 中记录的 IPsec 事件的文本在 Windows XP 和 Windows Server 2003 中已改变。 此项体系结构更改还意味着必须对用于进行远程管理的 RPC 接口进行大量的更改。 对于 Windows Server 2003 来说，RPC 接口已再次进行了重大更新。 因此，IPsec 策略管理 MMC 管理单元无法连接至未安装相同操作系统版本的远程计算机。 此外，Windows XP SP2 和 Windows Server 2003 SP1 的安全模型已作了根本更改，以便限制远程 RPC 连接并且在默认情况下激活 Windows 防火墙。 有关更多信息，请参阅“Microsoft Windows XP Service Pack 2 中的功能变更 - 第 2 部分：网络保护技术”，网址为 www.microsoft.com/technet/prodtechnol/winxppro/
maintain/sp2netwk.mspx。

由于进行了这些更改，作为一项安全措施，IPsec 服务的远程 RPC 接口已被禁用。 因此，IPsec 监视器和 IPsec 策略管理 MMC 管理单元将无法在这些计算机上执行远程监视。 IPsec 的远程管理应该使用远程桌面（终端服务器）连接执行，这些连接将 IPsec MMC 管理单元作为本地进程执行。

在 Windows 2000 中，IPsec 驱动程序在默认情况下是在启动过程结束时由策略代理服务加载的。 在策略代理第一次将活动策略通知 IPsec 驱动程序之前，IPsec 驱动程序不参与 IP 数据包处理。 如果没有活动的 IPsec 策略，则 IPsec 驱动程序不参与入站和出站 IP 通信流处理。 在 Windows XP 和 Windows Server 2003 中，此设计已作了改进，因此 IPsec 驱动程序是在启动过程中由 TCP/IP 驱动程序加载的。 IPsec 驱动程序在它拥有由 IPsec 服务加载的筛选器之前不处理数据包。

在 Windows 2000 中，IPsec 策略代理可能会因为服务启动问题而记录错误。 这些错误包括：

在 Windows XP 和 Windows Server 2003 中，下列 IPsec 服务错误事件表示该服务无法启动：

IPsec 策略检索疑难解答

在所有平台上，IPsec 服务都使用经过身份验证并经过加密的 TCP LDAP 查询来下载已指派的 IPsec 策略。 使用 Kerberos 会话密钥进行 LDAP 签名和密封时有一些选项。 因此，作为本地系统运行的 IPsec 服务必须能够获取 Active Directory 服务器上 LDAP 服务的 Kerberos 服务票证。 如果确认 IPsec CSE 已将正确的已指派 IPsec 策略存储在 GPTIPsecPolicy 注册表项下面，并且 IPsec 服务正在运行，则下列问题可能导致 IPsec 服务无法从 Active Directory 中检索策略：

当管理 Active Directory 中的或远程计算机上的 IPsec 策略时，IPsec 策略管理 MMC 管理单元有一个已知问题。 如果 MMC 管理单元是通过低速链路运行的，它可能需要花费一些时间来保存对大型策略所作的所有更改。 如果关闭 MMC 管理单元窗口，则任何尚未保存的 IPsec 策略对象或更改都将丢失。 此功能可能导致 IPsec 策略损坏。 如果 IPsec 策略管理 MMC 管理单元是通过低速链路运行的，请使用远程桌面会话来以本地进程方式执行该管理单元。

一般来说，应该对所有创建 IPsec 策略的命令行工具脚本进行测试。 要完成此任务，请在本地存储库中创建策略并使用 IPsec 策略管理 MMC 管理单元来查看该策略以验证其完整性。 测试计算机应该应用本地 IPsec 策略并在 IPsec 监视器 MMC 管理单元中检查详细信息以确认筛选器顺序合乎预期。

IPsec 策略读错误和损坏问题的疑难解答和解决过程取决于存储位置。 此解决方案仅使用基于域的 IPsec 策略，但可能已经以引起问题的方式配置了其他类型的 IPsec 策略。

本节余下内容阐述了每种策略类型的疑难解答过程。 通常，第 2 层支持应该能够使用命令行工具或 GUI 工具来确认检索的是正确的 IPsec 策略并且该策略被正确的解释。 这里显示了删除每种类型的策略的步骤，并且期望策略刷新能够干净地安装正确的策略。 如果似乎未从脚本检索或安装正确的策略，则应该将问题汇报给第 3 层支持。

启动 IPsec 策略

Netsh 实用程序仅允许配置受 Windows Server 2003 支持的 bootmode 和 bootexemptions 选项。 此配置存储在以下注册表项中，下面提供了默认值：

默认的 OperationMode 值要求 IPsec 驱动程序对出站通信流执行状态筛选。 如果 IPsec 服务正在运行，请使用
Netsh ipsec dynamic show config 命令来显示启动配置。 如果 IPsec 服务未运行（例如，当以安全模式启动时），可使用注册表工具来检查和更改注册表项值。

要对 IPsec 状态筛选在启动期间可能导致的通信流问题进行疑难解答，请将 IPsec 驱动程序设置为在启动期间允许通信流，而不是执行状态筛选。 如果 IPsec 服务正在运行，则使用
netsh ipsec dynamic set config bootmode value=permit 将启动模式设置为允许。 如果 IPsec 服务未运行，请使用注册表工具来更改 OperationsMode=1（表示允许）。 此外，如果 IPsec 服务已被配置为手动启动或者被禁用，则 IPsec 驱动程序就不应用启动安全模式。 在将 IPsec 服务配置为手动启动或者将其禁用之后，请重新启动计算机以使 IPsec 驱动程序以允许模式加载。

永久 IPsec 策略

永久策略受 Windows XP 和 Windows Server 2003 支持。 在定义新的永久策略之前未删除现有的永久策略，并且新策略与已指派的其他设置有冲突时，会发生一种常见的错误情况。 本指南描述的解决方案未使用永久策略。 但是，由于在某些环境下可能会使用永久策略，所以本章提供了疑难解答说明。

默认情况下，永久策略注册表项存在并且是空的：

HKEY_LOCAL_MACHINE/SOFTWARE/Policies/Microsoft/Windows/
IPSec/Policy/Persistent

在 Windows XP 中，检测永久策略的最佳方法是查看此注册表项不是空的。 ipseccmd show 命令报告 IPsec 服务中包含的活动策略，但不报告源于永久策略的特定设置。 IPsec 服务在将策略解释成活动设置时，它不考虑永久策略规则的名称。 由于 ipseccmd 未提供筛选器及筛选器操作的名称，所以不能使用命名约定来指示源于永久策略的筛选器和筛选器操作。 无论何时 ipsecpol.exe 或 ipseccmd.exe 创建筛选器，它们均具有“text2pol{GUID}”样式的名称，这包括永久策略的条目。 但是，使用脚本创建的本地策略或域策略也具有这样的名称。

永久策略首先被应用并与本地或域 IPsec 策略合并。 因此，仅当未应用任何本地策略和域策略时，才能查看永久设置。 在 IPsec 服务启动后，使用 ipseccmd show all 显示所有活动策略，包括所有永久设置。

要删除与特定永久策略相关联的所有对象（规则、筛选器列表和筛选器操作），请在以下命令中指定永久策略名称：

ipseccmd.exe -w PERS -p "policy name" –o

确保删除所有永久策略的最简单方法是删除 Persistent 注册表项下面的所有子项。 但是，如果删除 Persistent 注册表项本身，将来执行的 ipseccmd 命令在尝试创建永久策略时就会失败。 要解决永久策略损坏和策略冲突问题，请删除永久策略存储库中的所有对象并再次执行 ipseccmd 脚本以创建该策略。

在 Windows Server 2003 中，永久策略具有与本地或域 IPsec 策略相类似的全面管理能力。 永久策略存储在前面提到的注册表位置中。 以下 Netsh 命令脚本将通过使用 show_persistent.netsh 文件中的命令来显示已配置的永久策略：

    Netsh –f show_persistent.netsh 

show_persistent.netsh 文件是一个文本文件，它包含下列各行：

Pushd ipsec staticSet store persistentshow allexit

可使用以下 Netsh 命令脚本来删除所有永久策略：

pushd ipsec staticset store persistentdelete allexit

本地 IPsec 策略

本地 IPsec 策略受 Windows 2000、Windows XP 和 Windows Server 2003 支持并存储在以下注册表项下面：

HKEY_LOCAL_MACHINE/SOFTWARE/Policies/Microsoft/Windows/
IPSec/Policy/Local

如果已指派本地策略，则指派的策略将按以下方式存储在注册表项中：

HKEY_LOCAL_MACHINE/SOFTWARE/Policies/Microsoft/Windows/
IPSec/Policy/Local/ActivePolicy

如果未指派域策略，则指派的本地策略将被添加到任何已配置的永久策略中以成为活动策略。 为了显著降低疑难解答难度，应该使用 IPsec 策略管理 MMC 管理单元来编辑由 ipsecpol 或 ipseccmd 脚本创建的 IPsec 策略，以便为每个筛选器定义筛选器名称之后，才在生产环境中使用它们。 此外，可以使用 netsh ipsec 命令在基于 Windows Server 2003 的计算机上创建策略，并将该策略导出到一个文件中，在对该策略进行测试后，可以在基于 Windows 2000 和 Windows XP 的计算机上导入该文件或者将其导入到域中。

在 Windows 2000 中，使用 netdiag /test:ipsec /debug 命令来查看指派和活动策略详细信息。 应该使用 IPsec 策略管理 MMC 管理单元或注册表工具来删除本地存储库中的 IPsec 策略对象。 要强制重新加载已指派的 IPsec 策略，请停止并重新启动 IPsec 服务。

在 Windows XP 中，使用 ipseccmd show gpo 或 netdiag /test:ipsec 命令查看指派和活动策略详细信息。 使用 IPsec 策略管理 MMC 管理单元、注册表工具或
ipseccmd.exe -w REG -p "<policy_name>" –o 命令来删除指定的 IPsec 策略。 为了方便地删除所有本地策略，请删除前面提到的存储位置中的所有子项。

要强制 IPsec 服务重新加载策略，请使用 IPsec 策略管理 MMC 管理单元来停止并重新启动 IPsec 服务，或者取消指派并接着重新指派 IPsec 策略。 也可以使用 sc policyagent control 130 命令重新加载策略。 重新加载策略时，将删除所有 IPsec 和 IKE SA，这可能会导致您与当前正在使用 IPsec SA 传输和接收通信流的计算机之间出现连接延迟或中断。

在 Windows Server 2003 中，使用
netsh ipsec static show gpoassignedpolicy 命令、IPsec 策略管理 MMC 管理单元或 IPsec 监视器活动策略节点来显示当前已指派的本地策略。

使用 netsh ipsec dynamic show all 命令查看当前活动策略配置。 此外，可以使用 IPsec 监视器来检查活动策略的不同部分。

要在 Windows Server 2003 上删除并重新加载本地策略，请使用为 Windows XP 列出的那些命令。 可以使用 netsh ipsec 命令取消指派、重新指派和删除策略。

Active Directory IPsec 策略

此策略受 Windows 2000、Windows XP 和 Windows Server 2003 支持。 已指派的域 IPsec 策略存储在本地注册表中，位置如下：

HKEY_LOCAL_MACHINE/SOFTWARE/Policies/Microsoft/Windows/
IPSec/GPTIPSECPolicy

域策略的本地注册表缓存存储在以下位置：

HKEY_LOCAL_MACHINE/SOFTWARE/Policies/Microsoft/Windows/
IPSec/Policy/Cache

目录存储应该由 IPsec 策略管理 MMC 管理单元或者作为本地进程对 Active Directory 运行的 netsh ipsec 命令管理。 没有任何工具允许您直接查看缓存内容。 应该使用注册表工具来确定缓存是否存在并包含正确的内容。 同样，使用注册表工具来通过删除 GPTIPsecPolicy 和 Cache 注册表项来删除域策略。 然后，必须重新启动 IPsec 服务，或者使用服务控制命令来强制重新加载 IPsec 策略，但不加载域策略。

要刷新基于域的 IPsec 策略指派并重新加载 IPsec 策略和更新缓存内容，请使用 gpudpate /force。

要临时地阻止域策略应用于本地计算机，您可以同时对 GPTIPsecPolicy 和 Cache 注册表项配置权限以拒绝对本地系统帐户的读取访问权限。 由于 IPsec 安全监视器 MMC 管理单元和命令行工具读取本地管理员用户上下文中运行的 GPTIPsecPolicy 信息，所以这些工具仍将把域策略显示为已指派。 要长期阻止基于域的 IPsec 策略，应该不允许计算机读取 Active Directory 中的适当 GPO。

在 Windows 2000 中，当策略有问题时，您可能会看到下列错误：

在 Windows XP 和 Windows Server 2003 中，下列事件表示 IPsec 服务无法检索特定类型的策略。

再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow