使用 IPsec 与组策略隔离服务器和域-第 7 章:IPsec 疑难解答

本章提供有关如何对 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 层疑难解答第 1 层疑难解答
第 2 层疑难解答准备第 2 层疑难解答准备
IPsec 疑难解答过程IPsec 疑难解答过程
第 3 层疑难解答第 3 层疑难解答
总结总结

支持层和汇报

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

第 1 层:咨询台。 咨询台既是与域相关的客户端问题的入口点又是与域无关的客户端问题的入口点。 咨询台还支持由中央 IT 组织管理的服务器。 (其他服务器可能由业务应用小组或产品组管理。) 咨询台职员经过培训,他们可以使用分类法和若干流程图来将与服务器和域隔离相关的问题分类。

在 Microsoft 隔离解决方案的试验阶段,客户端问题被汇报给“企业 IT 安全性”部门。 然而,在将解决方案部署到生产环境中后,客户端问题由第 2 层支持小组处理。

第 2 层:数据中心操作、全局网络运作中心、业务流程应用支持以及消息传递/协作支持。 这些都是日常运作小组,他们监视并管理 IT 服务以及相关资产。 在服务器和域隔离试验期间,对于与服务器相关的问题和疑难解答来说,这些小组是咨询台和“企业 IT 安全性”部门的初始汇报点。 每个小组都有服务器和域隔离方面的专家,并且都有详细的疑难解答过程。

第 3 层:Windows 网络和基础结构服务。 在服务器和域隔离试验期间,这个小组确定一组人员作为解决方案疑难解答专家 - 相关的体系结构组件和技术,如 IPsec、TCP/IP 数据包处理、计算机帐户和网络登录权限。 在 Microsoft 内部,如果需要进行进一步的汇报,第 3 层职员就会直接与 Windows 开发小组配合工作,直到达成最终方案为止。 在 Microsoft 外部,这个级别将根据需要与“Microsoft 产品支持服务”配合工作。

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

第 1 层疑难解答

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

问题是否出自 IPsec?

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

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

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

网络连接性。 使用 pingtracert Internet 控制消息协议 (ICMP) 消息来测试网络路径。

名称解析。 使用 ping<目标名称>nslookup

应用程序。 当与同一目标通信时,某些应用程序工作正常(例如 net view),但其他应用程序无法正常工作。

服务。 例如,确定服务器是否正在运行路由和远程访问 (RRAS) 服务,该服务会为 L2TP 创建有冲突的自动 IPsec 策略。

呼叫者的计算机。 确定该计算机能否访问用于进行咨询台测试和诊断的任何主机或特定受信任主机目标计算机。

目标计算机。 确定呼叫者的计算机是否可以访问所有用于进行测试的咨询台计算机但无法访问某台目标计算机。

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

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

指定范围和严重性

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

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

特定于计算机的问题。 受 IPsec 保护的通信要求进行相互 Internet 密钥交换 (IKE) 计算机身份认证。 发起通信的计算机与响应通信的计算机都必须有有效的域帐户并能够访问它们所在的域的域控制器。 此外,IPsec 策略指派和网络访问控制要求计算机帐户包含在正确的域组中。 可能影响 IPsec 行为的其他特定于计算机的问题包括:

操作系统没有正确的服务包、修补程序或注册表项配置。

计算机安装了某个软件,或者正在运行特定的服务。

网络连接正在使用特定 IP 地址或者正在使用特定网络路径进行通信。

由于这些类型的问题,某些计算机可能会遇到连接性故障,而其他计算机则不会。

注:本章讨论的所有 IPsec 疑难解答工具都要求本地管理员组权限。

特定于网络位置和路径的问题。 在服务器和域隔离解决方案或 IPsec 的其他流行部署中,有可能所有 TCP 和 UDP 通信流都被封装。 因此,路径中的网络设备将只能看到 IKE、IPsec 和 ICMP 协议。 如果在源计算机与目标计算机之间传输这些协议时发生了任何网络问题,两台计算机之间的通信就会中断。

特定于用户的问题。 IPsec 的部署(如在服务器和域隔离方案中的部署)会影响域用户的网络登录权限。 例如,此问题可能只影响未隶属于有权进行网络访问的组中的用户,此外,授权用户在获取包含正确组成员身份的 Kerberos 身份验证凭据时也可能会发生问题。 域帐户与本地用户或服务帐户之间的行为可能会有区别。

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

疑难解答流程图

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

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

是网络连接性问题吗? 如果是,尝试进行基本的网络疑难解答。 如果不成功,就汇报给第 2 层支持。

是名称解析问题吗? 如果是,尝试进行基本的名称解析疑难解答。 如果不成功,就汇报给第 2 层支持。

是应用程序问题吗? 如果是,就汇报给第 2 层支持。

是呼叫者计算机的 IPsec 问题吗? 如果是,转到图 7.2。

是呼叫者尝试访问的目标计算机的 IPsec 问题吗? 如果是,转到图 7.3。  

图 7.1 无法与目标计算机进行通信时的疑难解答过程

图 7.1 无法与目标计算机进行通信时的疑难解答过程
查看大图

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

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

是 RRAS 问题吗? 如果是,或者停止 RRAS 服务(如果不需要 RRAS ),或者将问题汇报给第 2 层支持。

是策略问题吗? 如果是,尝试刷新组策略和 IPsec 策略。

是域帐户问题吗? 如果是,请为呼叫者计算机创建域帐户。

上述全都不是? 如果无法通过刷新 IPsec 策略和/或创建域帐户解决问题,则将该问题汇报给第 2 层支持。

图 7.2 对与呼叫者计算机 IPsec 相关的问题进行疑难解答

图 7.2 对与呼叫者计算机 IPsec 相关的问题进行疑难解答
查看大图

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

是 RRAS 问题吗? 如果是,就汇报给第 2 层支持。

是 IPsec 策略问题吗? 如果是,尝试刷新组策略和 IPsec 策略。 然后,检查网络连接。

是网络连接性问题吗? 如果是,就汇报给第 2 层支持。

是登录权限问题吗? 如果是,就汇报给第 2 层支持。

图 7.3 对与目标计算机 IPsec 相关的问题进行疑难解答

图 7.3 对与目标计算机 IPsec 相关的问题进行疑难解答
查看大图

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

问题已确定,并已解决。 此状态表示问题已被解决,并且问题的原因已明确。

问题未确定,但已解决。 此状态表示问题已被解决,但问题的原因未完全明确。 例如,通过进行 IPsec 策略刷新,可能能够解决问题,但不必解释为何应用了不正确的策略(甚至根本未应用任何策略)。

未解决。 此状态表示该问题仍待处理,但由于已将问题汇报给第 2 层支持,所以问题可能已被确定。  

预防社会工程攻击

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

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

免除列表的成员。 通过使用 IPsec 监视器 MMC 管理单元或通过查看本地注册表中的域 IPsec 策略缓存,所有受信任主机上的本地管理员都有可能看到免除列表筛选器中的 IP 地址列表。 此外,公司使用的安全设置可能会允许非管理用户对缓存进行读访问。 在全面实施域隔离之后,攻击者必须扫描网络以检测免于处理的计算机,这些计算机能够响应 TCP 和 UDP 连接请求。 注意,根据 DHCP 配置,可以很容易地确定 DNS 服务器、DHCP 服务器和 WINS 服务器,并且,通过使用 DNS 查询或 UDP 轻型目录访问协议 (LDAP) 查询,可以很容易地找到域控制器。

公司中未参与隔离解决方案的计算机。 例如,解决方案可能未包括某些类型的域或服务器。

使用了服务器隔离或者需要基于机器的访问控制的计算机。 包含最敏感信息的服务器通常实施最严密的安全保护。

IT 组织内的管理员用户或拥有特殊角色的用户。 在某些情况下,电子邮件地址被用作计算机名或计算机名的一部分,从而透露了登录名或电子邮件地址。

用于特定用途或由特定组织使用的子网。 如果攻击者了解此信息,他们就可以将他们的攻击侧重于网络的最敏感并且最有价值的部分。

正在使用的其他基于网络的安全措施。 例如,对是否存在防火墙、路由器筛选器是否允许某些通信流或者是否使用了网络入侵检测等情况的了解对于攻击者来说非常有帮助。

咨询台人员还应该接受培训,当呼叫者请求他们连接至呼叫者计算机 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

该脚本执行下列功能:

发现操作系统版本

调用 Detect_IPsec_Policy.vbs

增加组策略记录

增加 Kerberos V5 身份验证协议记录

清除当前 Kerberos 协议票证

刷新组策略

启用 IPsec 记录

执行 PING 和 SMB (Net View) 测试

检测 IPsec 文件版本

运行策略和网络诊断测试

将 IPsec 547 事件复制到一个文本文件中

禁用 IPsec 记录

恢复 Kerberos 协议记录

恢复组策略记录

此脚本还启用所有与 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 层支持应该收集下列信息并随服务请求一起传递:

IPsec_Debug.vbs 脚本生成的日志文件。

呼叫者的机器名,此信息帮助下一层支持确定脚本生成的日志文件。

被拒绝访问的目标计算机,此信息使问题将被汇报给正确的支持小组。

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

第 2 层疑难解答准备

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

第 2 层支持技巧

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

组策略。 了解应该指派哪些策略以及如何指派那些策略,并且能够执行下列任务:

对组策略对象 (GPO) 检查访问控制表 (ACL)。

检查 GPO 设置。

检查计算机和用户的组成员身份。

有关机构使用的第三方软件的经验

身份验证失败标识

能够使用 netdiagnltest 实用程序验证域计算机帐户是否正确。

IPsec 配置。 能够执行下列任务:

验证 IPsec 筛选器配置。

重新加载 IPsec 域策略。

完全禁用 IPsec,或者仅仅禁用域策略以使用本地策略来进行测试。

对 IPsec IKE 协商过程和安全协议进行疑难解答。

联网。 能够执行下列任务:

对主机上的网络协议堆栈进行疑难解答。

了解进行网络跟踪时收集的信息并能够进行疑难解答。

对网络路径问题(包括 TCP 路径 MTU 发现和虚拟专用网络 (VPN) 远程访问解决方案问题)进行疑难解答。

使用 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 组件的信息:

IKE 主模式和快速模式

本地 IPsec 策略或域 IPsec 策略

适用于计算机的 IPsec 筛选器  

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

提供有关活动 IPsec 策略的详细信息,包括策略名、描述、上次修改日期、存储、路径、OU 以及组策略对象名。 要在 Windows XP 中获取同一信息,您必须使用 IPseccmd 命令行工具(在本节随后的内容中有所描述)。

统计信息是分别针对主模式或快速模式提供的,而且位于每个模式下的文件夹中,而不是显示在一个屏幕中。

注:在 Windows 2000 中,IP 安全监视器是独立的可执行程序 (IPsecmon.exe),它具有自已的图形用户界面 (GUI)。 Microsoft 知识库文章 257225“Windows 2000 基本 IPSec 疑难解答”描述了此工具及其用法,网址为 http://support.microsoft.com/kb/257225。

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 实用程序具有下列功能:

动态地打开和关闭 IKE 记录。

显示关于当前指派的策略的信息。

使您能够创建永久 IPsec 策略。

可以显示当前指派的并且活动的 IPsec 策略。

要了解有关更新后的 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 功能

命令描述Windows2000®WindowsXP®Windows2003®

