pfSense book之IKEv2服務(wù)器配置示例

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

• 為×××創(chuàng)建一個證書結(jié)構(gòu)

• 配置IPsec移動客戶端設(shè)置

• 為客戶端連接創(chuàng)建階段1和階段2

• 添加IPsec防火墻規(guī)則

• 創(chuàng)建×××的用戶憑據(jù)

• ipsec連接測試

• ipsec故障排除

• ipsec日志說明

  
  

為×××創(chuàng)建IKEv2證書結(jié)構(gòu)

創(chuàng)建一個證書頒發(fā)機構(gòu)

如果證書管理器中沒有合適的證書頒發(fā)機構(gòu)（CA），那么我們首先創(chuàng)建一個：

• 導(dǎo)航到系統(tǒng)>證書管理，CAS選項卡

• 單擊  添加一個證書頒發(fā)機構(gòu)

• 證書來源選創(chuàng)建一個內(nèi)部證書頒發(fā)機構(gòu)

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

• 單擊保存

  
  

創(chuàng)建一個服務(wù)器證書

注意

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

• 導(dǎo)航到系統(tǒng)>證書管理,證書選項卡

• 單擊  添加一個新的證書

• 證書來源選創(chuàng)建內(nèi)部證書

• 輸入描述名稱如：IKEv2 Server

• 選擇在上一步中創(chuàng)建的證書頒發(fā)機構(gòu)

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

• 選擇證書類型為服務(wù)器證書

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

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

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

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

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

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

• 在類型字段選IP地址

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

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

• 單擊保存

  
  

配置IPsec移動客戶端設(shè)置

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

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

• 導(dǎo)航到××× > IPsec

• 選中啟用IPsec

• 單擊保存 

  
  

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

• 導(dǎo)航到××× >IPsec

• 點擊移動客戶端標(biāo)簽

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

  

  啟用IPsec移動客戶端支持

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

移動客戶端認(rèn)證

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

虛擬地址池:

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

虛擬IPv6地址池:

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

網(wǎng)絡(luò)列表:

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

保存Xauth密碼:

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

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

拆分DNS:

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

DNS服務(wù)器:

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

注意

如果移動客戶端將通過×××路由到Internet，請確?？蛻舳耸褂么诉x項從防火墻獲取DNS服務(wù)器，并且沒有啟用拆分DNS。 如果沒有這樣做，客戶端將嘗試從ISP分配的任何服務(wù)器獲取DNS，但是通過隧道路由該請求很可能會失敗。

WINS服務(wù)器：

與DNS服務(wù)器類似，但用于WINS?，F(xiàn)在已很少使用，最好還是禁用。

Phase 2 PFS組：

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

登陸橫幅：

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

設(shè)置完成后如下：

移動客戶端推送設(shè)置

創(chuàng)建階段1和階段2

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

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

• 單擊隧道選項卡。

• 配置選項如下:
  

    密鑰交換版本:IKEv2

    Internet協(xié)議:IPv4

    接口:WAN

    描述說明: Mobile IPsec

    認(rèn)證方法:EAP-MSCHAPv2

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

    對等標(biāo)識符:Any

    我的證書:選擇之前創(chuàng)建的IPsec服務(wù)器證書

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

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

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

    有效期:必須為 28800

    禁用預(yù)授密碼:不選中

    禁用重新認(rèn)證:不選中

    僅響應(yīng):不選中

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

移動客戶端階段 1

• 單擊保存 

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

• 單擊  添加新的phase 2條目 

• 配置選頂如下：

    模式:選IPv4隧道

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

    NAT/BINAT:設(shè)置為None

    協(xié)議:設(shè)置為ESP, 這將加密隧道流量

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

    哈希算法:選SHA1和 SHA256

    PFS密鑰組:設(shè)為關(guān)閉

   有效期: 3600

移動客戶端階段 2

• 單擊保存

• 單擊應(yīng)用更改

配置完成后如下圖：

創(chuàng)建IPsec移動用戶

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

• 導(dǎo)航到××× > IPsec,預(yù)共享密鑰選項卡 

• 單擊  添加新密鑰

• 配置選項如下:

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

    加密類型：設(shè)置為EAP

    預(yù)共享密鑰：客戶端的密碼, 如 abc123

• 單擊保存

• 為其他的×××用戶重復(fù)上述操作。

移動IPsec用戶

添加IPsec防火墻規(guī)則

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

創(chuàng)建×××的用戶憑據(jù)

Windows IKEv2 客戶端配置

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

