pfSense book之IKEv2服務器配置示例

移動客戶端的服務器配置有幾個組件：

• 為×××創建一個證書結構

• 配置IPsec移動客戶端設置

• 為客戶端連接創建階段1和階段2

• 添加IPsec防火墻規則

• 創建×××的用戶憑據

• ipsec連接測試

• ipsec故障排除

• ipsec日志說明

  
  

為×××創建IKEv2證書結構

創建一個證書頒發機構

如果證書管理器中沒有合適的證書頒發機構（CA），那么我們首先創建一個：

• 導航到系統>證書管理，CAS選項卡

• 單擊  添加一個證書頒發機構

• 證書來源選創建一個內部證書頒發機構

• 按照公司或特定地點的信息填寫其余的字段

• 單擊保存

  
  

創建一個服務器證書

注意

請嚴格按照步驟進行操作，如果任何一部分不正確，則某些或所有客戶端可能無法連接。

• 導航到系統>證書管理,證書選項卡

• 單擊  添加一個新的證書

• 證書來源選創建內部證書

• 輸入描述名稱如：IKEv2 Server

• 選擇在上一步中創建的證書頒發機構

• 輸入密鑰長度,摘要算法和有效期

• 選擇證書類型為服務器證書

• 根據需要在專用名稱字段中填寫地區和公司數據，將其從CA中復制并保留原樣

• 輸入通用名稱作為DNS中存在的防火墻的主機名稱。如果客戶端將通過IP地址連接，請在此處填寫IP地址

• 單擊  添加 一個新的替代名稱

• 在類型字段中選FQDN或主機名

• 在“值”字段中再次輸入防火墻的主機名

• 單擊  添加另一個替代名稱

• 在類型字段選IP地址

• 在“值”字段中輸入防火墻的WAN IP地址

• 根據需要為客戶端可能用于連接的防火墻上的其他主機名或IP地址添加更多替代名稱

• 單擊保存

  
  

配置IPsec移動客戶端設置

在配置移動IPsec實例之前，首先選擇一個IP地址范圍用于移動客戶端。 確保IP地址不與任何現有網絡重疊; IP地址必須與托管移動隧道的站點以及客戶端連接的LAN不同。 在這個例子中，將使用10.3.200.0/24，但它可以是任何未使用的子網。

首先，請在防火墻上啟用IPsec：

• 導航到××× > IPsec

• 選中啟用IPsec

• 單擊保存 

  
  

移動客戶端支持也必須啟用:

• 導航到××× >IPsec

• 點擊移動客戶端標簽

• 選中啟用IPsec移動客戶端支持

  

  啟用IPsec移動客戶端支持

• 將用戶認證設置為“本地數據庫”，如下圖所示所示。在用戶管理（用戶管理和認證）中定義的RADIUS服務器可以在這里選擇用于在使用EAP-RADIUS時對用戶進行認證。

移動客戶端認證

某些設置可能會推送到客戶端，例如客戶端IP地址和DNS服務器。 這些選項顯示在“移動客戶端推送的設置”中。 不同客戶端對這些選項的支持各不相同，但在大多數當前操作系統中得到很好的支持

虛擬地址池:

定義將分配給客戶端的IP地址池。 這個例子使用10.3.200.0/24。

虛擬IPv6地址池:

跟上面相同，只不過是IPv6地址。

網絡列表:

控制客戶端是否嘗試通過隧道發送所有流量，或者僅針對特定網絡的流量。 如果選中此選項，則移動階段2定義的本地網絡選項中定義的網絡將被發送到客戶端。 如果未選中此選項，則客戶端將嘗試通過隧道發送其所有流量，包括Internet流量。 并非所有客戶都尊重這一選擇。 對于這個例子，客戶端只能在階段2到達網絡，所以選中這個選項。

保存Xauth密碼:

選中后，支持此控件的客戶端將允許用戶在使用Xauth時保存其憑據。 這主要是由基于思科的客戶端（如iOS和Mac OS X上的客戶端）所推崇的。由于本示例使用了IKEv2，因此并不重要。

DNS默認域:選中后，輸入到框中的值將作為DNS請求的默認域后綴推送給客戶端。 例如，如果將此設置為example.com，并且客戶端請求主機，則會嘗試執行host.example.com的DNS請求。

拆分DNS:

控制客戶端如何將DNS請求發送到提供的DNS服務器（如果有）。 如果未選中此選項，則客戶端將把所有DNS請求發送到提供的DNS服務器。 如果該選項被選中，但保留為空，并且設置了DNS默認域，則只有該域名的請求才會轉到提供的DNS服務器。 如果選中并輸入一個值，那么只有輸入框中的域名請求才會被轉發到提供的DNS服務器。 在這個例子中，example.com和example.org都被使用，并且這兩個域的DNS請求將會到達×××服務器，所以在這里輸入這些值，并用空格隔開。

DNS服務器:

當選中向客戶端提供DNS服務器列表時，為本地DNS服務器（如10.3.0.1）輸入IP地址，這些值將在×××連接時發送給客戶端使用。

注意