netdiag
/test:ipsec

查看已指派的 IPsec 策略

否**

netdiag
/test:ipsec
/debug

显示活动 IPsec 策略、筛选器和快速模式统计信息

是*

否**

netdiag
/test:ipsec
/v

显示活动 IPsec 策略、筛选器和主模式统计信息

是*

否**

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

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

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

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

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

工具支持的操作系统如何获取角色更多信息

Ipsecpol.exe

仅限 Windows 2000

Windows 2000 资源工具包

在目录或注册表中配置 IPsec 策略

Windows 2000 资源工具包工具帮助

Gpresult

Windows 2000, Windows Server 
2003, Windows XP

Windows 2000 – 资源工具包;对于 Windows XP 和 Windows Server 
2003,它是操作系统的一部分

检查组策略的上次应用时间

Windows 2000 资源工具包工具帮助、Windows XP 帮助以及 Windows Server 
2003 帮助

策略的结果集 (RSoP) MMC
管理单元

Windows Server 
2003, Windows XP

包含在操作系统中

查看计算机的 IPsec 策略或者组策略容器成员的 IPsec 策略

Windows Server 
2003 帮助

Srvinfo

Windows 2000, Windows Server 
2003, Windows XP

Windows 2000 和 Windows Server 
2003 资源工具包

服务、设备驱动程序和协议信息

Windows Server 
2003 资源工具包工具帮助

PortQry

Windows 2000, Windows Server 
2003, Windows XP

Windows Server 
2003 资源工具包

网络端口状态报告

http://support.
microsoft.com/
kb/310099

NLTest

Windows 2000, Windows Server 
2003, Windows XP

支持工具

测试信任关系和 Netlogon 安全通道

Windows Server 
2003 支持工具帮助

Klist

Windows 2000, Windows Server 
2003, Windows XP

Windows 2000 和 Windows Server 
2003 资源工具包

Kerberos 票证报告

Windows Server 
2003 资源工具包工具帮助

Pathping

Windows 2000, Windows Server 
2003, Windows XP

包含在操作系统中

网络连接和路径测试

Windows 帮助

LDP

Windows 2000, Windows Server 
2003, Windows XP

支持工具

用于测试 Active Directory 的 LDAP 客户端

Windows Server 
2003 支持工具帮助

对 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 驱动程序丢弃了出站 ICMP 数据包。

由于存在允许筛选器或软 SA,IPsec 驱动程序允许以不安全的方式传递 ICMP 数据包。

IPsec 驱动程序未检测到出站数据包(例如,如果该数据包已被 IPsec 驱动程序上方的层丢弃)。

注:某些使用 ICMP 的工具可能无法检测到 IPsec 正在协商安全性,并可能产生不一致的或错误的结果。

IPsec 疑难解答过程

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

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

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

文件名描述

<CompName>_FileVer.txt

列出各个与 IPsec 相关的 DLL 文件版本。

<CompName>_gpresult.txt

gpresult 命令的输出。

<CompName>_ipsec_547_events.txt

安全事件日志中的任何 IPSEC 547 错误的输出。

<CompName>_ipsec_policy_version.txt

Detect_IPsec_Policy.vbs 脚本的输出。 显示机器上的当前策略版本以及它是否与 Active Directory 策略相匹配。

<CompName>_ipseccmd_show_all.txt

只有在 Windows XP 上才有此文件。 此文件捕获 ipseccmd 命令的输出。

<CompName>_kerberos_events.txt

系统事件日志中任何 Kerberos 事件的输出。

<CompName>_klist_purge_mt.txt

KList 在清除机器票证时的输出。

<CompName>_lsass.log

lsass.log 文件的副本(如果存在该文件)。

<CompName>_netdiag.txt

运行 netdiag 时的输出。

<CompName>_netsh_show_all.txt

只有在服务器平台上才有此文件。 netsh 中的 show all 命令的输出。

<CompName>_netsh_show_gpo.txt

只有在服务器平台上才有此文件。 netsh 中的 show gpo 命令的输出。

<CompName>_oakley.log

Oakley.log 文件的副本(如果存在该文件)。

<CompName>_OSInfo.txt

当前操作系统信息的输出。

<CompName>_RegDefault.txt

在进行更改前的最初注册表项值的输出。 当脚本由于某种原因而发生故障时,您可以使用此输出将注册表手动重新设置为先前的值。

<CompName>_userenv.log

userenv.log 文件的副本(如果存在该文件)。

<CompName>_<SrvName>_netview.txt

对 <SrvName> 执行 net view 命令时的输出。

<CompName>_<SrvName>_ping.txt

对 <SrvName> 执行 ping 命令时的输出。

<CompName>_winlogon.log

winlogon.log 文件的副本(如果存在该文件)。

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

验证域控制器的 IP 网络配置、网络连接和服务以及与 IPsec 相关的协议的客户端-服务器路径连接。

验证客户端和服务器是否正确地应用了组策略和 IPsec 策略。

调查与 IKE 协商以及受 IPsec 保护的通信相关的问题。

确定问题原因以便汇报给第 3 层(如果有需要)。  

考虑以下示例方案:客户端报告能够 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 相关问题排除手段使用。

广播和多播通信流环境

与那些不要求入站访问使用 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 来确认获取地址时未发生问题:

对于 DHCP 客户端来说,打开命令窗口并运行 ipconfig /release,接着运行 ipconfig /renew。

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

名称解析问题

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

客户端能否 ping 它的 IP 配置中列示的 DNS 服务器 IP 地址?

nslookup 能否找到 DNS 服务器?

客户端能否 ping 目标的完全合格的 DNS 名称?

客户端能否 ping 目标的 DNS 或 NetBIOS 短名称?

名称解析问题的可能原因包括活动 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 filters
Netsh ipsec static show all 

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

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

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

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

检查客户端是否可以 ping 每个域控制器 IP 地址。 如果客户端无法 ping 每个域控制器 IP 地址,请参阅上述网络连接步骤。

确定域成员的域控制器使用了哪些 IP 地址。 使用 nslookup <域名> 来返回完整的 IP 地址列表。 在服务器和域隔离方案中,应该有一个快速模式特别筛选器对这些地址中的每个地址的协商策略(筛选器操作)都是“许可”。

使用版本 2.0 或更新版本的 portqry.exe 工具或 PortQueryUI 工具来测试对域控制器 UDP、LDAP 和 RPC 端口的访问。 portqry 使用的 UDP 协议消息通常不要求进行上层协议身份验证,因此即使不能进行身份认证,它们也可以验证服务是否可用。 “HOW TO: Use Portqry to Troubleshoot Active Directory Connectivity Issues”对这些步骤作了说明,网址为 http://support.microsoft.com/?kbid=816103。

当与内部网络相连接时,使用 netdiag /v >outputfile.txt 来执行许多与 DNS 相关的以及与域控制器相关的连接测试。 Netdiag 使用多个网络连接和协议来执行测试;如果任何这些连接触发了 IKE 协商,并且身份验证由于 IKE 找不到用于 Kerberos 身份验证的域控制器而失败,就可能会在安全日志中记录事件 547 故障错误。

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

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

打开命令提示符并输入以下命令:

klist tickets

查看域计算机票证

1.

验证任务计划程序服务是否正在运行,并且已登录用户是否是本地 Administrators 组的成员。

2.

在命令行提示符处,选择比当前系统时间晚一分钟的时间(如 4:38 pm)并输入以下命令:

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

注意,命令窗口标题栏包含 C:/Windows/System32/svchost.exe

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

清除计算机的 Kerberos 票证

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

1.

验证任务计划程序服务是否正在运行,并且已登录用户是否是本地 Administrators 组的成员

2.

在命令行提示符处,选择比当前系统时间晚一分钟的时间(如 4:38 pm)并输入以下命令:

at 4:38pm /interactive cmd

3.

键入 klist purge 并对每种票证类型按 Y 以删除所有 Kerberos 票证。

4.

键入 klist tickets 以确认不存在任何票证。

5.

如果此过程是 IKE 协商故障疑难解答过程的一部分,则等待 1 分钟时间以使 IKE 协商超时,然后再次尝试使用应用程序来访问目标服务器。 新的 IKE 主模式协商将为目标计算机请求新的 Kerberos TGT 和服务票证,该票证将包含最新的组信息。 确保不要从本地系统上下文中运行的命令窗口中执行应用程序。  

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

Kerberos 错误疑难解答,网址为 www.microsoft.com/downloads/details.aspx?
FamilyID=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en

Kerberos 委派疑难解答,网址为 www.microsoft.com/downloads/details.aspx?
FamilyID=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&displaylang=en

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

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

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

1.

依次单击“开始”和“运行”,键入 ldp.exe 并按 ENTER 键。

2.

选择“连接”,然后选择“连接”。 指定目标域的名称。

3.

选择“连接”,然后选择“绑定”。 指定目标域的登录凭据。

4.

选择“查看”,然后选择“树”。 不指定基本 DN 并导航到 IPsec 策略容器,或者指定 IPsec 策略容器的 LDAP DN 来作为基本位置。

5.

在树视图中单击容器节点旁边的“+”(加号)。 如果您对该容器具有读取权限,则该容器中的所有 IPsec 策略对象都将显示。

:某些域用户可能会由于权限的配置方式而对容器不具有读取权限。 有关更多信息,请参阅 Microsoft 知识库文章 329194“IPSec Policy Permissions in Windows 2000 and Windows Server 2003”,网址为 http://support.microsoft.com/?kbid=329194。

对于策略检索和损坏问题的高级疑难解答来说,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 对象名称映射

IPsec 策略组件名称Active Directory 对象名称

IPsec 策略

ipsecPolicy{GUID}

IKE 密钥交换安全措施

ipsecISAKMPPolicy{GUID}

IPsec 规则

ipsecNFA{GUID}

IPsec 筛选器列表

ipsecFilter{GUID}

IPsec 筛选器操作

ipsecNegotiationPolicy{GUID}

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 策略。

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

客户端能否 ping 它自己的 IP 地址或本地环回地址 127.0.0.1? 如果不能,则可能是 TCP/IP 配置有问题、安装了第三方防火墙、Ping 实用程序丢失或者 IP 配置无效。 使用其他 TCP/IP 配置疑难解答过程来进行调查。

客户端能否 ping 它的 IP 配置中显示的默认网关? 如果不能,则可能是客户端上的 IP 配置有问题、本地接口未连接或者对连接进行了限制、本地或网络筛选器阻止了通信流或者通往默认网关的网络路径已中断。 使用其他 TCP/IP 疑难解答过程来进行调查。

客户端能否 ping 它的 IP 配置中显示的 DNS 服务器? 如果不能,则可能是 DNS 服务器不允许它们自己接收 ICMP 回应请求消息、IPsec 策略未免除正确的 DNS 服务器 IP 地址或者存在上面提到的任何可能问题。 使用其他 TCP/IP 疑难解答过程来进行调查。

客户端能否 ping 免除列表中的 IP 地址,如 DC? 如果不能,则问题不是由 IPsec 引起的,或者 IPsec 没有用于那个免除的 IP 地址的筛选器。 后者可通过检查筛选器配置来进行确认。 请参阅本章随后的 IPsec 策略一节。

客户端能否 ping 目标的 IP 地址? 如果能,则表示客户端与不带 IPsec 的目标之间存在基本网络连接问题。 如果不能,则尝试对该目标以及其他目标 IP 地址执行 tracert 以确定网络路径的有效程度。 使用其他 TCP/IP 和核心网络疑难解答过程来进行调查。

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