導(dǎo)入CA證書到客戶端PC上

• 從pfSense導(dǎo)出CA證書并下載或復(fù)制到客戶端PC:

• 導(dǎo)航到系統(tǒng)>證書管理,CAS選項卡

• 在證書列表右側(cè)單擊  導(dǎo)出CA證書

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

• 雙擊這個 CA 文件

• 單擊安裝證書

證書屬性

• 選擇本地計算機

證書導(dǎo)入向?qū)?- 存儲位置

• 單擊下一步

• 如果出現(xiàn)UAC提示，請單擊是

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

證書導(dǎo)入向?qū)?- 瀏覽存儲

• 單擊瀏覽

• 單擊“受信任的根證書頒發(fā)機構(gòu)”

選擇證書存儲

• 單擊確定

• 單擊完成。

• 
  

完成證書導(dǎo)入向?qū)?/span>

設(shè)置 ×××連接

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

• 在客戶端PC上打開網(wǎng)絡(luò)和共享中心

• 點擊設(shè)置一個新的連接或網(wǎng)絡(luò)

• 選擇連接到工作區(qū)

• 單擊下一步

• 選擇否，創(chuàng)建一個新的連接

• 單擊下一步

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

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

注意

這必須與服務(wù)器證書通用名稱或配置的備用名稱中的內(nèi)容匹配！

Windows IKEv2 ×××連接設(shè)置

• 輸入目標(biāo)名稱

• 單擊創(chuàng)建

連接已經(jīng)添加，但有幾個默認(rèn)值需要進(jìn)行修改。 請參閱圖下圖進(jìn)行設(shè)置：

• 在Windows的網(wǎng)絡(luò)連接/適配器設(shè)置中，找到上面創(chuàng)建的連接

• 右鍵單擊連接

• 單擊屬性

• 單擊安全選項卡

• 設(shè)置×××類型為：KEv2

• 設(shè)置數(shù)據(jù)加密選項為 ：需要加密（如果服務(wù)器拒絕將斷開連接）

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

• 單擊確定

  設(shè)置完成后如下圖
  

Windows IKEv2 ××× 連接屬性

現(xiàn)在×××連接已經(jīng)可以使用了。

禁用EKU檢查

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

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

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

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

可能需要重新啟動才能激活設(shè)置。

iOS 11 IKEv2客戶端配置

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

導(dǎo)入CA到OS設(shè)備

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

iOS郵件客戶端接收CA證書

• 從電子郵件安裝證書：
  

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

• 打開客戶端設(shè)備上的郵件應(yīng)用程序
  

• 打開包含CA證書的郵件
  

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

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

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

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

• 在確認(rèn)提示處點擊安裝，現(xiàn)在將CA證書存儲為受信任的條目。
  

設(shè)置×××連接

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

• 進(jìn)入手機的設(shè)置>通用>×××

• 添加×××配置

• 設(shè)置類型為IKEv2 (default)

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

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

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

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

• 本地ID留空

• 將用戶鑒定設(shè)置為用戶名

• 輸入用戶名或密碼

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

• 點擊完成 

iOS IKEv2客戶端設(shè)置

連接和斷開

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

1. 設(shè)置 ×××

2. 設(shè)置 >通用 > ×××

一旦存在至少一個×××連接，直接會在設(shè)置里面出現(xiàn)×××條目。

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

IOS ×××列表

測試IPsec連接

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

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

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

在GUI中使用Ping工具

在GUI中，按以下步驟操作

• 導(dǎo)航到系統(tǒng)診斷> Ping

• 在主機字段中輸入一個遠(yuǎn)程路由器遠(yuǎn)程隧道子網(wǎng)的IP（例如10.5.0.1）

• 協(xié)議選 IPv4

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

• 最大ping數(shù)，選默認(rèn)3

• 單擊Ping

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

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

在Shell中使用Ping命令

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

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

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

#  ping -S 10.3.0.1 10.5.0.1

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

IPsec故障排除

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

IPsec日志

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

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

• 導(dǎo)航到××× > IPsec高級設(shè)置選項卡

• 將IKE SA、IKE Child SA、Configuration Backend 設(shè)置為診斷

• 將所有其他日志設(shè)置設(shè)置為控制

• 單擊保存

注意

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

隧道不能建立

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

如果服務(wù)正在運行，請檢查防火墻日志（系統(tǒng)狀態(tài)>系統(tǒng)日志，防火墻選項卡）以查看連接是否被阻止，如果是，請?zhí)砑右?guī)則以允許阻止的流量。 通常為IPsec自動添加規(guī)則，但可以禁用該功能。

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

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

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

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

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

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

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

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

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

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

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