如果移動客戶端將通過×××路由到Internet，請確保客戶端使用此選項從防火墻獲取DNS服務器，并且沒有啟用拆分DNS。 如果沒有這樣做，客戶端將嘗試從ISP分配的任何服務器獲取DNS，但是通過隧道路由該請求很可能會失敗。

WINS服務器：

與DNS服務器類似，但用于WINS。現在已很少使用，最好還是禁用。

Phase 2 PFS組：

覆蓋所有移動Phase 2條目的PFS設置。 通常最好在P2條目上單獨設置此值，因此請不要選中。

登陸橫幅：

可選，只適用于Xauth客戶端。 保持未選中并空白

設置完成后如下：

移動客戶端推送設置

創建階段1和階段2

• 單擊“保存”，pfSense將顯示警告，指出移動客戶端沒有定義Phase 1。

• 點擊創建Phase 1，為移動客戶端創建一個新的Phase1條目。

• 單擊隧道選項卡。

• 配置選項如下:
  

    密鑰交換版本:IKEv2

    Internet協議:IPv4

    接口:WAN

    描述說明: Mobile IPsec

    認證方法:EAP-MSCHAPv2

    我的標識符:從下拉列表中選擇“可分辨名稱”，然后輸入防火墻的主機名，與服務器證書的主機名相同， ***.example.com

    對等標識符:Any

    我的證書:選擇之前創建的IPsec服務器證書

    加密算法:設置為3DES (如果沒有iOS / OS X設備，則為AES 256)

    哈希算法:必須設置為 SHA1 (如果沒有iOS / OS X設備，則為SHA256)

    DH組:必須設置為2 (1024 bit)

    有效期:必須為 28800

    禁用預授密碼:不選中

    禁用重新認證:不選中

    僅響應:不選中

    MOBIKE:設置為啟用以允許客戶端在IP地址之間漫游，否則設置為禁用。

移動客戶端階段 1

• 單擊保存 

• 單擊  顯示階段 2條目，展開階段2列表

• 單擊  添加新的phase 2條目 

• 配置選頂如下：

    模式:選IPv4隧道

    本地網絡:設置為LAN子網或其他本地網絡。 要通過×××隧道傳輸所有流量，請選擇網絡，并輸入掩碼為0的0.0.0.0

    NAT/BINAT:設置為None

    協議:設置為ESP, 這將加密隧道流量

    加密算法:必須設置為AES，自動選擇密鑰長度。 如果有iOS或OS X客戶端連接，也選中3DES。

    哈希算法:選SHA1和 SHA256

    PFS密鑰組:設為關閉

   有效期: 3600

移動客戶端階段 2

• 單擊保存

• 單擊應用更改

配置完成后如下圖：

創建IPsec移動用戶

下一步是添加用戶以供EAP-MSCHAPv2使用。

• 導航到××× > IPsec,預共享密鑰選項卡 

• 單擊  添加新密鑰

• 配置選項如下:

    標識符：客戶端的用戶名可以用多種方式表示，例如電子郵件地址 jimp@example.com

    加密類型：設置為EAP

    預共享密鑰：客戶端的密碼, 如 abc123

• 單擊保存

• 為其他的×××用戶重復上述操作。

移動IPsec用戶

添加IPsec防火墻規則

與靜態站點到站點隧道一樣，移動隧道也需要在防火墻>規則策略下的IPsec選項卡中添加防火墻規則。 在這種情況下，流量的來源將是為移動客戶端選擇的子網，目的地是LAN網絡，或者為任意。 

創建×××的用戶憑據

Windows IKEv2 客戶端配置

Windows 8以上的版本可以輕松支持IKEv2 ×××，而Windows 7也可以，雖然過程略有不同。 本示例過程在Windows 10上執行，與Windows 8幾乎完全相同。 

導入CA證書到客戶端PC上

• 從pfSense導出CA證書并下載或復制到客戶端PC:

• 導航到系統>證書管理,CAS選項卡

• 在證書列表右側單擊  導出CA證書

• 在客戶端計算機上找到下載的文件（例如×××CA.crt）

• 雙擊這個 CA 文件

• 單擊安裝證書

證書屬性

• 選擇本地計算機

證書導入向導 - 存儲位置

• 單擊下一步

• 如果出現UAC提示，請單擊是

• 選擇將所有證書都放入下列存儲，如下圖所示

證書導入向導 - 瀏覽存儲

• 單擊瀏覽

• 單擊“受信任的根證書頒發機構”

選擇證書存儲

• 單擊確定

• 單擊完成。

• 
  

完成證書導入向導

設置 ×××連接

一旦證書正確導入，就可以創建客戶端×××連接了。 確切的步驟將取決于客戶端使用的Windows版本，以下是在Win10的設置方法。

• 在客戶端PC上打開網絡和共享中心

• 點擊設置一個新的連接或網絡

• 選擇連接到工作區

• 單擊下一步

• 選擇否，創建一個新的連接

• 單擊下一步

• 單擊使用我的Internet連接（×××）

• 在Internet地址中輸入服務器的IP地址或主機名

注意

這必須與服務器證書通用名稱或配置的備用名稱中的內容匹配！

Windows IKEv2 ×××連接設置

• 輸入目標名稱

• 單擊創建

連接已經添加，但有幾個默認值需要進行修改。 請參閱圖下圖進行設置：

