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

关注

VIP免费原创最新推荐文章于 2026-07-15 12:50:44 发布 1.2w 阅读 AI 写同款· GEO 优化 ›

IPSec 域间策略常见问题当对IPSec进行调试时，如果IPSec的统计信息比较多不便于查看，可以执行以下操作清除IPSec统计信息。如果用户需要对安全策略重新配置，为了使新配置的安全策略生效，可以执行下列操作清除IPSec安全联盟。如果用户需要对安全策略重新配置，为了使新配置的安全策略生效，可以执行下列操作清除IKE安全联盟。因为此时只有USGA配置了域间安全策略，USGC没有配置。假设其他配置都正确，只有域间安全策略配置异常情况下。因为此时只有USGA和USGC都配置了域间安全策略。阅读详情

本章提供有关如何对 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 层：咨询台。咨询台既是与域相关的客户端问题的入口点又是与域无关的客户端问题的入口点。咨询台还支持由中央 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 层支持。例如，咨询台应该能够按照以下方式确定问题的各种类型：

•	网络连接性。使用 ping 和 tracert 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 无法与目标计算机进行通信时的疑难解答过程查看大图

注：此流程图假定呼叫者计算机正在运行 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 层支持人员处理完这些流程图之后，问题将具有下列其中一种状态：

•	问题已确定，并已解决。此状态表示问题已被解决，并且问题的原因已明确。
•	问题未确定，但已解决。此状态表示问题已被解决，但问题的原因未完全明确。例如，通过进行 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 设置。
•	检查计算机和用户的组成员身份。

•

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

•

身份验证失败标识。

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

•

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