使用 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 層疑難解答 | |
| 第 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 行為的其他特定于計算機的問題包括：
由于這些類型的問題，某些計算機可能會遇到連接性故障，而其他計算機則不會。 注：本章討論的所有 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 支持的支持人員應該具備下列領域的技巧和經驗：
| ? | 組策略。 了解應該指派哪些策略以及如何指派那些策略，并且能夠執行下列任務：
| ||||||||
| ? | 有關機構使用的第三方軟件的經驗。 | ||||||||
| ? | 身份驗證失敗標識。
| ||||||||
| ? | 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 組件的信息：
| ? | 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 | 查看已指派的 IPsec 策略 | 是 | 是 | 否** |
netdiag | 顯示活動 IPsec 策略、篩選器和快速模式統計信息 | 是 | 是* | 否** |
netdiag | 顯示活動 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? | Windows 2000 – 資源工具包；對于 Windows?XP 和 Windows Server? | 檢查組策略的上次應用時間 | Windows?2000 資源工具包工具幫助、Windows?XP 幫助以及 Windows?Server? |
策略的結果集 (RSoP) MMC | Windows Server? | 包含在操作系統中 | 查看計算機的 IPsec 策略或者組策略容器成員的 IPsec 策略 | Windows?Server? |
Srvinfo | Windows?2000, Windows Server? | Windows 2000?和 Windows Server? | 服務、設備驅動程序和協議信息 | Windows?Server? |
PortQry | Windows?2000, Windows Server? | Windows Server? | 網絡端口狀態報告 | http://support. |
NLTest | Windows?2000, Windows Server? | 支持工具 | 測試信任關系和 Netlogon 安全通道 | Windows?Server? |
Klist | Windows?2000, Windows Server? | Windows 2000 和 Windows Server? | Kerberos 票證報告 | Windows?Server? |
Pathping | Windows?2000, Windows Server? | 包含在操作系統中 | 網絡連接和路徑測試 | Windows 幫助 |
LDP | Windows?2000, Windows Server? | 支持工具 | 用于測試 Active Directory 的 LDAP 客戶端 | Windows?Server? |
對 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 filtersNetsh 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? |
| ? | Kerberos 委派疑難解答，網址為 www.microsoft.com/downloads/details.aspx? |
在 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 圖形界面中顯示此計數器，此外，您也可以使用 |
| ? | 啟用 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? |
基于域的 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 策略，即使在強制刷新組策略之后，Userenv 或 SceCli 產生的應用程序日志錯誤也將指示組策略處理有問題。 必須啟用組策略記錄功能以便更詳細地調查此問題。 有許多不同類型的組策略日志和記錄級別。 為了查看任何錯誤處理安全策略以及 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/ |
| ? | HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/IPSec/ |
默認的 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.netshshow_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 中，當策略有問題時，您可能會看到下列錯誤：
| ? | 無法綁定到 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。 此錯誤可能是由下列任何情況導致的：
| ||||||||||||
| ? | 無法完成請求的操作。 策略存儲未打開。 無法打開 Active Directory、遠程計算機或本地計算機存儲。 此錯誤通常是由權限或身份驗證故障導致的。 | ||||||||||||
| ? | 正在使用活動本地注冊表策略，原因是：(i) 沒有 Active Directory 存儲策略，或者 (ii) 無法成功地應用 Active Directory 存儲策略，并且沒有緩存的策略。 此事件表示計算機本地定義了 IPsec 策略，并且無法應用基于域的策略以覆蓋該策略。 | ||||||||||||
| ? | 未使用任何 IPsec 策略，原因如下：(i) 沒有 Active Directory 存儲策略或活動本地注冊表策略，或者 (ii) 無法成功地應用 Active Directory 存儲策略，并且沒有緩存的策略，或者沒有活動本地注冊表策略。 此事件表示默認狀態，在此狀態下，未對計算機指派任何策略。 |
在 Windows XP 和 Windows Server 2003 中，下列事件表示 IPsec 服務無法檢索特定類型的策略。
再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://blog.csdn.net/jiangjunshow
總結
以上是生活随笔為你收集整理的使用 IPsec 与组策略隔离服务器和域－第 7 章 IPsec 疑难解答的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 19、Fragment
- 下一篇： 二分学习笔记