IKE。 UDP 源端口 500、目标端口 500 和片段

IKE/IPsec NAT-T。 UDP 源端口 4500 和目标端口 4500

IPsec ESP。 IP 协议 50 和片段

IPsec AH。 IP 协议 51 和片段

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

由于状态通常基于活动超时,因此状态筛选可能会导致 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 注册表项的用法以及安全含义的详细信息,请参阅下列知识库文章:

810207 - IPSec default exemptions are removed in Windows Server 2003,网址为 http://support.microsoft.com/?kbid=810207

811832 - IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios,网址为 http://support.microsoft.com/?kbid=811832

注:Windows XP SP2 与 Windows Server 2003 使用相同的默认免除。

在所有平台上都可以根据需要设置注册表项,以便控制默认免除。 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 Packets Not Authenticated”计数器。 在 Windows Server 2003 中,可以通过使用性能监视器中的 IPsec 计数器、通过使用 netsh ipsec dynamic show stats 命令或者通过在 IPsec 安全监视器 MMC 管理单元中查看统计信息来检查此计数器。 在 Windows XP 中,可以通过使用 ipseccmd show stats 命令或者通过在 IPsec 安全监视器 MMC 管理单元中查看统计信息来检查此计数器。 Windows 2000 将在 ipsecmon.exe 图形界面中显示此计数器,此外,您也可以使用
netdiag /test:ipsec /v 命令。

启用 IPsec 驱动程序记录,并在系统日志中查找由 IPsec 产生的事件 4285。 请参阅本章的“工具包”一节以了解有关如何启用 IPsec 驱动程序记录的详细信息。 事件文本将类似于:

未能身份验证从 192.168.0.10 上的 5 个数据包接收的散列。 这可能是临时的问题;如果问题持续存在,请停止并重新启动此机器上的 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 中已解决了此问题。 由于各种协议已预期某些数据包会由于各种其他原因而丢失,所以,此问题对上层协议通信的影响通常可以忽略不计。 此问题由下列问题印证:

“Bad SPI”计数器值缓慢但连贯地增加。

系统日志事件 4268 消息(如果已启用)。 默认情况下,Windows 2000 将这些消息作为事件 4268 记录到系统日志中。 Windows XP 在默认情况下不记录此事件;必须启用驱动程序记录功能。 事件文本类似于:

“从 <Ip 地址> 接收到一个带有不正确的‘安全参数索引’的 <数目> 数据包。 这可能是临时的问题;如果问题持续存在,请停止并重新启动此机器上的 IPSec 策略代理服务。”  

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

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

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

正在通过千兆位或更高速度的连接传送大量的 IPsec 通信流。

当存在负载较重(低速)的服务器和快速客户端时。

当有低速客户端与高速服务器通信时。

当服务器有许多活动客户端时(这种情况将导致 IKE 不断地同时对许多客户端重新生成密钥)。  

产生的影响是,受 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 配置或者直接通过注册表项允许报告这些事件。

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

调整 IPsec 策略设置。 将快速模式生存期(如果安全要求允许)提高到 21 或 24 小时(空闲 IPsec SA 如果未被使用,则将在 5 分钟内被删除)。 为了避免由于使用同一项来对太多数据进行加密而带来潜在的安全威胁,当使用 ESP 加密时,不要将生存期设置为大于 100 MB。

使用主模式或快速模式完全向前保密 (PFS),这对于所协商的特定 IPsec SA 来说不会引起此问题。 但是,这两项设置都会在为许多客户端提供服务的计算机上显著增加负载,因此会导致响应其他协商时发生延迟。

添加 CPU 或其他硬件以提高性能,或者降低应用程序负载。

如果尚未安装 IPsec 硬件加速 NIC,则进行安装。 这些网卡能够显著降低 IPsec 使用的 CPU 利用率,从而提高数据传输吞吐量。

如果 CPU 利用率仍然很高,则调查能否使用硬件加速产品来提高 Diffie-Hellman 计算速度。 这些产品通常是具有 Diffie-Hellman 指数卸载能力的 PCI 卡,它们能提高 Diffie-Hellman 计算速度。 这种加速能力也能够使使用安全套接字层 (SSL) 协议的证书的公钥和私钥操作受益。 与供应商一起验证他们的卡是否确实支持“CAPI 中用于进行 Diffie-Hellman 计算的 ModExpoOffload 接口”。

如有可能,创建一个筛选器以允许某些不需要 IPsec 保护的高速通信流(例如,通过专用 LAN 进行的服务器备份通信流)。

如果这些选项不起作用,并且不可能升级到 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 服务未运行

无法检索 Active Directory 中的 IPsec 策略,因此使用了缓存的副本

为了检索当前已指派的 IPsec 策略而进行的 IPsec 策略轮询造成延迟

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

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

“Troubleshooting Group Policy in Windows 2000”,网址为 http://support.microsoft.com/?kbid=810739。

“Troubleshooting Group Policy in Microsoft Windows Server”,网址为 www.microsoft.com/downloads/details.aspx?
FamilyId=B24BF2D5-0D7A-4FC5-A14D-E91D211C21B2&displaylang=en.  

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

IPsec 策略管理 MMC 管理单元(这是安全策略 MMC 管理单元的扩展),用于指派 GPO 中的 IPsec 策略。

IPsec 的组策略客户端扩展 (CSE)(在 gptext.dll中实施),它处理 GPO 中与 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 如下所示:

Security. {827D319E-6EAC-11D2-A4EA-00C04F79F83A}

IP Security.{E437BC1C-AA7D-11D2-A382-00C04F991E27}

Scripts. {42B5FAAE-6536-11D2-AE5A-0000F87571E3}

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

导致对象找不到的复制问题或延迟。

域控制器定位器的负载平衡逻辑可能导致从一个域控制器中检索 GPO,而对已指派的 IPsec 策略执行的 LDAP 查询是从同一站点中的另一域控制器检索的。

要为安全 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 服务在启动期间发生故障:

计算机是以安全模式或 Active Directory 恢复模式启动的。 在这些情况下,如果已指派 IPsec 策略,则 IPsec 驱动程序在默认情况下将提供状态出站通信。 除非配置了引导免除,否则入站连接将被阻止。

IKE 无法获取对 UDP 端口 500 和端口 4500 的独占控制权。 使用 netstat –bov 以显示每个端口的进程和代码模块。 命令 portqry –local –v 将提供更多详细信息。 可能是安装了某些干扰 IPsec 的 Winsock 分层服务提供程序 (LSP)。 有关 LSP 和 IPsec 的更多信息,请参阅本章随后的“与应用程序相关的问题的疑难解答”。

IPsec 策略损坏。 完全无法读取或完全无法应用所指派的 IPsec 策略,这导致 IPsec 服务报告了许多错误。 这些错误不会导致服务本身失败,但可能导致通信以许多种方式失败,如导致组策略和 IPsec 服务无法检索正确的策略。 在 Windows XP 和 Windows Server 2003 中,应该对永久策略或本地策略的设计加以关注,当应用基于域的策略发生错误时,将应用这些策略以作为“安全”的策略。 永久策略和计算机启动策略(启动模式免除)都应该包括在疑难解答调查范围内。 这些策略应该允许通过其他方法对计算机进行远程访问,以防它们由于其他故障条件而成为唯一应用的策略。

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 策略代理可能会因为服务启动问题而记录错误。 这些错误包括:

IP 安全策略代理无法启动。 将不强制实施任何 IP 安全策略。 此错误可能是由 IPsec 策略代理在对 RPC 子系统注册它自己时遇到的问题导致的。 此错误的原因也可能是 IKE 因为存在第三方 Winsock LSP 而无法进行初始化。

策略代理 RPC 服务器无法...

注册协议顺序

注册接口

注册接口绑定

注册接口端点

注册身份验证机制

进行侦听

任何这些错误都可能是由高级安全设置的更改导致的,也可能是由 RPC 服务中的问题导致的,那些问题导致 IPsec 策略代理服务在服务启动期间无法正确地初始化。 因此,IPsec 策略代理将无法正常工作、可能挂起并可能关闭。

策略代理无法启动。 无法连接至 SCM 数据库。 错误:<编号> IPsec 服务无法打开服务控制管理器数据库,这可能是因为 IPsec 服务被配置为作为不具有权限的服务帐户运行而导致的。 它必须作为本地系统运行。 否则,请调查服务控制管理器是否有问题。

策略代理无法连接至 IPSEC 驱动程序 IPsec 驱动程序无法成功地完成加载并与 TCP/IP 堆栈进行交互。 Windows 2000 被设计成在 IPsec 服务启动时执行此操作。 可能是第三方软件禁止了该连接,或者可能是操作系统缺少此功能所必需的代码模块。

策略代理无法加载 IPSEC 策略。 IPsec 策略代理在将所有筛选器加载到 IPsec 驱动程序中时发生错误。 此错误可能是由于内核内存不足导致的,也可能是由于 IPsec 驱动程序未正确地完成初始化导致的。 如果问题仍存在,请与 Microsoft 产品支持服务联系。

策略代理无法启动 ISAKMP 服务 发生此错误的原因通常是由于另一个服务已使用 UDP 端口 500 或端口 4500 而导致 IKE 无法获取这些端口的独占控制权。 此错误也可能是由于第三方安全软件禁止进行网络端口分配而导致的,也可能是由于未在本地系统上下文中运行 IPsec 服务而导致的。

无法确定 ISAKMP/Oakley 服务的 SSPI 主名称。 当安全支持提供程序接口 (SSPI) 函数调用 QueryCredentialsAttributes 失败时,Windows 2000 将记录此消息。 此故障可能表示计算机无法成功地登录到域。

无法获取 ISAKMP/Oakley 服务的 Kerberos 服务器凭据。 这条 Windows 2000 错误消息通常是在远程网络中启动 IPsec 服务(可能是在计算机启动时)时出现的,在该网络中,指派了 IPsec 策略(可能是从域策略的注册表缓存中指派的),该 IPsec 策略要求进行 Kerberos 身份验证,但没有域控制器可用。 因此,Kerberos 身份验证无法正常工作。 在内部网络中,此事件将记录在并非域成员或者在 IPsec 服务初始化期间无法使用 Kerberos 协议来访问域控制器的计算机上。

由于 IP 安全驱动程序无法启动,所以无法强制实施安全通信策略。 请立即与系统管理员联系。 此错误是由 IPsec 驱动程序加载时发生的问题、与 TCP/IP 堆栈绑定时发生的问题或者在尝试对其添加策略前进行初始化时发生的问题引起的。 文件损坏或权限可能是问题的原因。 请查找导致无法进行驱动程序加载的安全设置或第三方安全软件。 如果在初始化期间无法验证 FIPS.sys 内部签名,就无法加载它,并且 IPsec 驱动程序也将无法加载。 发生 FIPS.sys 签名失败问题时,您需要替换原始的已签署二进制文件,也可以使用新的由 Microsoft 提供的二进制文件。 重新启动计算机。 如果问题仍存在,请与 Microsoft 产品支持服务联系。  

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

IPSec 服务初始化 IPSec 驱动程序失败,错误代码为:<编号>。 IPSec 服务不能启动。 IPsec 驱动程序由于某种原因而无法加载。 如果问题仍存在,请与 Microsoft 产品支持服务联系。

