pfSensebook之IKEv2服務器配置示例-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)長期為千余家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為石景山企業(yè)提供專業(yè)的成都網(wǎng)站制作、成都網(wǎng)站設計，石景山網(wǎng)站改版等技術服務。擁有10多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

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

• 配置IPsec移動客戶端設置

• 為客戶端連接創(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)建一個：

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

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

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

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

• 單擊保存

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

注意

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

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

• 單擊  添加一個新的證書

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

• 輸入描述名稱如：IKEv2 Server

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

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

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

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

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

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

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

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

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

• 在類型字段選IP地址

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

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

• 單擊保存

配置IPsec移動客戶端設置

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

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

• 導航到××× > IPsec

• 選中啟用IPsec

• 單擊保存

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

• 導航到××× >IPsec

• 點擊移動客戶端標簽

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

  

  啟用IPsec移動客戶端支持

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

移動客戶端認證

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

虛擬地址池:

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

虛擬IPv6地址池:

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

網(wǎng)絡列表:

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

保存Xauth密碼:

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

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

拆分DNS:

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

DNS服務器:

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

注意

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

WINS服務器：

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

Phase 2 PFS組：

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

登陸橫幅：

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

設置完成后如下：

移動客戶端推送設置

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

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

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

• 單擊隧道選項卡。

• 配置選項如下:

  密鑰交換版本:IKEv2

  Internet協(xié)議:IPv4

  接口:WAN

  描述說明: Mobile IPsec

    認證方法:EAP-MSCHAPv2

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

  對等標識符:Any

  我的證書:選擇之前創(chuàng)建的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隧道

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

  NAT/BINAT:設置為None

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

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

  哈希算法:選SHA1和 SHA256

  PFS密鑰組:設為關閉

  有效期: 3600

移動客戶端階段 2

• 單擊保存

• 單擊應用更改

配置完成后如下圖：

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

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

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

• 單擊  添加新密鑰

• 配置選項如下:

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

   加密類型：設置為EAP

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

• 單擊保存

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

移動IPsec用戶

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

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

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

Windows IKEv2 客戶端配置

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

導入CA證書到客戶端PC上

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

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

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

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

• 雙擊這個 CA 文件

• 單擊安裝證書

證書屬性

• 選擇本地計算機

證書導入向?qū)?- 存儲位置

• 單擊下一步

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

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

證書導入向?qū)?- 瀏覽存儲

• 單擊瀏覽

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

選擇證書存儲

• 單擊確定

• 單擊完成。

完成證書導入向?qū)?/p>

設置 ×××連接

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

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

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

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

• 單擊下一步

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

• 單擊下一步

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

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

注意

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

Windows IKEv2 ×××連接設置

• 輸入目標名稱

• 單擊創(chuàng)建

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

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

• 右鍵單擊連接

• 單擊屬性

• 單擊安全選項卡

• 設置×××類型為：KEv2

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

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

• 單擊確定

  設置完成后如下圖

Windows IKEv2 ××× 連接屬性

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

禁用EKU檢查

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

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

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

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

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

iOS 11 IKEv2客戶端配置

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

導入CA到OS設備

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

iOS郵件客戶端接收CA證書

• 從電子郵件安裝證書：

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

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

• 打開包含CA證書的郵件

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

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

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

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

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

設置×××連接

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

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

• 添加×××配置

• 設置類型為IKEv2 (default)

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

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

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

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

• 本地ID留空

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

• 輸入用戶名或密碼

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

• 點擊完成

iOS IKEv2客戶端設置

連接和斷開

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

1. 設置 ×××

2. 設置 >通用 > ×××

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

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

IOS ×××列表

測試IPsec連接

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

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

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

在GUI中使用Ping工具

在GUI中，按以下步驟操作

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

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

• 協(xié)議選IPv4

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

• 大ping數(shù)，選默認3

• 單擊Ping

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