• 在Windows的網絡連接/適配器設置中，找到上面創建的連接

• 右鍵單擊連接

• 單擊屬性

• 單擊安全選項卡

• 設置×××類型為：KEv2

• 設置數據加密選項為 ：需要加密（如果服務器拒絕將斷開連接）

• 設置身份驗證為使用可擴展身份驗證協議(EAP)(E): Microsoft:安全密碼 (EAP-MSCHAP v2) (啟用加密)

• 單擊確定

  設置完成后如下圖
  

Windows IKEv2 ××× 連接屬性

現在×××連接已經可以使用了。

禁用EKU檢查

在pfSense 2.2.4及更高版本上正確設置了CA和服務器證書后，禁用EKU檢查已經不是必需的了。 如果出于某種原因必須使用不正確的服務器證書，則可能需要在Windows上禁用擴展密鑰使用檢查。 禁用此檢查還會禁用證書的公用名稱和SAN字段的驗證，因此可能會有危險。 禁用此服務器時，可以使用來自同一CA的任何證書，因此請謹慎操作。

要禁用擴展密鑰用法檢查，請打開Windows客戶端上的注冊表編輯器，并導航到客戶端注冊表中的以下位置：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters\

添加一個名為DisableIKENameEkuCheck的新DWORD條目，并將其值設置為“1”。

可能需要重新啟動才能激活設置。

iOS 11 IKEv2客戶端配置

從IOS9開始，iOS內置了對IKEv2的支持，可以從GUI配置而不需要×××配置文件。 和其他客戶一樣，必須安裝CA證書。

導入CA到OS設備

將CA證書導入到客戶端設備是一個相對容易的過程。 第一步是將CA證書拿到客戶端設備上。 最簡單的方法是通過電子郵件，如圖用iOS郵件客戶端接收CA證書

iOS郵件客戶端接收CA證書

• 從電子郵件安裝證書：
  

• 僅將CA證書（不是密鑰）發送到可從客戶端設備訪問的電子郵件地址
  

• 打開客戶端設備上的郵件應用程序
  

• 打開包含CA證書的郵件
  

• 點擊附件安裝CA證書，安裝配置文件提示將顯示在iOS CA證書安裝配置文件提示中

iOS CA證書安裝配置文件提示

• 點擊右上方的“安裝”，將出現一個警告屏幕，如iOS安全證書安裝警告中所示

• 點擊右上方的安裝再次確認，然后顯示一個最終提示，如iOS CA證書確認提示中所示

• 在確認提示處點擊安裝，現在將CA證書存儲為受信任的條目。
  

設置×××連接

一旦安裝了CA證書，就必須配置一個×××條目：

• 進入手機的設置>通用>×××

• 添加×××配置

• 設置類型為IKEv2 (default)

• 輸入一個描述(例如 ExampleCo ×××)

• 在服務器中輸入防火墻主機名或IP地址

• 在Remote ID中再次輸入防火墻的主機名

注意:這必須匹配服務器證書的通用名稱和SAN條目。

• 本地ID留空

• 將用戶鑒定設置為用戶名

• 輸入用戶名或密碼

注意:使用EAP-MSCHAPv2，用戶名是在“×××”>“IPsec”下的“預共享密鑰”選項卡上為用戶條目配置的標識符。 使用EAP-RADIUS，這將是在RADIUS服務器上設置的用戶名。

• 點擊完成 

iOS IKEv2客戶端設置

連接和斷開

通過訪問設置下的×××條目可以連接或斷開×××。 這兩個地方稍有不同：

1. 設置 ×××

2. 設置 >通用 > ×××

一旦存在至少一個×××連接，直接會在設置里面出現×××條目。

一旦在×××列表中，必須選擇×××條目（在其條目旁邊顯示復選標記），然后滑塊可以移動到“開”位置以連接。

IOS ×××列表

測試IPsec連接

對于IPsec隧道來說，最簡單的測試就是從防火墻后面的一個客戶端ping到另一個客戶端。 如果能ping通，隧道就可以正常工作了。

正如pfSense啟動的流量和IPsec中所提到的，從pfSense防火墻啟動的流量通常不會在沒有額外路由的情況下穿越隧道，但是通過PING指定發出的源，可以快速測試防火墻本身的連接。

有兩種方法可以執行這個測試：GUI和shell。

在GUI中使用Ping工具

在GUI中，按以下步驟操作

• 導航到系統診斷> Ping

• 在主機字段中輸入一個遠程路由器遠程隧道子網的IP（例如10.5.0.1）

• 協議選 IPv4

• 源地址：在本地防火墻上選擇一個接口或IP地址（例如，選擇LAN作為LAN IP地址）

• 最大ping數，選默認3

• 單擊Ping

如果隧道正常工作，則防火墻將從站點B的局域網地址接收ping回復。

如果最初沒有建立隧道，那么在隧道協商過程中丟失幾個ping是很常見的，所以如果第一次嘗試失敗，選擇更多的次數或重新運行測試是一個好的做法。

在Shell中使用Ping命令

使用控制臺上的shell或通過ssh，可以手動運行ping命令，并可以使用-S參數指定源地址。 如果不使用-s或靜態路由，ping生成的數據包將不會嘗試穿越隧道。 下面是一個簡單的測試語法：