IIPSec 服务初始化 IKE 模块失败,错误代码为:<编号>。 IPSec 服务不能启动。 此问题的常见原因是第三方 Winsock LSP,后者导致 IKE 无法使用某些套接字选项。 当 IKE 无法获取对 UDP 端口 500 和 4500 的独占控制权时,也将报告此错误。

IPSec 服务初始化 RPC 服务失败,错误代码为:<编号>。 IPSec 服务不能启动。 IPsec 服务依靠 RPC 子系统在 IKE、SPD 和策略代理之间进行进程间通信。 使用 RPC 疑难解答技术来确认 RPC 工作正常。 在重新启动计算机之后,如果问题仍存在,请与 Microsoft 产品支持服务联系。

IPSec 服务遇到一个关键性失败,已经停止,错误代码为:<编号>。 停止 IPSec 服务可能会对此机器的安全性构成潜在威胁。 请与您的机器管理员联系,重新启动此服务。 IPsec 服务遇到了由事件文本中的 <编号> 指示的错误,已不再运行。 IPsec 驱动程序仍处于已加载状态,并可能处于正常模式(强制实施 IPsec 策略筛选器)或阻止模式。 有一个独立的事件将指示 IPsec 驱动程序是否已进入阻止模式。 如果该驱动程序处于正常模式,则表示允许和阻止筛选器操作仍按预期方式工作。 由于 IKE 不可用,所以进行协商操作的筛选器仅仅丢弃通信流。

由于以前的失败错误代码 <编号>,IPSec 服务将 IPSec 驱动程序置于阻止模式。 此消息是一个通知,表示由于在处理 IPsec 策略期间遇到错误,作为一项防故障行为,IPsec 驱动程序已进入阻止模式。 此行为只有在 Windows Server 2003 中才存在。 阻止模式仍允许通过 netsh ipsec 命令配置的入站免除。  

IPsec 策略检索疑难解答

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

与域控制器通信时发生的问题。

计算机帐户登录到域控制器时发生的问题。

发放 Kerberos 票证时发生的问题。

LDAP 服务可用性问题。

查找 LDAP 查询中请求的特定 IPsec 策略或组件对象时发生的问题。

对所请求的任何 IPsec 策略对象的读取权限问题。

由于将对象保存至存储库时发生问题或者由于在存储库中意外或故意删除对象而导致策略损坏。  

:对于在 Windows XP 或 Windows Server 2003 中创建并使用那些版本提供的新功能的 IPsec 策略来说,如果使用 Windows 2000 IPsec 策略管理 MMC 管理单元来编辑并保存那些策略,那些策略就可能会静默地删除那些新功能。 然而,如果 Windows 2000 系统检索具有附加功能的 IPsec 策略,它仅仅是忽略那些功能,在 Windows 2000 系统上强制实施该 IPsec 策略时,该策略的行为可能会也可能不会更改。

当管理 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 选项。 此配置存储在以下注册表项中,下面提供了默认值:

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/IPSec/
OperationMode=3(状态)

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/IPSec/
BootExemptList =(入站 DHCP 免除,请参阅以下内容)

默认的 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.exeipseccmd.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 static
Set store persistent
show all
exit

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

pushd ipsec static
set store persistent
delete all
exit
本地 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 gponetdiag /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 命令管理。 没有任何工具允许您直接查看缓存内容。 应该使用注册表工具来确定缓存是否存在并包含正确的内容。 同样,使用注册表工具来通过删除 GPTIPsecPolicyCache 注册表项来删除域策略。 然后,必须重新启动 IPsec 服务,或者使用服务控制命令来强制重新加载 IPsec 策略,但不加载域策略。

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

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

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

无法绑定到 Directory 架构。 IPsec 策略代理服务无法对 Active Directory IP 安全策略容器执行经过身份验证的 LDAP 绑定。 此错误可能是由于计算机帐户无法成功登录并接收 Kerberos 凭据而导致的。 此错误也可能是由于 Kerberos 协议无法发放 LDAP 服务票证给 IPsec 策略代理服务而导致的。

无法绑定到 IPSEC 策略存储对象。 IPsec 策略定义了当前不存在的对象(如规则或筛选器列表)。 可能是该 IPsec 策略已损坏、可能是 Active Directory 存储策略已损坏,也可能是该对象已被删除(但是现有的 IPsec 策略仍引用该对象)。 通过使用 IPsec 策略管理 MMC 管理单元查看是否所有策略规则都完好并且能否正确地查看“密钥交换”属性(“常规”选项卡上),对 IPsec 策略进行检查。

找不到域控制器。 确保计算机是域成员并检查网络连接 IPsec 策略存储模块找不到 LDAP 目录,无法从中检索基于域的 IPsec 策略。

无法与域控制器上的目录服务通信。 请与系统管理员联系 IPsec 存储模块未能成功地使用 LDAP 签名和密封来下载指派的 IPsec 策略。

在存储中找不到对象 此错误通常很严重,这是因为 IPsec 策略完全无法被检索,因而无法正常工作。 IPsec 策略存储模块无法通过使用 LDAP 调用或远程注册表调用来找到包含在 IPsec 策略或其中一个规则中的对象(规则、筛选器列表、筛选器操作或 ISAKMP 设置)的 GUID。 此错误可能是由下列任何情况导致的:

复制延迟,在这种情况下,引用对象在被引用对象之前到达,或者查询变为针对两个不同的域控制器进行。

该对象可能已被删除,但 IPsec 策略仍使用该对象。

对象的权限可能拒绝了对该对象进行枚举或读取的能力,或者 IPsec 策略存储已被复原到先前不存在该对象时的状态。

IPsec 策略损坏可能会导致查询中的 GUID 无效。

可能没有通往目标 IP 地址的网络连接。

可能没有 LDAP 或远程注册表服务可用。

无法完成请求的操作。 策略存储未打开。 无法打开 Active Directory、远程计算机或本地计算机存储。 此错误通常是由权限或身份验证故障导致的。

正在使用活动本地注册表策略,原因是:(i) 没有 Active Directory 存储策略,或者 (ii) 无法成功地应用 Active Directory 存储策略,并且没有缓存的策略。 此事件表示计算机本地定义了 IPsec 策略,并且无法应用基于域的策略以覆盖该策略。

未使用任何 IPsec 策略,原因如下:(i) 没有 Active Directory 存储策略或活动本地注册表策略,或者 (ii) 无法成功地应用 Active Directory 存储策略,并且没有缓存的策略,或者没有活动本地注册表策略。 此事件表示默认状态,在此状态下,未对计算机指派任何策略。

在 Windows XP 和 Windows Server 2003 中,下列事件表示 IPsec 服务无法检索特定类型的策略。 在 Windows Server 2003 和 Windows XP SP2 中,如果无法成功地读取本地策略,则该策略将被忽略,并且按优先顺序读取下一个策略。

PAStore 引擎为“<策略名称>”在此计算机上加载永久性存储 IPSec 策略失败,错误代码为:<编号>。 IPsec 服务检测到永久策略已被指派并存储在本地注册表中,但无法读取至少其中一个永久策略对象的内容。 检查所有注册表项的权限。 该策略可能已损坏。 尝试删除所有永久策略并接着重新创建它。

PAStore 引擎为“<策略名称>”在此计算机上加载本地存储 IPSec 策略失败,错误代码为:<编号>。 IPsec 服务检测到已指派本地策略并尝试读取该策略,但在读取至少其中一个与指派的策略相关联的对象时发生故障。 检查所有注册表项的权限。 该策略可能已损坏,应该删除并重新创建该策略。

PAStore 引擎为“<策略名称>”在此计算机上加载目录存储 IPSec 策略失败,错误代码为:<编号>。 IPsec 服务在从 Active Directory 中读取指派的 IPsec 策略时遇到至少一个错误。 此错误可能是由于网络连接在所有策略对象被检索前中断而导致的,也可能是由于缺少 IPsec 策略对象或者未授予对象读取权限而导致的。

PAStore 引擎进行了轮询以了解对 Active Directory IPSec 策略的更改,检测到 Active Directory 不可访问,并且迁移为使用 Active Directory IPSec 策略的本地缓存副本。 在上次轮询后对 Active Directory IPSec 策略的任何更改都不会被应用。 此消息仅仅表示,在定期的轮询间隔时,IPsec 服务无法成功地联系 Active Directory(例如,由于丢失 DNS 服务),并且当前活动 IPsec 策略未发生任何更改。 在应用活动策略时,与 Active Directory 的连接最初是可用的,IPsec 服务已检索了最新版本并将其存储在缓存中。 因此,IPsec 服务现在将 IPsec 域策略的注册表缓存看作策略的主要来源。 轮询将继续尝试访问目录。  

IPsec 策略解释疑难解答

IPsec 策略解释是在成功地从适当存储位置检索整个策略后执行的。 将使用当前网络接口 IP 地址来将策略的一般筛选器扩充为特定筛选器。 然后,将入站和出站特别筛选器列表加载到 IPsec 驱动程序中以进行数据包处理。 IPsec 服务将接收到接口更改事件通知,这将尽快调整 IPsec 驱动程序中的 IPsec 筛选器配置(例如,“我的 IP 地址”筛选器)。

在 Windows 2000 中,下列消息表示出现了问题,从而导致无法正确地解释或配置 IPsec 组件以强制实施策略:

数据类型属性指定了不识别的数据格式。 IPsec 策略的一部分包含策略存储引擎所不识别的数据格式。 此错误表示策略已损坏,也可能表示将来某个时刻会发生策略版本问题。 Windows XP 和 Windows Server 2003 中的 IPsec 策略功能被设计成对 Windows 2000 IPsec 策略代理透明。

无法从 blob 读取数据。 IPsec 策略对象中的 IPsecData 属性的数据格式不是所需的格式。 此错误几乎总是表示策略损坏或版本问题。 在按计划成功应用所有 IPsec 策略设置之前,必须更正此问题。

策略代理没有接口列表。 IPsec 策略代理找不到任何要筛选的 IP 网络接口。 注意,消息文本中的错误直接来自 Windows 源代码,并且与此处显示的相同。

IP 公用帮助 API 无法获取接口表。 基于接口的筛选器不会被扩充并加载到 IPsec 驱动程序中 当 IPsec 策略代理尝试枚举计算机上的接口列表时发生错误。 可能没有网络接口,或者网络接口管理器发生内部错误。 与 PnP 不完全兼容的设备、文件损坏、NIC 驱动程序问题或者其他相关 Windows 联网组件的问题都可能是错误原因。 基于接口类型的 IPsec 筛选器,如规则中为特定连接类型(例如远程访问)配置的筛选器,而不是为所有连接配置的筛选器。 如果重新启动后问题仍存在,请与 Microsoft 产品支持服务联系。

IP 公用帮助 API 无法获取 IP 地址表。 基于接口的筛选器不会被扩充并加载到 IPsec 驱动程序中。 当 IPsec 策略代理尝试使用 IP Helper API 中的函数调用来枚举计算机上的所有 IP 地址时发生错误。 可能是未配置任何 IP 地址,或者是存在类似于以上的问题。