如果最初沒有建立隧道，那么在隧道協(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地址，而遠程LAN IP是遠程路由器上列出的遠程子網(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回復。

IPsec故障排除

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

IPsec日志

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

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

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

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

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

• 單擊保存

注意

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

隧道不能建立

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

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

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

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

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

如果隧道已建立，但沒有流量通過，首先應檢查IPsec防火墻規(guī)則。如果站點A無法到達站點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)的流量到達IPsec隧道的遠端。 WAN或OPT WAN接口上的阻塞數(shù)據(jù)包將阻止建立隧道。通常只有當自動×××規(guī)則被禁用時才會發(fā)生這種情況。添加一個規(guī)則允許來自該遠程IP地址的ESP協(xié)議和UDP端口500將允許建立隧道。在移動隧道的情況下，允許任何來源的流量連接到這些端口。

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

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

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

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

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

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

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

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

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

連接掛起

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

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

在其他嵌入式硬件上，如果IPsec隧道被丟棄，則可能需要禁用隧道上的DPD。 這種故障傾向與高帶寬使用時間相關聯(lián)。 當?shù)凸南到y(tǒng)上的CPU發(fā)送IPsec通信或占用其他資源時，會發(fā)生這種情況。 由于CPU過載，可能無法花時間來響應DPD請求或者看到自己的請求的響應。 因此，隧道將無法通過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的使用期限到期時，它才會按預期進行重新協(xié)商。

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

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

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

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

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

IPsec日志說明

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

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

成功的連接

當隧道成功建立后，雙方都會建立一個IKE SA和一個子SA。 當多個階段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

響應者的日志顯示:

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ù)情況下，從示例中可以清楚地看到，啟動器沒有收到有關特定項目不匹配的消息，因此響應者日志更有參考性。 這樣做是為了保護隧道的安全，向潛在的***者提供消息是不安全的，這將給他們提供關于隧道配置的信息。

階段1的Aggressive / Main不匹配

在此示例中，啟動程序設置為Aggressive模式，而響應者設置為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

響應者的日志顯示:

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

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

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

階段1標識符不匹配

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

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

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

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

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

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加密算法不匹配

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

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哈希算法不匹配

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

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

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

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

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

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

響應者的日志顯示:

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

在響應者日志中，它列出了它收到的網(wǎng)絡（日志中的“child config”行）以及它在本地配置了什么（在日志中提出了“proposing traffic selectors for us....”行）。 通過比較兩者，可以發(fā)現(xiàn)不匹配。 當發(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

響應者的日志顯示:

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ā)起者收到響應者找不到合適提議的消息（“收到NO_PROPOSAL_CHOSEN”），并且從響應者日志中可以看出，這是由于網(wǎng)站被設置為不同的加密類型，一端為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

響應者的日志顯示:

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中發(fā)生這種情況時，響應者還會記錄更清晰的消息“找不到可接受的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

響應者的日志顯示:

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完美的前向保密）是一種安全通信協(xié)議，可防止一次加密會話的破壞導致多次加密會話的破壞。通過PFS，服務器為每個與客戶端建立的安全會話生成唯一的私鑰。如果服務器私鑰遭到破壞，則只有與該密鑰建立的單個會話易受*** - ***者無法從過去和將來的會話中檢索數(shù)據(jù)，因為服務器使用唯一生成的密鑰來建立每個連接。

注意

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

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

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)返回到默認解析器，這將糾正IPsec狀態(tài)頁面的顯示。

IPsec術語

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

IKE

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

ISAKMP安全聯(lián)盟

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

ISAKMP安全聯(lián)盟（ISAKMP SA）是一種單向策略，定義了如何加密和處理流量。 每個活動的IPsec隧道將有兩個安全關聯(lián)，每個方向一個。 ISAKMP安全關聯(lián)設置在每個端點的公共IP地址之間。 這些活動安全關聯(lián)的數(shù)據(jù)保存在安全關聯(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條目和交換密鑰的安全通道。 這還包括身份驗證，檢查標識符以及檢查預共享密鑰（PSK）或證書。 第一階段完成后，兩端可以安全地交換信息，但尚未決定通過隧道或其加密的流量。

階段 2

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

翻譯自pfsense book

2017-11-21

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

分享題目：pfSensebook之IKEv2服務器配置示例-創(chuàng)新互聯(lián)
網(wǎng)站URL：http://muchs.cn/article34/cechpe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、全網(wǎng)營銷推廣、外貿(mào)網(wǎng)站建設、動態(tài)網(wǎng)站、企業(yè)建站、響應式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)