#  ping -S <Local LAN IP> <Remote LAN IP>

本地LAN IP是隧道的本地子網定義的內部接口上的IP地址，而遠程LAN IP是遠程路由器上列出的遠程子網內的IP地址。 在大多數情況下，這只是各個pfSense防火墻的LAN IP地址。 根據上面的站點到站點示例，這是從Site A防火墻的控制臺輸入的內容：

#  ping -S 10.3.0.1 10.5.0.1

如果隧道正常工作，則防火墻將從站點B的局域網地址接收ping回復。

IPsec故障排除

由于IPsec的挑剔性質，出現問題并不罕見。 幸運的是，有一些基本的故障排除步驟可以用來追蹤潛在的問題。

IPsec日志

本章中介紹的例子有為了簡潔起見而編輯的日志，但仍有重要的信息。

IPsec日志可以被配置為提供更多有用的信息。 在pfSense中要配置IPsec日志記錄來診斷隧道問題，請參照以下步驟：

• 導航到××× > IPsec高級設置選項卡

• 將IKE SA、IKE Child SA、Configuration Backend 設置為診斷

• 將所有其他日志設置設置為控制

• 單擊保存

注意

更改日志記錄選項不會中斷IPsec活動，也不需要為當前版本的pfSense上的IPsec輸入特定的“調試模式”。

隧道不能建立

首先檢查系統狀態>系統服務的狀態。 如果IPsec服務已停止，請在×××> IPsec檢查它是否已啟用。 另外，如果使用移動客戶端，請確保在移動客戶端上的啟用框也被選中。

如果服務正在運行，請檢查防火墻日志（系統狀態>系統日志，防火墻選項卡）以查看連接是否被阻止，如果是，請添加規則以允許阻止的流量。 通常為IPsec自動添加規則，但可以禁用該功能。

IPsec隧道連接失敗的最常見原因是配置不匹配。 通常情況下，它是很小的，例如DH組在A側設置為1，在B側設置為2，或者在一側為/ 24或者在另一側為/ 32的子網掩碼。 一些路由器（Linksys）也喜歡隱藏“高級”按鈕背后的某些選項。 大量的反復試驗可能會涉及到大量的日志閱讀，但是確保雙方精確匹配最有幫助。

根據隧道兩端的互聯網連接情況，一方或另一方涉及的路由器也可能無法正確處理IPsec通信。 這是移動客戶端和NAT在實際IPsec端點之外涉及的網絡引起的更大的關注。 一般來說，ESP協議存在一直被阻塞或處理不當的問題。 NAT穿越（NAT-T）將ESP封裝在UDP端口4500流量中，可以解決這些問題。

隧道已建立，但沒有流量傳遞

如果隧道已建立，但沒有流量通過，首先應檢查IPsec防火墻規則。如果站點A無法到達站點B，請檢查站點B的防火墻日志和規則。相反，如果站點B不能聯系站點A，請檢查站點A的防火墻日志和規則。在查看規則之前，請在“防火墻”選項卡上的系統狀態>系統日志中檢查防火墻日志。如果存在阻止的條目涉及IPsec隧道中使用的子網，則繼續檢查規則。

IPsec或enc0接口上的阻塞數據包表明隧道本身已建立，但流量正在被防火墻規則阻止。在局域網或其他內部接口上阻塞的數據包可能表示在該接口規則集上可能需要附加的規則，以允許來自內部子網的流量到達IPsec隧道的遠端。 WAN或OPT WAN接口上的阻塞數據包將阻止建立隧道。通常只有當自動×××規則被禁用時才會發生這種情況。添加一個規則允許來自該遠程IP地址的ESP協議和UDP端口500將允許建立隧道。在移動隧道的情況下，允許任何來源的流量連接到這些端口。

IPsec接口的規則可以在IPsec選項卡上的防火墻>規則策略下找到。常見的錯誤包括設置規則只允許TCP通信，這意味著像ICMP ping和DNS這樣的協議不能通過隧道工作。

在某些情況下，設置不匹配也可能導致流量無法通過隧道。在一個例子中，在一個非pfSense防火墻上定義的子網是192.0.2.1/24，而在pfSense防火墻上是192.0.2.0/24。建立了隧道，但是直到子網被糾正，流量才能通過。

路由問題是另一種可能性。使用跟蹤路由（Windows上的tracert）檢查隧道另一側的IP地址可以幫助追蹤這些類型的問題。重復隧道兩側的測試。當使用跟蹤路由（traceroute）時，進入和離開IPsec隧道的流量似乎缺少一些中間跳躍。這是正常的，也是IPsec工作的一部分。沒有正確進入IPsec隧道的流量將顯示為離開WAN接口并通過Internet向外路由，這將指向路由問題，如pfSense不是網關（如在路由和網關注意事項中）、錯誤地指定在隧道定義上的遠程子網、或已禁用隧道等 。

一些主機工作，但不是全部

如果通過×××的某些主機之間的流量功能正常，但另外一些主機不通過，則通常是以下四種情況之一：