在接口表中找不到 IP 地址条目索引。 正在废弃 IP 地址。 IPsec 策略代理确认所有 IP 地址都在网络接口列表中出现。 在添加新网络接口或删除网络接口时发生的暂时情况可能会导致此问题。 此消息表示 IPsec 服务不会为策略中一般“我的 IP 地址”筛选器的这个被废弃 IP 地址创建特定筛选器,这样,当使用这个 IP 地址时,可能会依次表现出暂时的意外连接行为。 否则,此错误表示 IP 接口配置存在内部状态问题,这要求 Microsoft 产品支持服务进行进一步的调查。 由于该 IP 地址是被 IPsec 策略代理(而不是被 TCP/IP 堆栈)废弃的,所以不会为该 IP 地址创建 IPsec 筛选器。 因此,不会为使用此 IP 地址的通信流执行安全操作(如允许或阻止)以及 IPsec SA 协商。

在筛选器列表中存在匹配的筛选器镜像 此错误表示 IPsec 策略包含重复的筛选器条件。 您应该对 IPsec 策略设计进行分析以确保用于入站方向和出站方向的快速模式特别筛选器不重复。

未将任何筛选器添加到主筛选器列表中。 IPsec 策略代理在从存储器检索到的 IPsec 策略中找不到任何筛选器。 IPsec 策略可能只包含默认响应规则,或者读取规则或筛选器列表中遇到了错误。

0 个第 1 阶段安全措施。 正在废弃 ISAKMP 策略 如果找不到 IKE 主模式安全措施(ISAKMP 策略对象),则 IPsec 策略可能已损坏。

0 个第 2 阶段安全措施。 正在废弃协商策略。 在没有筛选器操作安全措施(IKE 快速模式第 2 阶段安全措施)的情况下,IKE 在为与相应筛选器匹配的通信流进行快速模式协商时将失败。 IPsec 策略可能已损坏。

策略未包含有效的安全措施 IPsec 策略在规则的筛选器操作中未包含有效的安全措施,或者它未包含 IKE 主模式设置(在“常规”选项卡中配置的“密钥交换”设置)。

策略代理已尝试将现有的筛选器插入 IPsec IPsec 驱动程序检测到存在重复的筛选器,并且拒绝了副本。 如果重复的筛选器与已加载到 IPsec 驱动程序中的筛选器具有相同的操作,这种情况就是良性的。 但是,如果筛选器操作不同,就是不受支持的 IPsec 策略设计。 经过一段时间后,结果可能会有所不同,并且,结果取决于策略更改的处理顺序。 设计 IPsec 策略时,应该避免筛选器重复。

无法将条目添加到 IPSEC 策略表中。 IPsec 策略代理无法将新的筛选器添加到 IPsec 驱动程序中。 此错误表示任何与该筛选器相匹配的通信流都不会受保护。 此错误可能是由于内核内存不足而导致的。 如果此问题持久存在,请与 Microsoft 产品支持服务联系。

策略代理无法插入或更新 IPsec 中的筛选器。 与前面有关插入筛选器的消息相似,IPsec 驱动程序中的筛选器列表不是所指派的 IPsec 策略所需的筛选器列表。 因此,并未按计划提供安全功能。

正在使用缓存的策略,这是因为无法成功地应用 Active Directory 存储策略(网络不可访问,策略完整性无效等等)。 当指派基于域的 IPsec 策略时,IPsec 策略代理将尝试首先从 Active Directory 读取最新的策略。 此消息表明 IPsec 策略代理无法从目录中检索 IPsec 策略,并且正在应用上一个域策略中的策略,该策略缓存在注册表中。  

在 Windows Server 2003 中,下列事件表示解释 IPsec 策略时遇到了问题。 在大多数情况下,Windows XP 使用相同的事件文本。 您必须解决这些问题才能使 IPsec 策略正常工作。

PAStore 引擎为“<策略名称>”在此计算机上应用永久性存储 IPSec 策略失败,错误代码为:<编号>。 IPsec 服务发现注册表中配置了永久策略,但无法成功地应用该策略的全部内容。 任何已应用的永久策略都将被删除,并且 IPsec 驱动程序将以编程方式设置为阻止模式(具有引导时免除),有一条独立的消息指示了这种情况。

PAStore 引擎为“<策略名称>在此机器上应用本地注册表存储 IPSec 策略失败,错误代码为:<编号>。 此消息表示 IPsec 服务在应用本地注册表中的本地 IPsec 策略时遇到了至少一个错误。 此消息可能表示该策略已损坏或者权限不正确。

PAStore 引擎为 DN“<CN=ipsecPolicy{GUID}”在此机器上应用 Active Directory 存储 IPSec 策略失败,错误代码为:<编号>。 IPsec 服务已找到 GPTIPsecPolicy 注册表项中的 DN 指定的域策略,但无法应用该策略。 此消息仅供参考,它通常是一个通知,表示移动客户端无法访问域控制器;在此消息后面,应该有一条消息指示成功地应用了缓存的策略(如果存在该策略)。 但是,此消息可能表示 GPO 正在提供不存在的或无法被读取的 IPsec 策略,或者该策略已损坏。

PAStore 引擎为“<策略名称>”在此机器上应用 Active Directory 存储 IPSec 策略的本地缓存副本失败,错误代码为:<编号>。 此消息表示 IPsec 服务知道应该指派域策略,但它无法应用从 Active Directory 检索到的策略。 现在,它在应用所指派的域策略在本地注册表中的缓存副本时至少遇到了一个错误。 此错误可能表示缓存已损坏或者权限不正确。 由于无法应用任何基于域的策略,所以这是一种十分严重的情况,可能会影响与其他隔离域成员的连接。 本地策略(如果已定义)将是优先顺序中的下一个策略。

PAStore 引擎在此机器上应用活动 IPSec 策略“<策略名称>”的一些规则失败,错误代码为:<编号>。 请运行 IPSec 监视器管理单元来进一步诊断此问题。 此问题通常与这里讨论的其他问题一起发生,如没有快速模式安全措施(供给)。

IPSec 服务获得此机器上的网络接口的完整列表失败。 这可能会对此机器的安全性构成潜在威胁,因为某些网络接口可能无法通过应用 IPSec 筛选器来获得希望的保护。 请运行 IPSec 监视器管理单元来进一步诊断此问题。 此消息替换 Windows 2000 中使用的若干个 IP Helper API 消息。 如果此错误是在添加或删除接口时发生的,或者是在连接状态更改时发生的(例如,不再处于无线网络覆盖范围之内),则此错误是良性的。 如果此错误是在从待机模式或休眠模式恢复时发生的,并且在恢复期间检测到存在另一网络接口配置,则此错误也是良性的。  

与 RRAS VPN 相关的策略配置问题

如本章前面有关第 1 层支持的内容所述,在某些组织中,RRAS 服务是 IPsec 策略冲突的常见根源。 本节说明 L2TP/IPsec VPN 服务器的内置 IPsec 策略与此解决方案中使用的域策略产生冲突的原因。 这种情况是筛选器重复问题的一个示例。

在下面的讨论中,我们使用 Woodgrove Bank 方案中使用的 IPsec 策略设计来说明问题。 但是,这些原理适用于许多企业范围的 IPsec 部署。

L2TP/IPsec 服务器的 IPsec 策略是由 RAS 管理器服务 (RASMAN) 自动生成的,它包含下列筛选器:

从任何 IP 地址到我的 IP 地址,UDP,源 1701,目标“任何”(入站)

从我的 IP 地址到任何 IP 地址,UDP,源“任何”,目标 1701(出站)

注:有关此策略的更多信息,请参阅知识库文章 248750“Description of the IPSec policy created for L2TP/IPsec”,网址为http://support.microsoft.com/?kbid=248750。

因此,用于控制对此服务器的 IKE 协商响应的主模式特别筛选器就是入站筛选器的地址部分:

从任何 IP 地址到我的 IP 地址 -> 证书身份验证

注意,“我的 IP 地址”的使用导致为 VPN 服务器上的每个 IP 地址扩展入站筛选器。 假定 VPN 服务器有一个外部接口 IP 地址用于 Internet 连接并有一个内部接口用于 LAN 连接,则 IKE 主模式专用入站筛选器是:

从任何 IP 地址到 <外部接口 IP 地址> -> 证书身份验证

从任何 IP 地址到 <内部 LAN 接口 IP 地址> -> 证书身份验证

第二个筛选器(用于内部 LAN 接口)比如下服务器和域隔离 IKE 主模式入站筛选器更为特定:

从任何 IP 到子网 -> Kerberos 身份验证

因此,当管理员使用受信任的客户端来管理 VPN 服务器时,它将对该 VPN 服务器的内部 IP 地址启动 IKE。 IKE 入站策略查找将与更特定的主模式筛选器匹配并使用 L2TP 的 IKE 主模式设置进行答复。 使用的将是证书身份验证,而不是使用此解决方案所使用的 Kerberos 身份验证。

如果 Internet VPN 客户端使用连接管理器客户端的隔离功能,就会发生第二种冲突情况。 隔离客户端必须传递“隔离密钥”给 VPN 服务器的内部 LAN IP 地址以结束隔离并获取对网络的完全 VPN 访问权限。 在此方案中,当便携式计算机启动时,将从缓存中应用 VPN 客户端的域 IPsec 策略。 在成功建立 VPN 隔离连接之后,将把一个内部 IP 地址指派给该 VPN 客户端。 客户端内部 IP 地址可以被域隔离 IPsec 策略中定义的其中一个子网筛选器(任何 <-> 内部子网)覆盖。 此筛选器是必需的,这样 VPN 客户端就可以通过 VPN 隧道对内部服务器以及可以访问的任何其他工作站执行通过 IPsec 进行身份验证的端到端访问。

但是,此解决方案中的子网筛选器将从客户端 VPN 隧道虚拟接口的内部 IP 地址对 VPN 服务器的内部 LAN 接口启动 IKE 协商。 由于服务器将响应接受证书身份验证,这与域和服务器隔离方案所使用的策略不兼容,所以 IKE 主模式协商将失败。 即使策略允许进行证书身份验证,来自客户端的 IKE 快速模式将提供用于所有通信流的筛选器,并且 VPN 服务器将使协商失败,这是因为提供的筛选器太一般化了。 VPN 服务器将仅接受 L2TP 专用快速模式筛选器:UDP 源 1701,目标“任何”或者 UDP 源 1701,目标 1701。

可以使用下列选项来解决 RRAS 服务器 L2TP/IPsec 策略与隔离策略之间的冲突:

在免除列表中包括 RRAS 服务器内部 LAN IP 地址。

在 VPN 服务器上禁用 L2TP 端口。 仅使用 PPTP。

通过使用 RASMAN 的 ProhibitIPsec 注册表项,禁用 L2TP 的自动 IPsec 策略。 为 L2TP 手动自定义 IPsec 策略配置,以便仅将外部 IP 地址用于 UDP 1701 通信流的证书身份验证,并且仅将内部 IP 地址用于所有域隔离通信流的 Kerberos 身份验证。

注:有关此配置的更多信息,请参阅知识库文章 240262“如何使用预共享密钥身份验证配置 L2TP/IPSec 连接”,网址为 http://support.microsoft.com/kb/240262。

在此列表中,第一个解决方案最为简单,它使用 IPsec 来免除 RRAS 服务器的内部 NIC。

IKE 疑难解答