2.子網(wǎng)掩碼不正確:如果一端使用的子網(wǎng)為10.0.0.0/24，另一端為10.254.0.0/24，并且主機的子網(wǎng)掩碼為255.0.0.0或/ 8，則永遠(yuǎn)不能通過×××進(jìn)行通信 因為它認(rèn)為遠(yuǎn)程×××子網(wǎng)是本地網(wǎng)絡(luò)的一部分，因此路由將無法正常工作。 配置中斷的系統(tǒng)將嘗試通過ARP而不是使用網(wǎng)關(guān)聯(lián)系遠(yuǎn)程系統(tǒng)。

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

4.pfSense上的防火墻規(guī)則:確保兩端的規(guī)則允許所需的網(wǎng)絡(luò)流量。

連接掛起

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

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

在其他嵌入式硬件上，如果IPsec隧道被丟棄，則可能需要禁用隧道上的DPD。 這種故障傾向與高帶寬使用時間相關(guān)聯(lián)。 當(dāng)?shù)凸南到y(tǒng)上的CPU發(fā)送IPsec通信或占用其他資源時，會發(fā)生這種情況。 由于CPU過載，可能無法花時間來響應(yīng)DPD請求或者看到自己的請求的響應(yīng)。 因此，隧道將無法通過DPD檢查并斷開連接。 這表明硬件正在超越極限。 如果發(fā)生這種情況，請考慮使用更強大的硬件。

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

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

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

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

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

站點A將相信隧道已經(jīng)啟動并繼續(xù)發(fā)送流量，就像隧道正常工作一樣。

只有在站點A的階段1或階段2的使用期限到期時，它才會按預(yù)期進(jìn)行重新協(xié)商。

在這種情況下，兩種可能的解決方法是：啟用DPD，或者站點B必須將流量發(fā)送到站點A，這將導(dǎo)致整個隧道重新協(xié)商。 實現(xiàn)這一點的最簡單方法是在隧道的兩側(cè)啟用?；顧C制。

隧道在啟動時建立，而不是在響應(yīng)時建立

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

有效期不匹配不會導(dǎo)致階段1或階段2失敗。

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

IPsec日志說明

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

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

成功的連接

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

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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

失敗的連接示例

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

階段1的Aggressive / Main不匹配

在此示例中，啟動程序設(shè)置為Aggressive模式，而響應(yīng)者設(shè)置為Main模式。

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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

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

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

階段1標(biāo)識符不匹配

當(dāng)標(biāo)識符不匹配時，發(fā)起者只顯示認(rèn)證失敗，但沒有理由。 響應(yīng)者指出無法找到對等點，表明找不到匹配的階段1，這意味著不能找到匹配的標(biāo)識符。

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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預(yù)共享密鑰不匹配

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

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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

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

階段1加密算法不匹配

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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) ]

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

階段1哈希算法不匹配

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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組不匹配

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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”部分表示。 如日志消息所示，發(fā)起人被設(shè)置為8192（組18），響應(yīng)者被設(shè)置為1024（組2）。 通過將隧道兩端的DH組設(shè)置為匹配值，可以糾正該錯誤。

階段2網(wǎng)絡(luò)不匹配

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

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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) ]

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

階段2加密算法不匹配

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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) ]

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

階段 2 哈希算法不匹配

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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值不對齊。 然而，當(dāng)階段2中發(fā)生這種情況時，響應(yīng)者還會記錄更清晰的消息“找不到可接受的INTEGRITY_ALGORITHM”。

階段2 PFS不匹配

發(fā)起者的日志顯示:

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

響應(yīng)者的日志顯示:

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

注意

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

與NAT不匹配的標(biāo)識符

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

響應(yīng)者的日志顯示:

   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]

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

消失的流量

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

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

IPsec狀態(tài)頁面問題

如果IPsec狀態(tài)頁面出現(xiàn)錯誤，如：

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

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

IPsec術(shù)語

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

IKE

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

ISAKMP安全聯(lián)盟

ISAKMP代表互聯(lián)網(wǎng)安全聯(lián)盟和密鑰管理協(xié)議。 它為雙方提供了一個機制，可以建立一個安全的通信渠道，包括交換密鑰和提供認(rèn)證。

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

安全策略

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

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

階段 1

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

階段 2

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

翻譯自pfsense book

2017-11-21