1.缺少、不正確或被忽略的默認網關:如果設備沒有默認網關，或者有一個指向pfSense防火墻之外的其他設備，則不知道如何正確返回×××上的遠程網絡。有些設備，即使使用指定的默認網關，也不使用該網關。這已經出現在各種嵌入式設備上，包括IP攝像機和一些打印機。除了修復設備上的軟件之外，沒有什么可以做。這可以通過在連接到包含該設備的網絡的防火墻的內部接口上運行數據包捕獲來驗證。使用tcpdump進行故障排除，并且可以在IPsec隧道中找到一個IPsec特定的示例。如果觀察到流量離開防火墻的內部接口，但沒有應答返回，則設備沒有正確路由其回復流量，或者可能通過本地客戶端防火墻阻止。

2.子網掩碼不正確:如果一端使用的子網為10.0.0.0/24，另一端為10.254.0.0/24，并且主機的子網掩碼為255.0.0.0或/ 8，則永遠不能通過×××進行通信 因為它認為遠程×××子網是本地網絡的一部分，因此路由將無法正常工作。 配置中斷的系統將嘗試通過ARP而不是使用網關聯系遠程系統。

3.主機防火墻:如果目標主機上有防火墻，則可能不允許連接。 檢查Windows防火墻，iptables或類似的實用程序，可能會阻止主機處理流量。

4.pfSense上的防火墻規則:確保兩端的規則允許所需的網絡流量。

連接掛起

IPsec不能正常處理分片數據包。 這些問題中的許多問題多年來已經得到解決，但可能會有一些滯后的問題。 如果僅在使用特定協議（SMB，RDP等）時才會看到掛起或丟包，則可能需要×××設置MSS。 可以在“×××> IPsec”的“高級設置”選項卡上激活MSS限制。 在該頁面上，選中啟用×××通信上的MSS限制，然后輸入一個值。 一開始可以輸入1400，慢慢地增加MSS值，直到正常連接，然后再降低一點。

嵌入式路由器上的“隨機”隧道斷開/ DPD故障

在其他嵌入式硬件上，如果IPsec隧道被丟棄，則可能需要禁用隧道上的DPD。 這種故障傾向與高帶寬使用時間相關聯。 當低功耗系統上的CPU發送IPsec通信或占用其他資源時，會發生這種情況。 由于CPU過載，可能無法花時間來響應DPD請求或者看到自己的請求的響應。 因此，隧道將無法通過DPD檢查并斷開連接。 這表明硬件正在超越極限。 如果發生這種情況，請考慮使用更強大的硬件。

隧道已建立和工作，但不能重新協商

在某些情況下，隧道正常運行，但是一旦階段1或階段2的使用期限屆滿，隧道將無法正確重新協商。 這可以用幾種不同的方式表現出來，每種方式都有不同的分辨方法。

DPD不受支持，一方丟棄，另一方丟棄

從站點A到站點B，從站點A發起的流量建立隧道。

站點B在站點A之前到期的階段1或階段2。

站點A將相信隧道已經啟動并繼續發送流量，就像隧道正常工作一樣。

只有在站點A的階段1或階段2的使用期限到期時，它才會按預期進行重新協商。

在這種情況下，兩種可能的解決方法是：啟用DPD，或者站點B必須將流量發送到站點A，這將導致整個隧道重新協商。 實現這一點的最簡單方法是在隧道的兩側啟用保活機制。

隧道在啟動時建立，而不是在響應時建立

如果隧道有時會建立，但并不總是，一般來說，某一方面是不匹配的。 隧道仍然可以建立，因為如果一方提出的設置更安全，另一方可以接受，但不能反過來。 例如，如果在一個IKEv1隧道和設置為Main模式的站點與設置了Aggressive / Main模式的站點通信，雖然不匹配，隧道仍將建立。 但是，如果設置為Aggressive的端口嘗試啟動隧道，則將會失敗。

有效期不匹配不會導致階段1或階段2失敗。

要跟蹤這些故障，請按照“IPsec日志記錄”中的說明配置日志，然后嘗試從各端發起連接隧道，然后檢查日志。

IPsec日志說明

IPsec選項卡上的“系統狀態”>“系統日志”中提供的IPsec日志包含隧道連接過程的記錄以及來自正在進行的隧道維護活動的一些消息。 本節列出了一些典型的日志條目，包括好的和壞的。 要查找的主要內容是指示連接的哪一部分起作用的關鍵短語。 如果日志中存在“IKE_SA ... established”，則意味著階段1已成功完成，并且協商了安全協會。 如果“CHILD_SA ...已經建立”，那么第二階段也已經完成，隧道已經建成。

在以下示例中，日志已在IPsec日志記錄中配置為偵聽，而不相關的消息可能會被忽略。 請記住這些是樣本，具體的ID號碼，IP地址等等會有所不同。

成功的連接

當隧道成功建立后，雙方都會建立一個IKE SA和一個子SA。 當多個階段2定義與IKEv1一起出現時，針對每個階段2條目協商子SA。

發起者的日志顯示:

charon: 09[IKE] IKE_SA con2000[11] established between 192.0.2.90[192.0.2.90]...192.0.2.74[192.0.2.74]charon: 09[IKE] CHILD_SA con2000{2} established with SPIs cf4973bf_i c1cbfdf2_o and TS 192.168.48.0/24|/0 === 10.42.42.0/24|/0