由于网络筛选功能不允许 UDP 500 或 IPsec 协议数据包,所以 IKE 和 IPsec 在最初部署时常常会失败。 因此,建立用于进行测试的静态 IP 工作站或服务器是很有益的,在该工作站或服务器上,将指派一个简单的策略,如使用预共享密钥的服务器(请求)策略的预定义示例。 必须启用审核以捕获 IKE 审核事件。 一个默认域 IPsec 策略被部署到所有使用同一个预共享密钥进行身份验证的域成员,该策略包含一个规则,该规则带有一个用于发往测试计算机 IP 地址的所有通信流(包括 ICMP)的筛选器。

然后,部署一个域登录脚本以执行 ping <testserver>
nbtstat –n <testserver>,这将触发从所有域成员对测试服务器进行 IKE 协商。 通过对 IKE 主模式成功审核中的 IP 地址进行分析和总结,您可以确定是否所有计算机都在接收策略并验证是否网络中的所有区域都可以使用 IKE 和 IPsec 协议来访问测试计算机。

更高级的测试是通过从测试服务器对位于每个区域的计算机使用 ping –l 5000 <IP address> 来确认 IPsec 分段封装操作对每个区域都工作正常。 –l 5000 选项导致 Ping 创建 5000 字节的 ICMP 数据包有效负载。 这个完整的 IP 数据包将被 IPsec 协议封装,接着被 IP 层分段,然后才通过线路发送。 目标位置必须接收所有片段,然后发回由相同数目的片段组成的答复。 经验表明,拥塞的设备或者作为不同速度网络(例如,1 GB 和 100 MB 以太网)之间的边界的设备在传递片段时可能会发生问题。 同样,驻留在不同 MTU 链路(如异步传输模式 (ATM)、光纤分布式数据接口 (FDDI) 和令牌环)上的主机要求 ICMP PMTU 消息为受 IPsec 保护的 TCP 数据包正确地发现网络路径 MTU。 有关不同网络的 MTU 默认值的信息,请参阅知识库文章 314496“不同网络拓扑的默认 MTU 大小”,网址为 http://support.microsoft.com/kb/314496。

IKE 协商疑难解答

对于 IKE 来说,由于错误可能只是在某些情况下才会发生(例如,仅当从通常作为响应方的计算机启动 IKE 快速模式协商时),所以疑难解答可能难以进行。 错误也可能是由身份验证系统中的故障(例如任何 Kerberos 协议错误,或者将不兼容的策略设计或预先存在的策略与域策略合并时)导致的。 IKE 故障会导致发生故障的计算机不再参与 IKE 协商,另一台协商计算机通常会耗尽它的重试限制并超时。 如果 IKE 失败,请尝试研究故障并捕获日志,而不进行任何更改。 标准审核可以动态地启用,而不必更改 IPsec 配置或服务的运行状态。 但是,在 Windows 2000 中,必须重新启动 IPsec 服务才能在 Oakley.log 文件中进行详细 IKE 记录,在 Windows XP SP2 和 Windows Server 2003 中,可以根据需要通过命令行启用和禁用 IKE 记录。

在某些情况下,可能有必要停止并重新启动 IPsec 服务才能研究网络通信流并从干净的状态捕获 Oakley.log 文件结果。 当手动停止 IPsec 服务或者作为计算机重新启动或关机过程的一部分而停止 IPsec 服务时,IKE 将尝试发送删除消息以便在当前连接的所有对等端上清除 IPsec SA 状态。 有时,操作系统会在 IKE 完成发送删除消息给所有活动对等端之前禁用发送数据包的能力,这将导致对等端上的 IPsec SA 状态保持不变。 发生这种情况时,对等端可以相信它安全地连接到正在重新启动的计算机。 重新启动后,如果计算机未对它的对等端发起新的 IKE 协商,该对等端就必须等待 5 分钟以使 IPsec SA 超时,然后才尝试重新建立那些 SA。 要重新建立 SA,首先尝试进行一分钟的快速模式协商,然后尝试发起 IKE 主模式协商。

Windows 2000 以后的每个版本都对 IKE 记录进行了改进。 本节阐述的事件适用于 Windows XP 和 Windows Server 2003,尽管 Windows 2000 事件在性质上是相似的。

在尝试确定 IKE 协商失败的原因时,建议您从 Windows 安全日志入手。 要查看 IKE 事件,必须在组安全策略设置“审核登录事件”中启用审核以了解成功或失败情况。启用审核后,IKE 服务将创建审核条目并提供协商失败原因说明。 但是,IKE 协商失败说明几乎总是作为事件 547 故障报告的,而同一错误消息有几个可能的原因。 下列各节对事件 547 故障列表及潜在原因作了详细描述。

在 Windows XP SP2 和 Windows Server 2003 中,可以通过 DisableIKEAudits 注册表项来禁用所有 IKE 审核。 务必在所调查的计算机上检查此值。 如果 IKE 审核生成了过多的成功或失败事件,从而导致无法有效地监视其他登录/注销类别的事件,则可以将 IKE 审核禁用。

