你已經實施了IPsec來保護你公司局域網內的通信，雖然已仔細地遵照所有技術文檔，但你還是不能確信網絡通信切實受到保護，不被竊聽。怎麼才能重新樹立IPsec確實對你的計算機的網絡通信進行了加密的信心呢？
讓我們來看一看如何確保一切順利進行，然後——假如你在驗證過程中發現問題——看一看對IPsec相關的驗證問題進行故障排除的整體情況。在驗證過程中，我會給你展示一些Windows Server 2003的內建工具，如果你真的發現網絡通信未被加密，你可以使用這些工具來診斷IPsec的問題(但是，請注意：我在本文中所討論的技術不一定適用於特定的IPsec應用程序，諸如：IPsec卡和基於虛擬專用網的IPsec)。
1. 檢查IPsec是否在運行
即使你已經成功地部署了IPsec，還是會有很多地方出現問題。當你為Windows Server 2003或Windows XP機器上一般網絡連接丟失而苦惱時，操作系統保證會讓你知道出問題了。遺憾的是，沒有類似的方法能讓你始終了解IPsec的狀態。依靠IPsec部署，當你有問題時，要麼釋放所有的網絡連接，要麼——可能性更大，並且更隱秘的是——網絡通信得以繼續，但是不再加密。想象一下當你相信自己受到保護，卻發現你的網絡通信根本不安全時會是多麼震驚。
檢查IPsec是否在運行的最快捷的方法是使用網絡監視器捕捉進出你的計算機的數據包，並檢查它們是否被加密。網絡監視器是隨Windows Server 2003一起提供的，你可以通過打開“控制面板”*“添加或刪除程序”，添加/刪除Windows組件來安裝它。安裝完之後，你可以從“捕獲”菜單選擇“開始”來開始包捕捉。然後，要制造一些網絡行為，生成一些數據，執行諸如浏覽另一台計算機上的一個共享文件夾的普通動作。最後，在“捕獲”菜單下選擇“停止並查看”。
圖1顯示了兩個包捕捉的結果。左邊是當計算機未配置使用IPsec時執行的包捕捉，你會看到在協議列中列出了多種協議。右邊是在計算機配置使用IPsec時執行的包捕捉，你會看到只列出了一個協議：封裝安全負載(Encapsulating Security Payload，ESP)協議。當一台Windows Server 2003計算機被配置為使用默認的IPsec策略時，只有ESP和因特網控制消息協議(Internet Control Message Protocol，ICMP)會出現在包捕捉中。因特網控制消息協議會出現是因為默認的IPsec策略允許ICMP通信。所以，如果在你捕捉網絡通信時看到多種協議，你就有理由認為IPsec沒有正常工作。
圖1：包捕捉比較
幾乎所有IPsec問題的發生都是因為Internet密鑰交換(Internet Key Exchange，IKE)階段的驗證困難。當兩台計算機試圖建立一個安全關聯(security association,SA)時,它們要經歷一個對彼此的身份進行驗證的過程。IKE是協商建立安全關聯的算法。身份驗證基於預共享密鑰、數字證書或Kerberos。默認的Windows Server 2003 IPsec策略使用Kerberos。在大多數實例中，對IPsec進行故障排除意味著排除驗證過程的故障。
2.重新啟動IPsec服務
你一旦確定IPsec未運行，應該首先嘗試重新啟動IPsec服務。重新啟動IPsec服務會完全清除IKE協商狀態。當策略發生重大變化以後IPsec變得不起作用時，這種方法通常能夠使它重新發揮作用。這一方案的兩個優勢在於它無需重新啟動服務器，並且實施起來耗時很少。你可以通過在Windows Server 2003計算機的命令提示符中運行如下的Net命令重新啟動IPsec服務：
以下是代碼片段：
現在，再次執行網絡包捕捉測試，或者運行我在後面將要談到的Netsh命令進行測試。
3. 在事件日志中診斷IKE問題
如果重新啟動IPsec不能解決問題，你可以轉而檢查安全事件日志。創建和刪除安全關聯的行為被審核為網絡登錄事件。如果你在審核登錄事件策略中啟用了對成功和失敗的審核，這些事件就會被寫入日志。當一切都正常運行時，出現的成功代碼是541、542和543。但是，本文討論IPsec未運行時你該怎麼辦，所以在我們的實例中，需要特別關注表1中顯示的失敗代碼。圖2顯示了失敗事件547。
表1：失敗審核代碼
圖2：失敗事件547
安全關聯事件日志的一個問題是該事件會很快充滿你的日志。如果你專門審核登錄事件，但又不想你的安全事件日志被IKE項充滿，可以通過創建“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Audit\DisableIKE Audits”子鍵，並將其鍵值設置為1來禁止IKE審核。