響應者的日志顯示:

charon: 03[IKE] IKE_SA con1000[19] established between 192.0.2.74[192.0.2.74]...192.0.2.90[192.0.2.90]charon: 16[IKE] CHILD_SA con1000{1} established with SPIs c1cbfdf2_i cf4973bf_o and TS 10.42.42.0/24|/0 === 192.168.48.0/24|/0

失敗的連接示例

這些示例顯示由于各種原因而失敗的連接 在大多數情況下，從示例中可以清楚地看到，啟動器沒有收到有關特定項目不匹配的消息，因此響應者日志更有參考性。 這樣做是為了保護隧道的安全，向潛在的***者提供消息是不安全的，這將給他們提供關于隧道配置的信息。

階段1的Aggressive / Main不匹配

在此示例中，啟動程序設置為Aggressive模式，而響應者設置為Main模式。

發起者的日志顯示:

charon: 15[IKE] initiating Aggressive Mode IKE_SA con2000[1] to 203.0.113.5charon: 15[IKE] received AUTHENTICATION_FAILED error notifycharon: 13[ENC] parsed INFORMATIONAL_V1 request 1215317906 [ N(AUTH_FAILED) ]charon: 13[IKE] received AUTHENTICATION_FAILED error notify

響應者的日志顯示:

charon: 13[IKE] Aggressive Mode PSK disabled for security reasonscharon: 13[ENC] generating INFORMATIONAL_V1 request 2940146627 [ N(AUTH_FAILED) ]

請注意，響應者狀態中的日志清楚地表明， Aggressive 模式已被禁用，這是模式不匹配的一個很好的線索。

在相反的情況下，如果為Main模式設置的端點啟動，則由于Main模式更安全，因此到pfSense防火墻的隧道將建立。

階段1標識符不匹配

當標識符不匹配時，發起者只顯示認證失敗，但沒有理由。 響應者指出無法找到對等點，表明找不到匹配的階段1，這意味著不能找到匹配的標識符。

發起者的日志顯示:

charon: 10[ENC] parsed INFORMATIONAL_V1 request 4216246776 [ HASH N(AUTH_FAILED) ]charon: 10[IKE] received AUTHENTICATION_FAILED error notify

響應者的日志顯示:

charon: 12[CFG] looking for pre-shared key peer configs matching 203.0.113.5...198.51.100.3[someid]charon: 12[IKE] no peer config foundcharon: 12[ENC] generating INFORMATIONAL_V1 request 4216246776 [ HASH N(AUTH_FAILED) ]

階段1預共享密鑰不匹配

不匹配的預共享密鑰可能難以診斷。 說明這個值不匹配的錯誤不會顯示在日志中，而是顯示以下消息：

發起者的日志顯示:

charon: 09[ENC] invalid HASH_V1 payload length, decryption failed?
charon: 09[ENC] could not decrypt payloads
charon: 09[IKE] message parsing failed

響應者的日志顯示:

charon: 09[ENC] invalid ID_V1 payload length, decryption failed?
charon: 09[ENC] could not decrypt payloads
charon: 09[IKE] message parsing failed

當上述日志消息存在時，請檢查雙方的預共享密鑰值以確保它們匹配。

階段1加密算法不匹配

發起者的日志顯示:

charon: 14[ENC] parsed INFORMATIONAL_V1 request 3851683074 [ N(NO_PROP) ]charon: 14[IKE] received NO_PROPOSAL_CHOSEN error notify

響應者的日志顯示:

charon: 14[CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[IKE] no proposal foundcharon: 14[ENC] generating INFORMATIONAL_V1 request 3851683074 [ N(NO_PROP) ]

在這種情況下，日志條目確切地說明了問題：啟動器設置為AES 128加密，響應者設置為AES 256。將兩個設置為匹配的值，然后再試一次。

階段1哈希算法不匹配

發起者的日志顯示:

charon: 10[ENC] parsed INFORMATIONAL_V1 request 2774552374 [ N(NO_PROP) ]charon: 10[IKE] received NO_PROPOSAL_CHOSEN error notify

響應者的日志顯示:

charon: 14[CFG] received proposals: IKE:AES_CBC_256/MODP_1024charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[IKE] no proposal foundcharon: 14[ENC] generating INFORMATIONAL_V1 request 2774552374 [ N(NO_PROP) ]

哈希算法由記錄提供的HMAC部分顯示。 從上面可以看出，接收和配置的propsals沒有匹配的HMAC條目。

階段1 DH組不匹配

發起者的日志顯示:

charon: 11[ENC] parsed INFORMATIONAL_V1 request 316473468 [ N(NO_PROP) ]charon: 11[IKE] received NO_PROPOSAL_CHOSEN error notify

響應者的日志顯示:

charon: 14[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[IKE] no proposal foundcharon: 14[ENC] generating INFORMATIONAL_V1 request 316473468 [ N(NO_PROP) ]

DH組由示例的“MODP”部分表示。 如日志消息所示，發起人被設置為8192（組18），響應者被設置為1024（組2）。 通過將隧道兩端的DH組設置為匹配值，可以糾正該錯誤。

階段2網絡不匹配

在以下示例中，啟動端的階段2條目設置為10.3.0.0/24到10.5.0.0/24。 響應者沒有設置為匹配，因為它列出了10.5.1.0/24。

發起者的日志顯示:

charon: 08[CFG] proposing traffic selectors for us:charon: 08[CFG] 10.3.0.0/24|/0charon: 08[CFG] proposing traffic selectors for other:charon: 08[CFG] 10.5.0.0/24|/0charon: 08[ENC] generating QUICK_MODE request 316948142 [ HASH SA No ID ID ]charon: 08[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (236 bytes)charon: 08[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 08[ENC] parsed INFORMATIONAL_V1 request 460353720 [ HASH N(INVAL_ID) ]charon: 08[IKE] received INVALID_ID_INFORMATION error notify

響應者的日志顯示:

charon: 08[ENC] parsed QUICK_MODE request 2732380262 [ HASH SA No ID ID ]charon: 08[CFG] looking for a child config for 10.5.0.0/24|/0 === 10.3.0.0/24|/0charon: 08[CFG] proposing traffic selectors for us:charon: 08[CFG] 10.5.1.0/24|/0charon: 08[CFG] proposing traffic selectors for other:charon: 08[CFG] 10.3.0.0/24|/0charon: 08[IKE] no matching CHILD_SA config foundcharon: 08[IKE] queueing INFORMATIONAL taskcharon: 08[IKE] activating new taskscharon: 08[IKE] activating INFORMATIONAL taskcharon: 08[ENC] generating INFORMATIONAL_V1 request 1136605099 [ HASH N(INVAL_ID) ]

在響應者日志中，它列出了它收到的網絡（日志中的“child config”行）以及它在本地配置了什么（在日志中提出了“proposing traffic selectors for us....”行）。 通過比較兩者，可以發現不匹配。 當發生這種不匹配時，日志中的“no matching CHILD_SA config foundcharon”行將始終存在，并且直接表示無法找到階段2定義以匹配從啟動端收到的內容。

階段2加密算法不匹配

發起者的日志顯示:

charon: 14[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQcharon: 14[ENC] generating QUICK_MODE request 759760112 [ HASH SA No ID ID ]charon: 14[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (188 bytes)charon: 14[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 14[ENC] parsed INFORMATIONAL_V1 request 1275272345 [ HASH N(NO_PROP) ]charon: 14[IKE] received NO_PROPOSAL_CHOSEN error notify

響應者的日志顯示:

charon: 13[CFG] selecting proposal:charon: 13[CFG] no acceptable ENCRYPTION_ALGORITHM foundcharon: 13[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQcharon: 13[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 13[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSENcharon: 13[IKE] queueing INFORMATIONAL taskcharon: 13[IKE] activating new taskscharon: 13[IKE] activating INFORMATIONAL taskcharon: 13[ENC] generating INFORMATIONAL_V1 request 1275272345 [ HASH N(NO_PROP) ]

在這種情況下，發起者收到響應者找不到合適提議的消息（“收到NO_PROPOSAL_CHOSEN”），并且從響應者日志中可以看出，這是由于網站被設置為不同的加密類型，一端為AES 128 ，而另一端是AES 256。

階段 2 哈希算法不匹配

發起者的日志顯示:

charon: 10[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQcharon: 10[ENC] generating QUICK_MODE request 2648029707 [ HASH SA No ID ID ]charon: 10[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (188 bytes)charon: 10[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 10[ENC] parsed INFORMATIONAL_V1 request 757918402 [ HASH N(NO_PROP) ]charon: 10[IKE] received NO_PROPOSAL_CHOSEN error notify

響應者的日志顯示:

charon: 11[CFG] selecting proposal:charon: 11[CFG] no acceptable INTEGRITY_ALGORITHM foundcharon: 11[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQcharon: 11[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 11[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSENcharon: 11[IKE] queueing INFORMATIONAL taskcharon: 11[IKE] activating new taskscharon: 11[IKE] activating INFORMATIONAL taskcharon: 11[ENC] generating INFORMATIONAL_V1 request 757918402 [ HASH N(NO_PROP) ]

與階段1哈希算法不匹配類似，日志條目中的HMAC值不對齊。 然而，當階段2中發生這種情況時，響應者還會記錄更清晰的消息“找不到可接受的INTEGRITY_ALGORITHM”。

階段2 PFS不匹配

發起者的日志顯示:

charon: 06[ENC] generating QUICK_MODE request 909980434 [ HASH SA No KE ID ID ]charon: 06[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (444 bytes)charon: 06[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 06[ENC] parsed INFORMATIONAL_V1 request 3861985833 [ HASH N(NO_PROP) ]charon: 06[IKE] received NO_PROPOSAL_CHOSEN error notify

響應者的日志顯示:

charon: 08[CFG] selecting proposal:charon: 08[CFG] no acceptable DIFFIE_HELLMAN_GROUP foundcharon: 08[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQcharon: 08[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 08[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSENcharon: 08[ENC] generating INFORMATIONAL_V1 request 3861985833 [ HASH N(NO_PROP) ]

PFS像第一階段的DH組一樣工作，但是是可選的。 當選擇的PFS選項不匹配時，會記錄一條明確的消息，指出這一事實：“找不到可接受的DIFFIE_HELLMAN_GROUP”。PFS（Perfect Forward Secrecy完美的前向保密）是一種安全通信協議，可防止一次加密會話的破壞導致多次加密會話的破壞。通過PFS，服務器為每個與客戶端建立的安全會話生成唯一的私鑰。如果服務器私鑰遭到破壞，則只有與該密鑰建立的單個會話易受*** - ***者無法從過去和將來的會話中檢索數據，因為服務器使用唯一生成的密鑰來建立每個連接。

注意

在某些情況下，如果一方的PFS設置為關閉，而另一方設置了值，隧道仍然可以建立和工作。 上面顯示的不匹配只有在值不匹配的情況下才能看到，例如1對5。

與NAT不匹配的標識符

在這種情況下，pfSense被配置為對等IP地址的對等標識符，但是遠程設備實際上在NAT之后。 在這種情況下，strongSwan期望實際的私有NAT-IP地址作為標識符。 在舊版本上使用的racoon守護進程要輕松得多，可以匹配任何一個地址，但strongSwan更為正式，需要正確匹配。

響應者的日志顯示:

   charon: 10[IKE] remote host is behind NAT
   charon: 10[IKE] IDir '192.0.2.10' does not match to '203.0.113.245'[...]
   charon: 10[CFG] looking for pre-shared key peer configs matching 198.51.100.50...203.0.113.245[192.0.2.10]

要糾正這種情況，請將對等標識符設置更改為IP地址，然后輸入NAT之前的IP地址，在本例中為192.0.2.10。

消失的流量

如果IPsec通信到達但從未出現在IPsec接口（enc0）上，請檢查是否有沖突的路由/接口IP地址。 例如，如果一個IPsec隧道配置了一個192.0.2.0/24的遠程網絡，并且有一個本地Open×××服務器和一個192.0.2.0/24的隧道網絡，那么ESP流量可能到達，strongSwan可能會處理這些數據包，但是 他們從來沒有出現在到達操作系統交付的enc0as。

解決重復的接口/路由，流量將開始傳遞。

IPsec狀態頁面問題

如果IPsec狀態頁面出現錯誤，如：

Warning: Illegal string offset 'type' in /etc/inc/xmlreader.inc on line 116

這表示不完整的xmlreader XML解析器處于活動狀態，這是由文件/ cf / conf / use_xmlreader的存在觸發的。 這個替代解析器可以更快地讀取大型config.xml文件，但是缺少其他區域運行良好所必需的某些功能。 刪除/ cf / conf / use_xmlreader會立即將系統返回到默認解析器，這將糾正IPsec狀態頁面的顯示。

IPsec術語

在深入研究配置之前，在本章中有幾個術語需要解釋。 其他術語在配置選項中用于更詳細地解釋。

IKE

IKE代表互聯網密鑰交換，分為兩種：IKEv1和IKEv2。 幾乎所有支持IPsec的設備都使用IKEv1。 越來越多的設備也支持較新的IKEv2協議，這是IKE的更新版本，它解決了早期版本中存在的一些問題。 例如，IKEv2具有MOBIKE，這是移動客戶端的標準，允許他們動態地切換地址。 它也具有內置的NAT穿越功能，以及類似于DPD的可靠性標準機制。 一般而言，IKEv2提供了更穩定和可靠的體驗，但兩端必須同時支持。

ISAKMP安全聯盟

ISAKMP代表互聯網安全聯盟和密鑰管理協議。 它為雙方提供了一個機制，可以建立一個安全的通信渠道，包括交換密鑰和提供認證。

ISAKMP安全聯盟（ISAKMP SA）是一種單向策略，定義了如何加密和處理流量。 每個活動的IPsec隧道將有兩個安全關聯，每個方向一個。 ISAKMP安全關聯設置在每個端點的公共IP地址之間。 這些活動安全關聯的數據保存在安全關聯數據庫（SAD）中。

安全策略

安全策略是管理IPsec隧道的完整規范。 與安全協會一樣，這些是單向的，所以每個隧道在每個方向都會有一個。 這些條目保存在安全策略數據庫（SPD）中。 一旦添加了隧道，每個隧道連接就為SPD填充兩個條目。 相比之下，SAD條目僅在成功協商連接時才存在。

在pfSense軟件中，安全策略控制內核將攔截那些通過IPsec傳遞的流量。

階段 1

IPsec隧道有兩個階段的協商。 在階段1中，隧道的兩個端點之間建立一個使用ISAKMP協商SA條目和交換密鑰的安全通道。 這還包括身份驗證，檢查標識符以及檢查預共享密鑰（PSK）或證書。 第一階段完成后，兩端可以安全地交換信息，但尚未決定通過隧道或其加密的流量。

階段 2

在階段2中，兩個端點根據安全策略協商如何加密和發送專用主機的數據。 這部分構建了用于在端點處理流量的端點和客戶端之間傳輸數據的隧道。 如果雙方的策略相同并且第二階段成功建立，則隧道將被啟動并準備好用于與第二階段定義匹配的流量。

翻譯自pfsense book

2017-11-21