IKE 审核事件和日志详细信息通常报告了错误代码值。 Microsoft MSDN® 的“System Code Errors (12000-15999”页面提供了这些错误代码值的描述,网址为 http://msdn.microsoft.com/library/en-us/debug/base/
system_error_codes__12000-15999_.asp。

进行 IKE 协商疑难解答要求深入了解 IPsec 策略设计、IKE协商过程和 IKE 故障事件的预期行为。 本节尝试仅对与 Woodgrove Bank 域隔离方案相关的最常见事件加以说明。 本节未阐述所有 IKE 审核事件或失败条件。

在充分了解 IKE 协商过程后,应该至少从通信的一端获取网络跟踪(如有可能)以确定 IKE 中的问题,然后再尝试收集 Oakley.log 文件。 服务器和域隔离方案中已部署的服务器应该能够使用网络监视器来捕获跟踪。

Oakley.log 文件能够提供最详细的记录,协商的两端都可能需要此文件(并且时间需同步)。 但是,如果启用此日志,IKE 协商速度就会变慢,这将改变计时条件并导致所有现有状态在服务重新启动以重新读取注册表项(在 Windows 2000 和 Windows XP SP1 中需要这样做)时丢失。 当前,没有已发布的指南对 Oakley.log 文件作了解释。 为了实现本指南的目标,这样的解释被认为是第 3 层技能集合的一部分。 由于篇幅有限,这里仅提供了几个错误的日志详细信息简要摘录。 要获取有关解释 Oakley.log 文件的帮助,请与 Microsoft 产品支持联系。

为 IKE 维护了下列 4 个详细日志文件:

Oakley.log。 IKE 的当前日志,限长 50,000 行。

Oakley.log.bak。 在 Oakley.log 中累积了 50,000 行之后,将创建此文件并开始一个新的空 Oakley.log 文件。 只要 IPsec 服务不断运行,此文件就会根据需要被更新的 Oakley.log 文件覆盖。

Oakley.log.sav。 当 IPsec 服务启动时,先前的 Oakley.log 文件将使用此名称保存。

Oakley.log.bak.sav。 当 IPsec 服务启动时,先前的 Oakley.log.bak 文件将使用此名称保存。

在疑难解答期间,常见的一个错误是两台用于进行记录和捕获网络跟踪的计算机上的时间不同步。 这使得难以进行日志关联,尽管并非不可能进行日志关联。 应该使用 ISAKMP 标头 cookie 和 IKE 快速模式消息标识字段来对 IKE 消息与网络跟踪中的数据包之间的关联进行反复检查。

期望的 IKE 行为

如果网络导致发起的 IKE 主模式协商无法到达期望的目标 IP 地址,就无法对受 IPsec 保护的通信进行协商。 如果发起方未被配置为“回退到使用明文”,则访问目标失败将作为审核事件 547 出现在安全日志中,并且包含下列其中一个文本条目:

对等客户没有响应

协商超时

完成建立之前,IKE SA 已被删除  

但是,对于域隔离客户端来说,如果它们的策略允许“回退到使用明文”,这种情况就可能不作为故障出现。 建立软 SA 时,将创建 IKE 主模式成功事件 541。 541 事件指示软 SA 的出站 SPI 是“0”,所有算法都显示为“无”。 以下示例显示了这些参数在 541 事件中的外观:

ESP Algorithm None
HMAC Algorithm None
AH Algorithm None
Encapsulation None
InboundSpi 31311481 (0x1ddc679)
OutBoundSpi 0 (0x0)
Lifetime (sec) <whatever is configured for QM lifetime>
Lifetime (kb) 0

:发往同一目标 IP 地址的软 SA 事件将具有不同的时间戳和不同的入站 SPI 值。

每当两台计算机在它们之间是否存在活动 IKE 主模式方面变为不同步时,连接就会出现一分钟的延迟。 如果一台计算机相信它们之间存在活动 IPsec SA 对,而另一台计算机(例如服务器)已删除了这些 SA 并且未发起快速模式重新生成密钥,就会出现 5 分钟的延迟。 Windows 2000 IKE 支持单一删除消息,这些消息有时会丢失。 Windows XP 和 Windows Server 2003 以多条删除消息的形式添加了对“可靠”删除功能的支持,作为抵御被丢弃的数据包的防护措施。

这种情况的最常见情形是域隔离便携式计算机用户从扩展坞中弹出便携式计算机以参加会议。 扩展坞具有有线以太网连接,卸下该网络接口的操作要求删除与该接口相关联的所有筛选器(如果那些筛选器是从“我的 IP 地址”扩展的筛选器)。

但是,在域隔离解决方案中,没有任何带有协商操作的筛选器使用“我的 IP 地址”- 它们全都是“任何 IP 地址 <-> 子网”筛选器。 因此,由于地址每次更改时均未删除这些筛选器,所以便携式计算机上的 IPsec SA 和 IKE SA 保持活动状态。 如果筛选器是从“我的 IP 地址”扩展的,则当 IP 地址消失时,这些筛选器将被删除。

每当在 IPsec 驱动程序中删除任何类型的筛选器时,驱动程序将通知 IKE 还必须删除所有使用该 IP 地址的 IKE SA 和 IPsec SA。 IKE 将尝试为这些 SA 发送删除消息并以内部方式删除它们。 这些删除消息将包含相同的已用于 IKE SA 的源 IP,尽管发送删除消息时在所连接的接口上可能存在另一个源 IP。 如果 ISAKMP 标头 cookie 对被识别并且数据包上的加密检查有效,则源 IP 地址对远程计算机没有意义。 但是,由于在断开连接(弹出便携式计算机)后的几秒钟内没有网络连接,所以通常不会发送删除消息。

在这种特定情况的“任何 IP 地址 <-> 子网”筛选器中,绝对不会删除筛选器,这意味着不会立即删除 IKE 和 IPsec SA。 同时,IPsec SA 在先前连接的远程计算机上超时,并且 IKE 快速模式删除被发送到便携式计算机的旧地址。 在这些远程计算机上,IKE 主模式 SA 继续存活一段事件(默认时间为 8 小时),但是在这段时间内,随时可以因为 IKE 已知的内部原因而删除它们。 当然,便携式计算机在它的旧 IP 地址上接收不到 IKE SA 删除消息。 当便携式计算机最终重新连接到扩展坞时,它再次接收到相同的 IP 地址。 文件共享、电子邮件客户端和其他应用程序通常重新连接到相同的目标地址。 但是,在便携式计算机与这些远程目标之间,IKE 状态可能有区别。 如果便携式计算机仍处于 IKE 主模式,它就会尝试进行 IKE 快速模式协商。 快速模式使用已被远程对等端删除的加密状态,因此它不识别这些消息并且不答复。 在便携式计算机上,IKE 在一分钟之后将终止重试限制,尝试新的 IKE 主模式协商,现在该协商将成功。 因此,便携式计算机用户在重新连接至远程资源时可能会注意到一分钟的延迟。 Microsoft 希望将来能够在所有支持 IPsec 的 Windows 版本更新中改进这种行为。

IKE 协商可能会由于各种原因而报告超时。 当任何 IKE 协商步骤(“回退到使用明文”除外)由于达到重试限制而失败时(IKE 通过“完成建立之前,IKE SA 已被删除”事件终止协商除外),都会发生“协商超时”事件。 这两个事件在本质上是相同的。 对于移动客户端来说,在常规操作期间,这些事件是常见的、良性的并且是在预料之中的。这些客户端在下列事件发生时频繁并且快速地更改网络连接状态:

用户将便携式计算机插入扩展坞以及从扩展坞中卸下便携式计算机

用户拔出网线接头

便携式计算机休眠或进入待机模式

计算机离开无线连接覆盖范围

VPN 连接断开

PCMCIA 网卡在处于连接状态时被弹出

对于远程计算机来说,任何这些事件都将使对等计算机表现为与网络断开连接。 远程计算机将尝试重新生成密钥或重新进行协商,直到 IKE 协商步骤超时为止。

Windows Server 2003 对协商超时故障进行了增强,它通过确定上一个成功的协商步骤来确定 IKE 协商发生超时的位置。 这些事件也可能是由于协商不具有 NAT-T 能力的 IKE 时存在网络地址转换 (NAT) 而导致的。 但是,如果远程对等端由于某种原因而使 IKE 协商失败,IKE 协商也会超时。

因此,对于所有协商超时以及“完成建立之前,IKE SA 已被删除”事件,第 2 层支持应该通过在远程计算机上检查直到 IKE 记录超时前一分钟为止发生的 547 故障审核事件来确定该计算机是否确实使协商失败。

IKE 协商成功事件

如果 IKE 协商成功,则 IKE 主模式 SA 将显示在 IPSec 监视器 MMC 管理单元中,并且能够通过命令行查询工具显示。

显示当前 IKE 主模式 SA 列表

对于 Windows 2000:

ipsecmon.exe, netdiag /test:ipsec /v 

:此命令仅显示 IPsec SA,而不显示 IKE 主模式 SA

对于 Windows XP:

IPsec monitor snapin, ipseccmd show sas 

对于 Windows Server 2003

注:为了增强可读性,此命令已分为多行。 但是,在系统上键入此命令时,必须在一行上输入它,不能换行。

IPsec monitor snapin, netsh ipsec dynamic 
show [mmsas | qmsas]

当启用了审核时,成功的主模式和快速模式 SA 将在安全日志中生成下列事件。

541. 已建立 IKE 主模式或快速模式

542. 已删除 IKE 快速模式

543. 已删除 IKE 主模式

IKE 主模式参考日志条目

要确定主模式交换是否发生了问题,请在计算机事件日志中查找记录的下列事件:

表 7.5:IKE 主模式参考日志消息

日志文本描述

新策略导致使用旧策略创建的 SA 失效

这是一条 Windows 2000 消息,表示 IPsec 策略更改导致删除了当前 IKE 或 IPsec SA。 此错误是良性的。 将根据使用新的 IPsec 策略的当前通信流来创建新的 IPsec SA。

IKE 有大量的未决安全关联建立请求,并且已开始拒绝服务防止模式

此情况可能是正常的,原因是高机器负载,和/或有大量客户端连接尝试。 也可能是对 IKE 的服务攻击拒绝的结果。 如果这样,通常会审核许多到哄骗 IP 地址的失败的 IKE 协商。 否则,计算机负载将非常重。
表示 IKE 认为它已被 IKE 主模式 SA 建立请求淹没,因此它将要丢弃许多这些 SA 建立请求,以作为拒绝服务攻击响应策略的一部分。

IKE 已从拒绝服务防止模式恢复,并且已继续进行正常操作

IKE 已从拒绝服务攻击状态恢复并已继续进行正常操作。

存在这些条目并不表示发生了通信故障。 这些条目仅供参考,它们可用来提供附加的信息以帮助您确定问题的真实原因。

IKE 主模式协商失败事件 #547

当 IKE 主模式协商失败时,可能会发生下列 IKE 失败事件:

对等客户没有响应。 在对未使用 IPsec 并且不是免除列表成员的计算机进行出站连接时,发生此事件是正常的。 但是,第 2 层支持应该提防导致 IKE 协商被阻止的连接问题,该问题也会生成此事件。

未配置任何策略。 如果源 IP 地址是内部子网内的地址,则此事件指示了一个问题,此外,此事件也可能指示筛选器集不匹配。 否则,可能是计算机没有规则可用来与某些地址范围或子网进行协商。 那些子网中的计算机可以尝试发起 IKE,但由于未配置任何策略,所以不会得到答复。

IKE 安全属性不可接受。 在进行了正确配置的系统上,不应该会发生此事件。 请完成“验证 IPsec 策略是否正确”一节中的步骤来进行调查。

下列任何“协商超时”消息都可能是由于前面讨论的原因而引起的。 这些消息也可能表示远程计算机使 IKE 协商失败。 通常,第 2 层支持侧重于调查远程计算机上的 IKE 失败(而不是对于已断开连接的计算机来说极为常见的协商超时)以及策略设计不兼容性,对于后者,IKE 主模式协商或 IKE 快速模式协商的响应方找不到特定的筛选器来与传入请求相匹配。

协商超时

协商超时 - 已处理第一个 (SA) 负载响应方。 增量时间 63

协商超时 - 已处理第二个 (KE) 负载发起方。 增量时间 63

协商超时 - 已处理第二个 (KE) 负载响应方

IKE 快速模式审核失败 (547)

当 IKE 快速模式协商失败时,可能会发生下列 IKE 失败事件:

没有配置任何策略 - 已处理第三个 (ID) 负载发起方

安全关联协商由于属性不匹配而失败

一般处理错误

未能从 IPsec 驱动程序中为入站 SA 获取新的 SPI

IPsec 驱动程序使 Oakley 协商失败,不存在筛选器

未能将安全关联添加到 IPsec 驱动程序中

协商超时

对于设计正确的 IPsec 策略来说,在典型的操作负载环境下,IKE 快速模式不应该会失败。 如果接收到这些错误中的任何错误,第 2 层支持应该首先执行“验证 IPsec 策略是否正确”一节中的步骤。 然后,第 2 层支持应该尝试使这些事件与不寻常的性能状况(如 CPU 利用率达到 100%,或者内核内存量非常低)相关联。

注意,如果计算机由于前面说明的任何原因而不再使用它的旧 IP 地址,则由于协商超时而造成 IKE 快速模式失败是正常的。

由身份验证导致的 IKE 故障的疑难解答

下列消息与 IKE 身份验证失败相关:

指定的目标是未知的/没有权限,无法进行身份验证

指定的目标未知或不可达 - 已处理第一个 (SA) 负载发起方。 增量时间 0

IKE 身份验证凭据不可接受

登录尝试失败

无法使用 Kerberos 进行身份验证

IKE 找不到有效的机器证书

前两条消息表示无法使用远程计算机的 Kerberos 身份来为远程计算机获取服务票证。 存在这种情况的原因是没有域信任或者无法访问域控制器。

如果入站 IKE 协商由于“从网络访问这台计算机”设置而失败,则强制实施访问权限一端上的 IKE 协商将报告 547 事件“无法使用 Kerberos 来进行身份验证”,如前面的内容所述。 该事件并未明确指出该问题就是检查“从网络访问这台计算机”权限时发生的故障,因此必须从服务器获取 Oakley.log 文件以查看所生成的特定错误。 应该对 IKE 发起方的组成员身份进行调查,以了解它是否确实是授权组的成员。 如果该计算机是有权进行访问的组的成员,则可能是该计算机没有能够反映新成员身份的 Kerberos 票证。 此外,也可能是该计算机无法获取正确的 Kerberos 票证。 完成本章前面“对域控制器验证连接和身份验证”一节所讨论的过程。

与应用程序相关的问题的疑难解答

本节讨论应用程序设计如何与 Microsoft Windows 中 IPsec 的使用进行交互。 IPsec 策略设计者应该了解这些影响,支持人员应该知道这些影响以便可以帮助快速地进行问题分类和确定。 IPsec 策略的应用对应用程序在很大程度上应该是透明的。 然而,在某些情况下,指派 IPsec 策略或对通信流进行保护可能导致应用程序的行为发生变化。 下列各节在 Woodgrove Bank 域隔离解决方案的上下文中对这些情况加以着重说明。

允许 ICMP,但是 TCP 和 UDP 需要 IPsec

某些应用程序使用 ICMP 回应请求 (Ping) 消息来确定目标地址是否可达。 例如,在此解决方案中,IPsec 不保护 ICMP 通信流,因此应用程序可以接收到来自目标的 ICMP 响应。 然而,当 IKE 协商失败时,应用程序可能无法使用受 IPsec 保护的 TCP 和 UDP 通信流来连接到目标。

初始连接延迟

与 TCP 三向握手或未经身份验证的 Nbtstat 单数据包查询和响应相比,完成 IKE 协商需要进行的处理以及所需时间要多得多。 期望目标进行快速 TCP 或 UDP 连接响应的应用程序可能会认为目标未进行响应并因而采取其他操作,如报告错误或尝试连接到备用目标。 使用 Kerberos 身份验证进行的 IKE 协商通常能够在 1 至 2 秒钟内成功完成。 然而,此时间取决于许多因素,尤其是两台计算机的 CPU 利用率以及网络数据包丢失情况。 在允许不加保护地发送 TCP 握手的第一个数据包之前,“回退到使用明文”始终要求等待三秒。

应用程序在等待网络响应时挂起

某些应用程序被编写成假设连接时间或接收错误消息的时间都非常短暂。 这些应用程序将等待连接完成(等待套接字绑定操作完成),然后才在用户界面上显示另一些内容。 当此应用程序的通信流受 IPsec 保护时,该应用程序可能会在成功连接期间出现暂挂挂起现象。 该应用程序可能会一直挂起,直到它终止或者由于 IKE 协商失败或 IPsec 阻止筛选器导致连接不成功而遇到其他不寻常的错误为止。 网络套接字层不认识 IPsec 筛选器,也不知道 IKE 正在为通信流协商安全性。 应用程序通常将这些情况看作是由于远程主机关机或网络故障而导致的。 然而,应用程序也可能将无法访问域控制器看作是由于目标计算机不可达或连接被拒绝而引起的。

内核模式网络数据包处理受影响

当 IPsec 对通信流进行保护时,涉及网络驱动程序或其他内核级别数据包处理的应用程序可能无法正常工作。 这些应用程序可能会对数据包进行修改,这样将会导致 IPsec 丢弃该数据包。 另外,IPsec 更改可能会干扰应用程序,这可能会导致系统错误(蓝屏)。

从隔离域中的主机进行的网络扫描受影响

对于快速探测网络上的远程 IP 地址或打开端口的基于主机的工具来说,如果 IPsec 尝试对这些工具的探测通信流进行保护,这些工具的运行速度就会慢得多。 通过在几秒钟或几分钟内对数以百计的 IP 地址发起 IKE,探测通信流可能会在本地主机上导致拒绝服务。 某些基于 SNMP 的工具依赖于被发送到充当事件收集器的不受信任主机的 SNMP 陷阱事件。 即使允许 IPsec“回退到使用明文”,IPsec 驱动程序也可能会在建立软 SA 之前将出站 SNMP 陷阱数据包丢弃。 同样,某些基于 UDP 的应用程序(如 NTP 和 Windows 域控制器定位器)在接收答复时仅等待 3 秒钟,这将导致应用程序故障或者错误地报告目标不可达。

Winsock 分层服务提供程序问题

某些合法的应用程序(如个人防火墙)以及一些恶意应用程序(如间谍软件)都可能因为插入其自己的网络通信流检查功能而引起问题,它们被称为 Winsock 分层服务提供程序 (LSP)。Microsoft 实施的 IPsec 的 IKE 组件使用了一个扩展的 Winsock API 函数,其函数指针是通过调用 WSAIoctl() 确定的。 如果此函数调用未被允许通过任何已安装的 LSP,IKE 就无法监视必需的 UDP 端口。 在 Windows Server 2003 中,IPsec 将这种情况解释为组件故障,从而强制执行必需的安全策略并采取防御措施。 将调用“无法执行安全模式”,并且 IPsec 驱动程序将进入阻止模式。 管理员必须使用桌面登录来进行登录以停止 IPsec 服务并恢复连接。 如果 IPsec 服务未对停止请求作出响应,则必须将 IPsec 服务配置为禁用并重新启动计算机。

即使 IKE 看起来正确地完成初始化,但是计算机发送和接收 IKE 和 IPsec 协议的能力可能已被 LSP 或其他已安装的第三方程序阻止。

对于第 2 层支持来说,Winsock LSP 疑难解答包括确定是否存在 LSP。 第 3 层支持将着手进行进一步的调查以确定安装 LSP 的应用程序,然后重排它们的顺序或者将其卸载以了解 IPsec 服务或 IKE 是否不再出现问题。 用于检测 Winsock LSP 的工具包括:

Sporder.exe。 Windows 平台软件开发工具包 (SDK) 的 Winsock 2.0 部件提供的用于查看 LSP 的小程序。

Netdiag /debug

第三方 IPsec VPN 客户端

当安装第三方 IPsec 实施来作为远程访问 VPN 客户端的部件时,可能会出现许多问题。 通常,这些客户端将禁用 IPsec 服务,并且不会与本地 Windows IPsec 冲突。 然而,对于此解决方案中的受信任域成员来说,本地 IPsec 服务是必需的。 因此,第三方 IPsec 实施可能会因为下列原因而产生冲突:

两个 IKE 实施都可能需要 UDP 端口 500。

两者的 IPsec 内核数据包处理都可能需要 ESP 协议。

作为客户端部件安装的 Winsock LSP 功能。

VPN 客户端提供的防火墙功能。

导致本地 IKE 和 IPsec 所封装的数据包无法通过第三方 IPsec 隧道的分层。

下列信息最好由 VPN 供应商提供:他们是否支持启用本地 Windows IPsec 服务,以及是否支持受 IPsec 保护的传输模式通信流端到端地通过它们的远程访问连接。 在某些情况下,VPN 供应商网关支持 Windows 2000 和 Windows XP PPTP 以及 L2TP/IPsec VPN 客户端。 本地 Windows VPN 客户端与端到端地通过 VPN 隧道的 IPsec 模式兼容。

第 3 层疑难解答

如果第 2 层疑难解答未能解决问题,则需要其他专业人员来进行问题分析并找到解决方案。 此专业人员被看作第 3 层支持。 在许多情况下,此支持是由雇用的 IPsec 专家或支持组织(例如 Microsoft 自己的产品支持服务)提供的。

第 3 层 IPsec 支持需要深入了解 IPsec 操作和 Microsoft TCP/IP 堆栈。 第 3 层支持人员需要接受有关 IPsec 以及 IPsec 在服务器和域隔离方案中的使用方面的重要培训。 第 3 层人员获得的技能将使他们能够负责对较低层人员进行培训以及开发支持文档,如技术摘要、白皮书、支持指南、常见问题以及有关 IPsec 结构和分类的信息。 第 3 层支持也可以负责开发和记录灾难恢复方案。

请求 Microsoft 产品支持服务提供帮助

如果本章描述的疑难解答过程未能帮助您解决问题,或者您的组织机构没有足够的专业人员来使用高级疑难解答技术,您可能需要将该问题汇报给 Microsoft 产品支持服务。 在请求产品支持服务提供帮助之前,您应该收集尽可能多的诊断信息(例如通过日志和网络监视收集信息),这很重要。 使用此列表来收集一些信息,第 3 层支持或 Microsoft 产品支持服务在分析问题时将需要这些信息。

每台计算机的入站和出站身份验证及授权的安全需求。 应该有简要描述来描述计算机上的组策略和 IPsec 配置如何满足这些需求。

方案示意图,此图应该显示源和目标计算机的名称、收集日志文件时它们具有的 IP 地址以及操作系统版本(包括 Service Pack 信息)。 并且,指示 DNS 服务器、WINS 服务器以及域控制器的 IP 地址。

当 IPsec 策略处于活动状态时从每一端获取的网络监视器通信跟踪,此跟踪最好是同时进行的,这样就可以方便地使两个跟踪文件中的数据包相互关联。 如有可能,网络跟踪应该包括每台计算机上的所有入站和出站通信流,以便可以标识身份验证请求、DNS 查询以及其他相关通信流。 并且,如果当 IPsec 策略处于活动状态时通信失败,并且当 IPsec 策略被禁用或服务停止时通信成功,则还应该提供 IPsec 不活动时的网络通信流跟踪。 这些系统的系统时间应该同步,这非常重要,只有这样才能使日志与跟踪文件相关联。

对于 Windows 2000、Windows XP 和 Windows Server 2003 来说,
netdiag /debug >netdiag-debug-computername.txt 日志输出是在捕获网络跟踪刚好完成前或刚好完成后运行的。 (Netdiag 生成大量的网络通信流,不需要对这些通信流进行网络跟踪。)对于 Windows XP 和 Windows Server 2003 来说,还需运行
portqry -v -local >portqry-v-computername.txt.

在发生问题和记录网络监视器跟踪时从通信双方收集的 IKE Oakley.log 文件。 这些文件的文件名称应该体现出计算机名称。 如果涉及 Windows RAS 或 VPN 客户端,就应该使用 RASDIAG 工具来收集信息。

收集 Oakley.log 文件和网络跟踪时每台计算机上的完整系统日志、安全日志以及应用程序日志。

捕获 Oakley.log 和网络跟踪时创建的任何组策略专用日志文件。

每台计算机的 IPsec 策略的详细信息。 如果可以方便地保存对每台计算机应用的 IPsec 策略,则应该包括它们。 然而,计算机的活动 IPsec 策略通常由几类 IPsec 策略配置组合而成,而不仅仅是域策略或本地策略。 用于分析计算机活动策略的最佳格式是 IPsec 监视器 MMC 管理单元中的 IKE 主模式特别筛选器列表和 IKE 快速模式特别筛选器列表。

创建这些筛选器的格式化文本文件

1.

在左窗格中,右键单击树中的“IKE 快速模式特别筛选器”节点。

2.

选择“导出列表”。

3.

将制表符分隔文本文件保存为 IKE-qm-<specific-computername>.txt,或者使用包含计算机名称的类似命名约定进行保存。

您可以将包含所有筛选器详细信息的制表符分隔文本文件导入到电子表格或字处理文档中。

总结

本章提供了有助于第 1 层支持(咨询台人员)和第 2 层支持(IT 专业网络支持人员)了解如何对常见 IPsec 通讯问题进行疑难解答的过程的详细信息。 因为 IPsec 和网络安全是如此的复杂,以致无法列举所有的变化,所以不可能提供有关所有潜在错误的信息。 在合适的时候,本章作者已将可能的选项简化以使本向导侧重于本向导所描述的服务器和域隔离环境类型最有可能遇到问题的那些领域。

本向导附带提供的示例脚本已在 Woodgrove Bank 方案测试实验室实施中进行测试,证明有效。 然而,这些脚本设计成可被自定义以满足组织机构的需求,因此它们不受 Microsoft 支持。

读者可以明显看出 IPsec 疑难解答在技术上相当复杂,并且需要除 IPsec 以外的许多技术领域(包括网络、Active Directory 和组策略)的技能。 不过,本章提供的信息应该使读者有可能对除最不引人注意的问题以外的所有可能影响服务器和域隔离方案的问题进行疑难解答。

对于那些希望将知识水平提高到第 3 层支持的读者来说,下一节引用的附加阅读材料足以令您钻研数年了!

更多信息

有关 IPsec 的详细背景信息,请参阅 Windows Server 2003 技术参考的“How IPsec Works”,网址为 www.microsoft.com/resources/documentation/
WindowsServ/2003/all/techref/en-us/w2k3tr_IPsec_how.asp

有关对 TCP/IP 问题进行疑难解答的详细信息,请参阅下列技术参考资料:

“TCP/IP in Windows 2000 Professional”,网址为 www.microsoft.com/resources/documentation/Windows/
2000/server/reskit/en-us/prork/prcc_tcp_slnb.asp

Windows XP 资源工具包的“TCP/IP Troubleshooting”一章,网址为 www.microsoft.com/resources/documentation/Windows/
XP/all/reskit/en-us/prcc_tcp_gfhp.asp

如何解决 Windows XP 的 TCP/IP 连接问题”,网址为 http://support.microsoft.com/?kbid=314067

“Windows Server 2003 TCP/IP 故障排除”,网址为 www.microsoft.com/technet/prodtechnol/windowsserver2003/
operations/system/tcpiptrb.mspx

有关专门讨论 Windows 2000、Windows XP 和 Windows Server 2003 中的 IPsec 疑难解答的联机帮助和资源工具包文档,请参阅下列参考资料:

Windows 2000 基本 IPSec 疑难解答”,网址为
http://support.microsoft.com/?kbid=257225

Microsoft Windows 2000 高级文档,网址为
www.microsoft.com/windows2000/en/advanced/help/
sag_ipsectrouble.htm?id=3352

在 Windows XP 中解决基本 L2TP/IPSec 问题”,网址为
http://support.microsoft.com/?kbid=314831

Windows Server 2003 帮助 – IPsec 疑难解答工具,网址为
www.microsoft.com/technet//prodtechnol/
windowsserver2003/proddocs/standard/
sag_ipsec_tools.asp?frame=true#iketrace_enable

Windows 2000 TCP/IP Implementation Details”白皮书中的体系结构概述图,网址为
www.microsoft.com/windows2000/
techinfo/howitworks/communications/networkbasics/
tcpip_implement.asp

“Windows 2000 Network Architecture”,图 B.1,网址为
www.microsoft.com/resources/documentation/windows/
2000/server/reskit/en-us/cnet/cnad_arc_jypf.asp

“How TCP/IP Works”,网址为 www.microsoft.com/resources/documentation/
WindowsServ/2003/all/techref/en-us/w2k3tr_tcpip_how.asp

“How IPSec Works”,网址为 www.microsoft.com/resources/documentation/
WindowsServ/2003/all/techref/en-us/w2k3tr_ipsec_how.asp

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页