華爲防火牆HCIA學習筆記06_ipsec ***

IPSec ***技術與應用

IPSec ***技術原理

 

IPSec基本概念

• IPSec對等體：
  • IPSec用於在協商發起方和響應方這兩個端點之間提供安全的IP通信，通信的兩個端點被稱爲IPSec對等體。其中，端點可以是網關路由器或者防火牆，也可以是主機。
• IPSec隧道：
  • IPSec爲對等體間建立IPSec隧道來提供對數據流的安全保護。一對IPSec對等體間可以存在多條IPSec隧道，針對不同的數據流各選擇一條隧道對其進行保護，例如有的數據流只需要認證、有的需要認證和加密。
  • IPSec對數據的加密是以數據包爲單位，而不是以整個數據流爲單位。發送方對要保護的數據包進行加密封裝，在Internet上傳輸，接收方採用相同的參數對報文認證、解封裝，以得到原始數據。

 

IPSec協議體系結構

• IPSec ***體系結構主要由驗證頭AH（Authentication Header）、封裝安全載荷ESP（Encapsulating Security Payload）和因特網密鑰交換IKE（Internet Key Exchange）協議套件組成。IPSec通過AH和ESP兩個安全協議實現IP報文的安全保護，通過ESP來保障IP數據傳輸過程的機密性，使用AH/ESP提供數據完整性、數據源驗證和抗報文重放功能。ESP和AH定義了協議和載荷頭的格式及所提供的服務，但卻沒有定義實現以上能力所需具體轉碼方式，轉碼方式包括對數據轉換方式，如算法、密鑰長度等。爲簡化IPSec的使用和管理，IPSec還可以通過IKE進行自動協商交換密鑰、建立和維護安全聯盟的服務。具體介紹如下：
  • AH協議：AH是報文頭驗證協議，主要提供數據源驗證、數據完整性驗證和防報文重放功能，不提供加密功能。
  • ESP協議：ESP是封裝安全載荷協議，主要提供加密、數據源驗證、數據完整性驗證和防報文重放功能。
  • IKE協議：IKE協議建立在Internet安全聯盟和密鑰管理協議ISAKMP（Internet Security Association and Key Management Protocol）框架之上，採用DH（Diffie-Hellman）算法在不安全的網絡上安全地分發密鑰、驗證身份，以保證數據傳輸的安全性。IKE協議可提升密鑰的安全性，並降低IPSec管理複雜度。

 

IPSec安全協議 – AH

• 提供數據源驗證（真實性）、完整性校驗和抗重放
• 不提供數據加密功能
• AH用IP協議號51來標識

• AH是一種基於IP的傳輸層協議，協議號爲51。
• AH的工作原理是在每一個數據包的標準IP報頭後面添加一個AH報文頭。AH對數據包和認證密鑰進行Hash計算，接收方收到帶有計算結果的數據包後，執行同樣的Hash計算並與原計算結果比較，傳輸過程中對數據的任何更改將使計算結果無效，這樣就提供了數據來源認證和數據完整性校驗。AH協議的完整性驗證範圍爲整個IP報文。
• AH報文頭字段含義如下：
  • 下一頭部：8比特，標識AH報文頭後面的負載類型。
    • 傳輸模式下，是被保護的上層協議（TCP或UDP）或ESP協議的編號；
    • 隧道模式下，是IP協議或ESP協議的編號。
  • 負載長度：8比特，表示以32比特爲單位的AH頭部長度減2，缺省爲4。
  • 保留字段：16比特，保留將來使用，缺省爲0。
  • 安全參數索引（SPI）：32比特，用於唯一標識IPSec安全聯盟（IPSec SA）。
  • 序列號：32比特，是一個從1開始的單項遞增的計數器，唯一地標識每一個數據包，用於防止重放***。
  • 認證數據：一個變長字段，長度爲32比特的整數倍，通常爲96比特。該字段包含數據完整性校驗值ICV（Integrity Check Value），用於接收方進行完整性校驗。可選擇的認證算法有MD5（Message Digest）、SHA-1（Secure Hash Algorithm）、SHA-2、SM3。前三個認證算法的安全性由低到高依次排列，安全性高的認證算法實現機制複雜，運算速度慢。SM3密碼雜湊算法是中國國家密碼管理局規定的IPSec協議規範。

 

IPSec安全協議 – ESP

• 提供數據真實性、數據完整性、抗重放、數據機密性
• ESP用IP協議號50來標識

 

• ESP的工作原理是在每一個數據包的標準IP報頭後面添加一個ESP報文頭，並在數據包後面追加一個ESP尾（ESP Tail和ESP Auth data）。與AH不同的是，ESP將數據中的有效載荷進行加密後再封裝到數據包中，以保證數據的機密性，但ESP沒有對IP頭的內容進行保護。
• ESP報文頭字段含義如下：
  • 安全參數索引（SPI）：32比特，用於唯一標識IPSec安全聯盟（IPSec SA）。
  • 序列號：32比特，是一個從1開始的單項遞增的計數器，唯一地標識每一個數據包，用於防止重放***。
  • 負載數據：包含由下一頭部字段給出的變長數據。
  • 填充字段：用於增加ESP包頭的位數。填充字段的長度與負載數據的長度和算法有關。當待加密報文的明文長度不是加密算法所要求的塊長度時，需要進行填充補齊。
  • 填充長度：8比特，給出前面填充字段的長度，置0時表示沒有填充。
  • 下一頭部：8比特，標識ESP頭後面的下一個負載類型。
    • 傳輸模式下，是被保護的上層協議（TCP或UDP）的編號；
    • 隧道模式下，是IP協議的編號。
  • 認證數據：一個變長字段，長度爲32比特的整數倍，通常爲96比特。該字段包含數據完整性校驗值ICV，用於接收方進行完整性校驗。ESP的驗證功能是可選的，如果啓動了數據包驗證，會在加密數據的尾部添加一個ICV數值。

 

IPSec協議封裝模式

• 封裝模式是指將AH或ESP相關的字段插入到原始IP報文中，以實現對報文的認證和加密。IPSec協議有兩種封裝模式：傳輸模式和隧道模式。
  • 傳輸模式：在傳輸模式中，AH頭或ESP頭被插入到IP頭與傳輸層協議頭之間，保護TCP/UDP/ICMP負載。傳輸模式不改變報文頭，故隧道的源和目的地址必須與IP報文頭中的源和目的地址一致，所以只適合兩臺主機或一臺主機和一臺***網關之間通信。
  • 隧道模式：與傳輸模式不同，在隧道模式下，AH頭或ESP頭被插到原始IP頭之前，另外生成一個新的報文頭放到AH頭或ESP頭之前，保護IP頭和負載。隧道模式主要應用於兩臺***網關之間或一臺主機與一臺***網關之間的通信。

 

傳輸模式報文封裝

 

• 在傳輸模式下，以TCP報文爲例，原始報文經過傳輸模式封裝後，報文格式如上圖所示。
• 傳輸模式下
  • AH協議的完整性驗證範圍爲整個IP報文。
  • ESP協議
    • 驗證報文的完整性檢查部分包括ESP頭、傳輸層協議頭、數據和ESP報尾，但不包括IP頭，因此ESP協議無法保證IP頭的安全。
    • 加密部分包括傳輸層協議頭、數據和ESP報尾。

 

隧道模式報文封裝

• 在隧道模式下，以TCP報文爲例，原始報文經過隧道模式封裝後，報文格式如上圖所示。
• 隧道模式下，
  • AH協議的完整性驗證範圍爲包括新增IP頭在內的整個IP報文。
  • ESP協議
    • 加密部分包括源IP頭、傳輸層協議頭、數據和ESP報尾。
    • ESP協議驗證報文的完整性檢查部分包括ESP包頭、原IP頭、傳輸層協議頭、數據和ESP報尾，但不包括新IP頭，因此ESP協議無法保證新IP頭的安全。
• 當安全協議同時採用AH和ESP時，AH採用封裝模式爲傳輸模式。

 

IPSec協議封裝模式對比

IKE介紹

• 因特網密鑰交換IKE（Internet Key Exchange）協議建立在Internet安全聯盟和密鑰管理協議ISAKMP定義的框架上，是基於UDP（User Datagram Protocol）的應用層協議。它爲IPSec提供了自動協商密鑰、建立IPSec安全聯盟的服務，能夠簡化IPSec的使用和管理，大大簡化IPSec的配置和維護工作。
• 用IPSec保護一個IP包之前，必須先建立一個安全聯盟（SA）。IPSec的安全聯盟可以通過手工配置的方式建立。但是當網絡中節點較多時，手工配置將非常困難，而且難以保證安全性。這時就可以使用IKE（Internet Key Exchange）自動進行安全聯盟建立與密鑰交換的過程。Internet密鑰交換（IKE）就用於動態建立SA，代表IPSec對SA進行協商。
• 密鑰管理協議ISAKMP定義了消息交換的體系結構，包括兩個IPSec對等體間分組形式和狀態轉變（定義封裝格式和協商包交換的方式）。

 

IKE與IPSec的關係

• IKE是UDP之上的一個應用層協議，是IPSec的信令協議。
• IKE與IPSec的關係如上圖所示：
  • 對等體之間先建立一個IKE SA完成身份驗證和密鑰信息交換
  • 在IKE SA的保護下，根據配置的AH/ESP安全協議等參數協商出一對IPSec SA。此後，對等體間的數據將在IPSec隧道中加密傳輸。

 

安全聯盟

• IPSec安全傳輸數據的前提是在IPSec對等體（即IPSec協議的兩個端點）之間成功建立安全聯盟SA（Security Association）。SA是通信的IPSec對等體間對某些要素的約定。IPSec安全聯盟簡稱IPSec SA。
• SA由一個三元組來唯一標識，這個三元組包括安全參數索引SPI（Security Parameter Index）、目的IP地址和使用的安全協議號（AH或ESP）。其中，SPI是用於唯一標識SA的一個32比特數值，它在AH和ESP頭中傳輸。在手工配置SA時，需要手工指定SPI的取值。使用IKE協商產生SA時，SPI將隨機生成。
• 安全聯盟是單向的，在兩個對等體之間的雙向通信，最少需要兩個安全聯盟來分別對兩個方向的數據流進行安全保護。另外，SA的個數還與安全協議相關。如果您只使用AH或ESP來保護兩個對等體之間的流量，則對等體之間就有兩個SA，每個方向上一個。如果對等體同時使用了AH和ESP，那麼對等體之間就需要四個SA，每個方向上兩個，分別對應AH和ESP。
• 建立IPSec SA的方式：手工方式和IKE自動協商方式。二者的主要區別爲：
  • 密鑰生成方式不同：手工方式下，建立SA所需的全部參數，包括加密、驗證密鑰，都需要用戶手工配置，也只能手工刷新，在中大型網絡中，這種方式的密鑰管理成本很高；IKE方式下，建立SA需要的加密、驗證密鑰是通過DH算法生成的，可以動態刷新，因而密鑰管理成本低，且安全性較高。
  • 生存週期不同：手工方式建立的SA，一經建立永久存在；IKE方式建立的SA，其生存週期由雙方配置的生存週期參數控制。

 

IKE的安全機制

• IKE具有一套自保護機制，可以在不安全的網絡上安全地認證身份、分發密鑰、建立IPSec SA：
• 身份認證：身份認證確認通信雙方的身份（對等體的IP地址或名稱）。
• 身份保護：通信雙方的身份數據在密鑰產生之後加密傳送，實現了對身份數據的保護。
• DH（Diffie-Hellman）密鑰交換算法：通信雙方通過交換密鑰材料來計算共享的密鑰，即使第三方截獲了雙方用於計算密鑰的所有交換數據，也無法計算出真正的密鑰。
• 完善的前向安全性PFS（Perfect Forward Secrecy）：PFS是一種安全特性，指一個密鑰被破解，並不影響其他密鑰的安全性，因爲這些密鑰間沒有派生關係。PFS是由DH算法保障的。

 

IKE的安全機制 – 身份認證

• 身份認證確認通信雙方的身份（對等體的IP地址或名稱），包括預共享密鑰PSK（pre-shared key）認證、數字證書RSA（rsa-signature）認證和數字信封認證。
  • 在預共享密鑰認證中，認證字作爲一個輸入來產生密鑰，通信雙方採用共享的密鑰對報文進行Hash計算，判斷雙方的計算結果是否相同。如果相同，則認證通過；否則認證失敗。（理解：使用輸入的共享祕鑰作爲材料，採用對稱加密算法產生祕鑰，對祕鑰進行哈希計算，將計算結果傳送給對端。對端使用相同的方法得到哈希值，進行比較。）
  • 在數字證書認證中，通信雙方使用CA證書進行數字證書合法性驗證，雙方各有自己的公鑰（網絡上傳輸）和私鑰（自己持有）。發送方對原始報文進行Hash計算，並用自己的私鑰對報文計算結果進行加密，生成數字簽名。接收方使用發送方的公鑰對數字簽名進行解密，並對報文進行Hash計算，判斷計算結果與解密後的結果是否相同。如果相同，則認證通過；否則認證失敗。
  • 在數字信封認證中，發送方首先隨機產生一個對稱密鑰，使用接收方的公鑰對此對稱密鑰進行加密（被公鑰加密的對稱密鑰稱爲數字信封），發送方用對稱密鑰加密報文，同時用自己的私鑰生成數字簽名。接收方用自己的私鑰解密數字信封得到對稱密鑰，再用對稱密鑰解密報文，同時根據發送方的公鑰對數字簽名進行解密，驗證發送方的數字簽名是否正確。如果正確，則認證通過；否則認證失敗。
• 對於預共享密鑰認證方法，當有1個對等體對應多個對等體時，需要爲每個對等體配置預共享的密鑰。該方法在小型網絡中容易建立，但安全性較低。使用數字證書安全性高，但需要CA來頒發數字證書，適合在大型網絡中使用。而數字信封認證用於設備需要符合國家密碼管理局要求時使用，此認證方法只能在IKEv1的主模式協商過程中支持。
• IKE支持的認證算法有：MD5、SHA-1、SHA2-256、SHA2-384、SHA2-512、AES-XCBC-MAC-96、SM3。

 

IKE的安全機制 – 身份保護

• 身份數據在密鑰產生之後加密傳送，實現了對身份數據的保護。
• 支持的加密算法有：
  • DES ( 56bità64bit )
  • 3DES( 3個 56bit à64bit )
  • AES (128、192、256)
  • 國密算法SM1、SM4

 

IKE的安全機制 – DH (Diffie-Hellman) 密鑰交換算法

• 發起方和響應方利用ISAKMP消息的Key Exchange和nonce載荷交換彼此的密鑰材料。
  • Key Exchange用於交換DH公開值。
  • nonce用於傳送臨時隨機數。
• 由於DH算法中IKE Peer雙方只交換密鑰材料，並不交換真正的共享密鑰，即使***竊取了DH值和臨時值也無法計算出共享密鑰，這一點正是DH算法的精髓所在。從抓包中可以看到IKE Peer雙方交換密鑰材料，以消息3爲例：

• DH被稱爲公共密鑰交換方法，它用於產生密鑰材料，並通過ISAKMP消息在發送和接收設備之間進行密鑰材料交換。然後，兩端設備各自計算出完全相同的對稱密鑰。該對稱密鑰用於計算加密和驗證的密鑰。在任何時候，通信雙方都不交換真正的密鑰。DH密鑰交換是IKE的精髓所在。但DH沒有提供雙方身份的任何信息，不能確定交換的數據是否發送給合法方，第三方可以通過截獲的數據與通信雙方都協商密鑰、共享通信，從而獲取和傳遞信息，所以，IKE還需要身份認證來對對等體身份進行認證。

 

DH (Diffie-Hellman) 密鑰交換算法

• 兩個對等體使用DH算法，通過兩條ISAKMP消息交換與密鑰相關的信息。然後，結合自身的身份驗證方法,各自開始密鑰計算過程（預共享密鑰或數字證書都會參與到密鑰計算過程中）如上圖所示，最終生成相關密鑰：
  • SKEYID：SKEYID爲基礎密鑰，通過它可以推導出SKEYID_a、SKEYID_e、SKEYID_d；
  • SKEYID_a：ISAKMP消息完整性驗證密鑰；
  • SKEYID_e：ISAKMP消息加密密鑰；

  以上兩個密鑰保證了後續交換的ISAKMP消息的安全性。

  • SKEYID_d：用於衍生出IPSec報文加密和驗證密鑰，最終是由這個密鑰保證IPSec封裝的數據報文的安全性。
  • 整個密鑰交換和計算過程在IKE SA超時時間的控制下以一定的週期進行自動刷新，避免了密鑰長期不變帶來的安全隱患。
• MD5、SHA-1、DES、3DES、AES等算法都可以採用DH算法來共享對稱密鑰。
• DH使用密鑰組定義自己產生的密鑰長度。密鑰組長度越長，產生的密鑰就越強壯。

 

IKE的安全機制 – 完美的前向安全性PFS

• 短暫的一次性密鑰系統稱爲"完美向前保密"(Perfect Forward Secrecy，PFS)。
• 如果加密系統中有一個祕鑰是所有對稱密鑰的衍生者（始祖），便不能認爲那是一個"完美向前保密"的系統。在這種情況下，一旦破解了根密鑰，便能拿到其它衍生的所有密鑰，受那些密鑰保護的全部數據都會曝光。
• 在IPSec裏，PFS是通過在IPSec SA協商階段重新進行一次DH交換來實現的。

 

IKE協商

• IKE協議分IKEv1和IKEv2兩個版本。
• IKEv1
  • IKEv1使用兩個階段爲IPSec進行密鑰協商並建立IPSec SA。
    • 第一階段，通信雙方協商和建立IKE本身使用的安全通道，建立一個IKE SA。
    • 第二階段，利用這個已通過了認證和安全保護的安全通道，建立一對IPSec SA。
• IKEv2
  • IKEv2則簡化了協商過程。
  • 在一次協商中可直接產生IPSec的密鑰，生成IPSec SA。
• IKE協議分IKEv1和IKEv2兩個版本。IKEv2與IKEv1相比有以下優點：
  • 簡化了安全聯盟的協商過程，提高了協商效率。

  IKEv1使用兩個階段爲IPSec進行密鑰協商並建立IPSec SA：第一階段，通信雙方協商和建立IKE本身使用的安全通道，建立一個IKE SA；第二階段，利用這個已通過了認證和安全保護的安全通道，建立一對IPSec SA。IKEv2則簡化了協商過程，在一次協商中可直接生成IPSec的密鑰並建立IPSec SA。

  • 修復了多處公認的密碼學方面的安全漏洞，提高了安全性能。
  • 加入對EAP（Extensible Authentication Protocol）身份認證方式的支持，提高了認證方式的靈活性和可擴展性。

 

IKEv1協商的兩個階段

• 採用IKEv1協商安全聯盟主要分爲兩個階段：
  • 第一階段，通信雙方協商和建立IKE協議本身使用的安全通道，即建立一個IKE SA；
  • 第二階段，利用第一階段已通過認證和安全保護的安全通道，建立一對用於數據安全傳輸的IPSec安全聯盟。
• IKEv1協商階段1的目的是建立IKE SA。IKE SA建立後對等體間的所有ISAKMP消息都將通過加密和驗證，這條安全通道可以保證IKEv1階段2的協商能夠安全進行。
• 兩個對等體間只建立一個IKE SA，它是一個雙向邏輯連接。
• IKEv1協商階段1支持兩種協商模式：
  • 主模式（Main Mode）
  • 野蠻模式（Aggressive Mode）
• IKEv1協商階段2的目的就是建立用來安全傳輸數據的IPSec SA，併爲數據傳輸衍生出密鑰。
• IKEv1協商階段2採用快速模式（Quick Mode）。該模式使用IKEv1協商階段1中生成的密鑰SKEYID_a對ISAKMP消息的完整性和身份進行驗證，使用密鑰SKEYID_e對ISAKMP消息進行加密，故保證了交換的安全性。
• 在快速模式中，對等體兩端協商IPSec SA的各項參數，併爲數據傳輸衍生出密鑰。

 

主模式和野蠻模式協商過程圖

• 主模式包含三次雙向交換，用到了六條ISAKMP信息，協商過程如圖左所示。這三次交換分別是：
• 消息①和②用於協商對等體之間使用的IKE安全提議。
  • 發起方發送一個或多個IKE安全提議（IKE協商過程中用到的加密算法、認證算法、Diffie-Hellman組及認證方法等）。
  • 響應方對發起方的IKE安全提議進行協商。在協商時將從優先級最高的提議開始匹配，協商雙方必須至少有一條匹配的IKE安全提議才能協商成功。匹配的原則爲協商雙方具有相同的加密算法、認證算法、認證方法和Diffie-Hellman組標識。
  • 響應方響應ISAKMP消息，攜帶經協商匹配的安全提議及參數。 如果沒有匹配的安全提議，響應方將拒絕發起方的安全提議。
• 消息③和④使用DH算法交換與密鑰相關的信息，並生成密鑰。
  • 雙方交換Diffie-Hellman公共值和nonce值，併產生IKE SA的認證和加密密鑰（請參考前面的DH密鑰交換算法）。
• 消息⑤和⑥用於身份和認證信息交換（雙方使用生成的密鑰發送信息），雙方進行身份認證（預共享密鑰方式下爲IP地址或名稱，數字證書方式下還需要傳輸證書的內容）和對整個主模式交換內容的認證。
• 野蠻模式只用到三條信息，前兩條消息①和②用於協商IKE安全提議，交換Diffie-Hellman公共值、必需的輔助信息以及身份信息，並且消息②中還包括響應方發送身份信息供發起方認證，消息③用於響應方認證發起方。

 

主模式和野蠻模式的區別

• 交換的消息：
  • 主模式爲6個，野蠻模式爲3個。
• 身份保護：
  • 主模式的最後兩條消息有加密，可以提供身份保護功能；而野蠻模式消息集成度過高，因此無身份保護功能
• 對等體標識：
  • 主模式只能採用IP地址方式標識對等體；而野蠻模式可以採用IP地址方式或者Name方式標識對等體。

 

快速模式協商過程圖

• 快速模式中，雙方需要協商生成IPSec SA各項參數（包含可選參數PFS），併爲IPSec SA生成認證/加密密鑰。IKEv1協商階段2通過三條ISAKMP消息完成雙方IPSec SA的建立，如上圖所示：
  • 消息1：協商發起方發送本端的安全參數和身份認證信息。

  安全參數包括被保護的數據流和IPSec安全提議等需要協商的參數。IPSec安全提議指IPSec協商過程中用到的安全協議、加密算法及認證算法等。身份認證信息包括第一階段計算出的密鑰和第二階段產生的密鑰材料等，可以再次認證對等體。

  • 消息2：協商響應方發送確認的安全參數和身份認證信息並生成新的密鑰。

  IPSec SA數據傳輸需要的加密、驗證密鑰由第一階段產生的密鑰、SPI、協議等參數衍生得出，以保證每個IPSec SA都有自己獨一無二的密鑰。

  如果啓用PFS，則需要再次應用DH算法計算出一個共享密鑰，然後參與上述計算，因此在參數協商時要爲PFS協商DH密鑰組。

  • 消息3：發送方發送確認信息，確認與響應方可以通信，協商結束。

 

IKEv2密鑰協商和交換

• IKEv2中所有消息都以"請求-響應"的形式成對出現，響應方都要對發起方發送的消息進行確認，如果在規定的時間內沒有收到確認報文，發起方需要對報文進行重傳處理，提高了安全性。
• 採用IKEv2協商安全聯盟比IKEv1協商過程要簡化的多。要建立一對IPSec SA，IKEv1需要經歷兩個階段："主模式＋快速模式"或者"野蠻模式＋快速模式"，前者至少需要交換9條消息，後者也至少需要6條消息。而IKEv2 正常情況使用2次交換共4條消息就可以完成一對IPSec SA的建立，如果要求建立的IPSec SA大於一對時，每一對IPSec SA只需額外增加1次創建子SA交換，也就是2條消息就可以完成。
• IKEv2定義了三種交換：初始交換（Initial Exchanges）、創建子SA交換（Create_Child_SA Exchange）以及通知交換（Informational Exchange）。

 

IKEv2初始交換過程圖

• IKEv2通過初始交換就可以完成一個IKE SA和第一對IPSec SA的協商建立。如果要求建立的IPSec SA大於一對時，每一對SA值只需要額外增加一次創建子SA交換（IKEv1仍然需要經歷兩個階段）。
• IKEv2初始交換對應IKEv1的第一階段，初始交換包含兩次交換四條消息，如圖所示。
  • 消息①和②屬於第一次交換（稱爲IKE_SA_INIT交換），以明文方式完成IKE SA的參數協商，包括協商加密和驗證算法，交換臨時隨機數和DH交換。IKE_SA_INIT交換後生成一個共享密鑰材料，通過這個共享密鑰材料可以衍生出IPSec SA的所有密鑰。
  • 消息③和④屬於第二次交換（稱爲IKE_AUTH交換），以加密方式完成身份認證、對前兩條信息的認證和IPSec SA的參數協商。
• 創建子SA交換包含兩條消息，用於一個IKE SA創建多個IPSec SA或IKE的重協商，對應IKEv1的第二階段。該交換必須在初始交換完成後進行，交換消息由初始交換協商的密鑰進行保護。如果啓用PFS，創建子SA交換需要額外進行一次DH交換，生成新的密鑰材料。生成密鑰材料後，子SA的所有密鑰都從這個密鑰材料衍生出來。該交換的發起者可以是初始交換的協商發起方，也可以是初始交換的協商響應方。

 

IKEv2通知交換過程圖

• 通知交換如圖所示，運行IKE協商的兩端有時會傳遞一些控制信息，例如錯誤信息或者通告信息，這些信息在IKEv2中是通過通知交換完成的。
• 通知交換必須在IKE SA保護下進行，也就是說通知交換隻能發生在初始交換之後。控制信息可能是IKE SA的，那麼通知交換必須由該IKE SA來保護進行；也可能是某子SA的，那麼該通知交換必須由生成該子SA的IKE SA來保護進行。

 

IPSec ***部署邏輯順序

• 配置高級ACL：手工方式和IKE自動協商方式建立的IPSec隧道都可以通過ACL來指定要保護的數據流範圍，在對等體間鏡像配置ACL，篩選出需要進入IPSec隧道的報文，ACL規則允許（permit）的報文將被保護，沒有被允許（permit）的報文將不被保護。這種方式可以利用ACL的豐富配置功能，根據IP地址、端口、協議類型等對報文進行過濾進而靈活制定IPSec的保護方法。
• 配置IKE安全提議：IKE安全提議是IKE對等體的一個組成部分，定義了對等體進行IKE協商時使用的參數，包括認證方法、認證算法、加密算法、DH組和IKE安全聯盟的生存週期。
• 配置IKE對等體：配置IKE動態協商方式建立IPSec隧道時，需要引用IKE對等體，並配置IKE協商時對等體間的一系列屬性。
• 配置IPSec安全提議：IPSec安全提議是IPSec安全策略或者安全框架的一個組成部分，它包括IPSec使用的安全協議、認證/加密算法以及數據的封裝模式，定義了IPSec的保護方法，爲IPSec協商SA提供各種安全參數。IPSec隧道兩端設備需要配置相同的安全參數。
• 配置IPSec安全策略：IPSec安全策略是創建SA的前提，它規定了對哪些數據流採用哪種保護方法。配置IPSec安全策略時，通過引用ACL和IPSec安全提議，將ACL定義的數據流和IPSec安全提議定義的保護方法關聯起來，並可以指定SA的協商方式、IPSec隧道的起點和終點、所需要的密鑰和SA的生存週期等。
• 應用IPSec安全策略：爲使接口能對數據流進行IPSec保護，需要在該接口上應用一個IPSec安全策略組。當取消IPSec安全策略組在接口上的應用後，此接口便不再具有IPSec的保護功能。

 

IPSec ***應用場景分析

 

IPSec點到點應用場景

• 點到點***也稱爲局域網到局域網***，網關到網關***，主要用於兩個網關之間建立IPSec隧道，從而實現局域網之間安全地互訪。
• 點到點***兩端網關必須提供固定的IP地址或固定的域名。通信雙方都可以主動發起連接。

• 以上場景中組網需求如下：
  • PC1與PC2之間進行安全通信，在FW_A與FW_B之間使用IKE自動協商建立安全通道。
  • 爲使用pre-shared key驗證方法的提議配置驗證字。
  • FW_A與FW_B均爲固定公網地址。
• 兩個網絡的公網IP地址固定不變，且兩個網絡之間要互相訪問，可建立IKE協商的點到點方式的IPSec隧道，使兩個網絡中的設備都可以主動發起連接。
• 點到點應用場景作爲IPSec ***中最典型的場景，將在本小節中爲大家做詳細講解。

 

IPSec *** Web配置流程

• IPSec的配置使用命令行和在Web界面下進行配置有較大的差別，在Web配置界面下，配置項做了很多簡化，同時對於各種場景也做了集成，在面對不同場景需求的時候，使得配置更加簡略。

 

數據規劃

 

配置基本信息

• 配置FW_A的IPSEC隧道，FW_B與FW_A配置類似：
  • 選擇"網絡 > IPSec > IPSec"。單擊"新建"，建立一條IPSec安全策略。選擇"場景"爲"點到點"。
  • 配置IPSec策略名稱及本端接口信息。如上圖所示。
  • 選擇認證方式爲預共享密鑰，設置預共享密鑰爲huawei。
  • 選擇IKE peer中本端端口IP信息。如上圖所示。

 

配置保護的數據流

• 在"待加密的數據流"中單擊"新建"，按如下參數新增一條數據流規則，定義兩端的私網網段地址爲待加密數據流報文。

 

 

配置IKE安全提議

• 展開"安全提議"中的"高級"，配置IKE和IPSec協商參數。首先，配置IKE參數，此處可直接採用默認值配置，具體如下所示：

 

配置IPSec安全提議

• 配置IPSEC參數，此處可直接採用默認值配置，具體如下所示：

 

配置驗證

 

查看IKE SA

• display ike sa命令可以查看到的信息包括：安全聯盟的連接索引、安全聯盟的對端IP地址、***實例名稱、SA所屬階段、此安全聯盟的狀態。
• 分別在FW_A和FW_B上執行display ike sa會顯示IKE安全聯盟的建立情況。以FW_B爲例，出現以上顯示說明IKE安全聯盟建立成功。

 

查看IPSec SA

• 分別在FW_A和FW_B上執行display ipsec sa會顯示IPSec安全聯盟的建立情況。以FW_B爲例，出現以上顯示說明IPSec安全聯盟建立成功。

FW_A的配置腳本

 

#定義被保護的數據流。配置高級ACL 3000，允許10.1.1.0/24網段訪問10.1.2.0/24網段。

acl number 3000

rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255

 

#配置IKE安全提議，缺省參數可不配置。

ike proposal 1

encryption-algorithm aes-256

dh group2 //配置IKE密鑰協商時採用的DH密鑰交換參數，缺省參數爲group14。

authentication-algorithm sha2-256

authentication-method pre-share

integrity-algorithm hmac-sha2-256

prf hmac-sha2-256

 

#配置IKE對等體，缺省參數可不配置。

ike peer ike6117323732

pre-shared-key Huawei //配置預共享密鑰爲huawei。

ike-proposal 1 //引用前面已創建的IKE安全提議。

remote-id-type ip

remote-address 1.1.5.1

 

#配置IPSec安全提議，缺省參數可不配置。

ipsec proposal prop6117323732

esp authentication-algorithm sha2-256

esp encryption-algorithm aes-256

 

#配置IPSec安全策略，引用已創建的ACL、IPSec安全提議、IKE對等體。

ipsec policy ipsec6117323788 1 isakmp

security acl 3000

ike-peer ike6117323732

proposal prop6117323732

tunnel local 1.1.3.1

#

 

interface GigabitEthernet1/0/3

ip address 10.1.1.1 255.255.255.0

 

#在FW_A的外網出接口上引用已創建的IPSec安全策略。

interface GigabitEthernet1/0/1

ip address 1.1.3.1 255.255.255.0

ipsec policy ipsec6117323788

 

#將接口GE1/0/3加入Trust區域。

firewall zone trust

set priority 85

add interface GigabitEthernet1/0/3

 

#將接口GE1/0/1加入Untrust區域。

firewall zone untrust

set priority 5

add interface GigabitEthernet1/0/1

 

#配置到達對端10.1.2.0/24的路由。FW_A通往FW_B側的下一跳設備的IP地址爲1.1.3.2。

ip route-static 10.1.2.0 255.255.255.0 1.1.3.2

#

 

#

security-policy

rule name policy_ipsec_1

//配置從Trust到Untrust的域間策略，允許分支訪問總部的報文通過。

source-zone trust

destination-zone untrust

source-address 10.1.1.0 24

destination-address 10.1.2.0 24

action permit

 

rule name policy_ipsec_2

//配置從Untrust到Trust的域間策略，允許總部訪問分支的報文通過。

source-zone untrust

destination-zone trust

source-address 10.1.2.0 24

destination-address 10.1.1.0 24

action permit

 

rule name policy_ipsec_3

//配置從Untrust到Local的域間策略，允許總部到分支的ISAKMP協商報文、ESP報文通過。

source-zone untrust

destination-zone local

source-address 1.1.5.1 32

destination-address 1.1.3.1 32

action permit

 

rule name policy_ipsec_4

//配置從Local到Untrust的域間策略，允許分支到總部的ISAKMP協商報文通過。

source-zone local

destination-zone untrust

source-address 1.1.3.1 32

destination-address 1.1.5.1 32

action permit

FW_B的配置腳本與FW_A的配置腳本是對稱的，在此不再進行詳述。

 

IPSec 點到多點應用場景

 

多個分支機構與總部建立IPSec

• 業務需求：
  • 某公司總部與多個分支機構想要通過IPSec ***互通。總部的IP地址爲固定公網IP地址，部分分支的IP地址爲靜態公網IP，也有部分是內網IP或動態公網IP。

 

組網方案：IPSec點到多點應用場景

• 點到多點多用於一個總部與多個分支建立IPSec的場景。在實際的應用中，經常需要使用HUB-Spoke類型的組網，即一個總部到多個分支機構的組網，分支節點建立到總部的IPSec隧道，各個分支機構之間的通信由總部節點轉發和控制。

• 在此種場景下，網絡內數據流量可能存在如下幾種情況：
  • 各分支機構之間不需要通信

    此時只需要在總部和分支之間部署IPSec ***。

    • 各分支機構之間需要通信

    此時，若分支採用動態的公網地址接入Internet時，部署傳統的IPSec ***將存在一個問題，即分支與分支間無法直接通信，所有分支與分支間的通信數據只能由總部中轉。而總部在中轉分支間的通信流量時會消耗Hub的CPU及內存資源，造成資源緊張；另外，總部要對分支間的流量進行封裝和解封裝，會引入額外的網絡延時。

 

配置思路 (總部防火牆)

• 以上列出的配置思路中，重點在於點到多點場景的選擇，而只有總部防火牆在配置時，需要將場景選擇爲"點到多點"，對於分支防火牆（如FW_B、FW_C），仍然按照"點到點"場景的配置模式完成配置，在此方案中，將FW_B和FW_C的配置省略。

 

關鍵配置：IPSec基本配置 (FW_A)

• 在本場景中，選擇使用預共享密鑰方式進行認證。預共享密鑰設置爲Test@123。
• 選擇"網絡 > IPSec > IPSec"，單擊"新建"，參數配置如上圖所示。

 

關鍵配置：感興趣數據流 (FW_A)

• 安全提議使用缺省參數。

• 安全提議使用缺省參數。如果想要修改某個參數，展開"安全提議"中的"高級"進行設置，隧道兩端所使用的安全提議配置必須相同。
• 單擊IPSec策略配置中的"應用"。完成FW_A的配置。
• 對於其他兩個分支的配置，請參考"點到點"場景中的配置。

 

GRE Over IPSec應用場景

• 組播業務的安全傳輸
• 業務需求：
• 某公司運行了組播業務，在兩個分支之間需要進行業務傳輸，目前使用GRE隧道來完成這一需求，但GRE隧道安全性較低，管理員希望能用更高安全性的方法傳輸業務數據。

• 當需要在IPSec ***上傳輸組播、廣播和非IP報文時，如在總部和分支之間開視頻會議等組播業務，可以採用GRE over IPSec。GRE over IPSec利用了GRE和IPSec的優勢，利用GRE將組播、廣播和非IP報文封裝成普通的IP報文，通過IPSec將封裝後的IP報文安全地傳輸。

 

組網方案：GRE Over IPSec應用場景

• GRE是常用的隧道封裝協議，可以很好的實現對於組播、廣播和非IP報文的數據承載，但是GRE只有簡單的密碼驗證，沒有加密功能，數據傳輸安全性較低。 IPSec雖具備很高的數據安全傳輸能力，但其本身不支持封裝組播、廣播和非IP報文。當需要在IPSec ***上傳輸組播、廣播和非IP報文時，如在總部和分支之間開視頻會議等組播業務，可以採用GRE over IPSec。GRE over IPSec利用了GRE和IPSec的優勢，利用GRE將組播、廣播和非IP報文封裝成普通的IP報文，通過IPSec將封裝後的IP報文安全地傳輸。
• GRE over IPSec使用的封裝模式爲可以是隧道模式也可以是傳輸模式。因爲隧道模式跟傳輸模式相比多增加了IPSec頭，導致報文長度更長，更容易導致分片。所以推薦採用傳輸模式GRE over IPSec。

 

GRE Over IPSec配置思路 (CLI)

• 配置GRE Over IPSec時，推薦使用命令行的方式進行配置。
• IPSec安全框架定義了對數據流的保護方法，如使用的IPSec安全提議、用於自動協商SA所需要的IKE協商參數、SA的生存週期以及PFS特性。一個IPSec安全框架相當於一個IPSec安全策略，與IPSec安全策略不同的是，安全框架由名稱唯一確定，且只能通過IKE協商方式配置。
• IPSec安全框架無需通過ACL定義數據流，而是保護所有路由到IPSec虛擬隧道接口的數據流。在IPSec虛擬隧道接口下應用IPSec安全框架後只會生成一條IPSec隧道，並對所有路由到該隧道接口的數據流進行IPSec保護，簡化了安全策略管理的複雜度。
• 爲保證IKE協商成功，安全框架中所有配置的參數必須在本端和對端相匹配。

 

關鍵配置

 

IPSec ***故障排除

 

IPSec診斷工具與方法 – Web診斷

 

IPSec診斷工具與方法 – CLI診斷命令

• 如果能同時查看到完整的IKE SA及IPSec SA信息，則表示IPSec隧道建立成功。

 

IPSec ***故障總體處理思路

• IPSec故障分析可以按照故障出現的先後順序從以下幾個現象入手：
  • 配置階段：IPSec配置界面不可見。
  • 業務觸發階段：沒有數據流觸發IKE協商。
  • IKE協商階段：IKE協商不成功（IKE SA、IPSec SA協商不成功）。
  • 數據傳輸階段：IKE協商成功，但***業務異常（不通或質量不好）。
• 其中IKE協商不成功是IPSec故障的核心問題，可以結合IKE協商過程進行深入分析；其它故障僅表現爲IPSec業務故障，根因皆爲NGFW基本特性的錯誤配置，如license、接口、鏈路、路由、安全區域、NAT等，需要結合具體場景來處理。

 

沒有數據流觸發IKE協商

 

IKE SA協商不成功

 

IPSec SA協商不成功

 

案例一：故障現象

• 在兩臺FW之間建立IPSec隧道。組網如上圖所示。在修改參數之前，隧道能夠建立成功。當在FW_B的公網接口增加了sub地址並修改某些配置後，發現隧道建立不成功。經檢查，兩端IPSec和IKE參數配置均正確。路由、接口、安全策略等配置也正確。

 

案例一：故障分析

• 本例中故障由配置sub地址引起，故猜測可能是本端的"對端網關"和對端的"本地地址"不匹配導致的，執行display ike peer命令觀察到FW_A的RemoteAddr和FW_B的local-address不一致。

 

案例一：故障處理

 

案例一：問題總結

• 在配置IPSec安全策略時，local-address命令爲可選配置。當本端發起IPSec隧道協商的IP地址與實際應用IPSec策略的接口IP地址不同時，需要配置local-address爲本端發起協商的IP地址，且該地址需要和對端使用remote-address命令設置的目的地址一致。
• 本案例是由於FW_B指定了隧道本端地址爲sub地址，引起對端的remote-address和本端的local-address不匹配導致IKE協商失敗。

 

案例二：故障現象

• 在FW_A與FW_B之間建立點到點的IPSec ***。配置完成後，從PC1 ping PC2，無法ping通；從PC2 ping PC1，可以ping通，並正常建立隧道。經檢查，各PC的IP地址、網關等基本配置無誤；FW_A和FW_B的IP地址、路由、安全域和域間策略等基本配置都無誤。

 

案例二：故障分析

 

案例二：故障處理與總結

• 隧道兩端配成鏡像並不是必要條件，IKEv1要求兩端配置的ACL規則互爲鏡像或發起方配置的ACL規則爲響應方的子集。IKEv2取雙方ACL規則交集作爲協商結果。
• 實際配置中建議將隧道兩端的ACL規則配成互爲鏡像，即簡單也不容易出錯。

 

實驗

點到點IPSec ***

FW1的配置，FW2反向配置

acl number 3000

rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.3.0 0.0.0.255

 

ike peer ike_fw2

pre-shared-key huawei@123

remote-address 1.1.5.1

 

[FW1]ipsec proposal ipsec_pro

 

ipsec policy policy_fw1 1 isakmp

security acl 3000

ike-peer ike_fw2

proposal ipsec_pro

 

interface GigabitEthernet1/0/0

undo shutdown

ip address 1.1.3.1 255.255.255.0

service-manage ping permit

ipsec policy policy_fw1

 

排錯命令：

dis ike sa

dis ike sa verbose

dis ipsec sa

dis ipsec statistics

dis ike proposal

dis ike peer

dis ike peer brief

dis ipsec proposal

dis ipsec policy

dis firewall session table verbos

 

基於路由方式ipsec ***

需求：

使用IPSec ***基於路由方式，使PC1訪問PC2

 

思路：

1. 創建Tunnel接口
2. 設置***路由,將流量引入Tunnel接口
3. 配置ike peer
4. 配置ipsec proposal，修改爲傳輸模式
5. 配置ipsec profile
6. 在tunel接口中調用

 

步驟：SZ_***設置

1. 創建tunnel 0 接口

interface Tunnel0

ip address 10.1.1.1 255.255.255.0

 

1. 將tunnel 0 加入gre安全區域

firewall zone name gre id 4

set priority 10

add interface Tunnel0

 

1. 設置設置GRE ***

interface Tunnel0

ip address 10.1.1.1 255.255.255.0

tunnel-protocol gre

source 202.1.1.1

destination 101.1.1.1

 

1. 設置***路由

ip route-static 192.168.2.0 255.255.255.0 Tunnel0

 

1. 設置ike peer

ike peer ike-1

pre-shared-key Huawei@123

remote-address 101.1.1.1

 

1. 設置ipsec proposal，設置爲傳輸模式

ipsec proposal ipsec-pro

encapsulation-mode transport

esp authentication-algorithm sha2-256

esp encryption-algorithm aes-256

 

1. 設置ipsec profile

ipsec profile profile1

ike-peer ike-1

proposal ipsec-pro

 

1. 在tunnel接口中調用

interface Tunnel0

ip address 10.1.1.1 255.255.255.0

tunnel-protocol gre

source 202.1.1.1

destination 101.1.1.1

ipsec profile profile1

 

 

IPSec點到多點應用場景

需求：

1. 深圳總部使用點到多點IPSec *** 連接廣州分部，廣州分部無固定IP

2. 深圳總部使用點到多點IPSec *** 連接北京分部，北京分部有固定IP

 

命令行：

廣州分部使用動態IP地址，先設置北京分部，模擬器會出現問題

SZ_FW：深圳總部配置：

ike peer中沒有設置remote-address，所以必須由廣州分部先產生數據流，

深圳總部才能建立隧道

 

連接廣州分部：

acl number 3000

rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255

 

ike peer ike_sz

undo version 2

pre-shared-key huawei@123

 

ipsec proposal ipsec_pro_sz

 

ipsec policy-template ipsec_tem_sz 1

security acl 3000

ike-peer ike_sz

proposal ipsec_pro_sz

 

[SZ_FW]ipsec policy ipsec_pol_sz 1 isakmp template ipsec_tem_sz

//此命令，在調用北京分部之後再調用，不然IKE SA第二階段無法創建

 

interface GigabitEthernet1/0/0

undo shutdown

ip address 202.1.1.1 255.255.255.0

service-manage ping permit

ipsec policy ipsec_pol_sz

廣州分部和北京分部配置和前面普通配置一樣。

 

連接北京分部，北京分部使用固定IP地址：

acl number 3001

rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.3.0 0.0.0.255

 

ike peer ike_bj

undo version 2

pre-shared-key huawei@123

remote-address 50.1.1.1

 

ipsec proposal ipsec_pro_sz

//經測試可以公用一個安全提議

 

ipsec policy ipsec_pol_sz 2 isakmp

security acl 3001

ike-peer ike_bj

proposal ipsec_bj

 

IPSec *** 和NAT組合案例：

 

 

 

北京的ipsec ***和nat在同一個設備上，深圳的 ipsec ***和nat不在同一設備上

需求：

PC1能夠ping通PC2。

北京設置EASY-IP使內網能夠訪問外網。

 

思路：

1. 在NAT_FW設置nat server
2. 在SZ_FW_***中設置ipsec ***,隧道的源IP：172.16.12.1 目標IP：101.1.1.1
3. 在BJ_FW_***設置ipsec ***，隧道的源IP：101.1.1.1 目標IP：202.1.1.1
4. 設置安全策略

 

深圳

NAT_FW：

1. 設置NAT_Server：先放行所有協議，查看會話表之後再回來設置

nat server nat_isakmp protocol udp global interface GigabitEthernet1/0/1 500 in

side 172.16.12.1 500

nat server nat_esp protocol udp global interface GigabitEthernet1/0/1 4500 insi

de 172.16.12.1 4500

 

SZ_FW_***:

1. 設置ACL

acl number 3000

rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255

 

2. 配置ike peer：

ike peer ike_bj

undo version 2

pre-shared-key huawei@123

remote-address 101.1.1.1

 

3. 配置ipsec proposal

[SZ_FW_***]ipsec proposal ipsec_pro_sz

//使用默認配置

 

4. 配置ipsec policy

ipsec policy ipsec_pol_sz 1 isakmp

security acl 3000

ike-peer ike_bj

proposal ipsec_pro_sz

 

5. 在出接口上調用

interface GigabitEthernet1/0/1

undo shutdown

ip address 172.16.12.1 255.255.255.0

service-manage ping permit

ipsec policy ipsec_pol_sz

 

北京

BJ_FW_***：

1. 設置ACL

acl number 3000

rule 5 permit ip source 192.168.2.0 0.0.0.255 destination 192.168.1.0 0.0.0.255

 

2. 配置ike peer

ike peer ike_sz

undo version 2

pre-shared-key huawei@123

remote-address 202.1.1.1

//遠端地址是202.1.1.1

 

3. 配置ipsec proposal

ipsec proposal ipsec_pro_bj

 

4.配置ipsec policy

ipsec policy ipsec_pol_bj 1 isakmp

security acl 3000

ike-peer ike_sz

proposal ipsec_pro_bj

 

5. 出接口調用

interface GigabitEthernet1/0/1

undo shutdown

ip address 101.1.1.1 255.255.255.0

service-manage ping permit

ipsec policy ipsec_pol_bj

 

6. 設置EASY-IP NAT 使北京內網能訪問公網

nat-policy

rule name to_wan

source-zone trust

egress-interface GigabitEthernet1/0/1

source-address 192.168.2.0 mask 255.255.255.0

action source-nat easy-ip

 

以上代碼會出現PC2無法ping通PC1的情況。造成此情況的原因是：源NAT策略的優先級高於

報文地址轉換（ipsec ***），導致PC2-->PC1流量的源IP地址直接被源NAT轉換了。

ipsec *** 無法抓取流量進行轉換。解決辦法如下：

 

rule name ipsec_***

source-zone trust

destination-zone untrust

source-address 192.168.2.0 mask 255.255.255.0

destination-address 192.168.1.0 mask 255.255.255.0

action no-nat

 

nat策略匹配規則是從上往下精確匹配，所以還需要調整ipsec_***的位置。

 

[BJ_FW_***-policy-nat]rule move ipsec_*** before to_wan

 

IPSec ***安全策略

需求：

使用IPSec *** 使PC1和PC2互訪，配置相關防火牆的安全策略

 

思路：

1. 將防火漆的defaul安全策略設置爲permit，配置ipsec ***使PC1和PC2能互訪。（省略）

2. 關閉SZ_***的defaul安全策略，配置PC1-->PC2的安全策略

3. 關閉GZ_***的defaul安全策略，配置PC2-->PC1的安全策略

 

命令：

2. 配置PC1-->PC2的安全策略

security-policy

rule name ipsec_icmp

source-zone trust

destination-zone untrust

source-address 192.168.1.0 mask 255.255.255.0

destination-address 192.168.2.0 mask 255.255.255.0

service icmp

action permit

 

rule name ipsec_icmp_gz

source-zone local

source-zone untrust

destination-zone trust

source-address 192.168.2.0 mask 255.255.255.0

destination-address 192.168.1.0 mask 255.255.255.0

service icmp

action permit

 

rule name ipsec_esp_gz

source-zone untrust

destination-zone local

source-address 101.1.1.1 mask 255.255.255.255

destination-address 202.1.1.1 mask 255.255.255.255

service esp

action permit

 

rule name ipsec_isakmp

source-zone local

source-zone untrust

destination-zone local

destination-zone untrust

source-address 101.1.1.1 mask 255.255.255.255

source-address 202.1.1.1 mask 255.255.255.255

destination-address 101.1.1.1 mask 255.255.255.255

destination-address 202.1.1.1 mask 255.255.255.255

service protocol udp source-port 500 destination-port 500

action permit

 

原理分析：

1. PC1發出icmp報文，源IP：192.168.1.100目的IP：192.168.2.100

報文到達防火牆，防火牆查找路由表，匹配默認路由。得出區域：

trust-->untrust。將報文轉到g1/0/0口，匹配ipsec ***，將源目

地址轉換爲202.1.1.1-->101.1.1.1，由於華爲防火牆默認發出***

不需要安全策略，此安全策略可以省略。

2. PC2使用esp報文返回，源目IP：101.1.1.1-->202.1.1.1，到達防火牆查路

由表，區域爲：untrust-->local

3. 由PC2發送icmp給PC1：

a. 此時報文類型爲esp報文，源目IP：101.1.1.1-->202.1.1.1，匹配安全

策略ipsec_esp_gz，經過ipsec ***轉換後查路由表發往接口g1/0/1。

b. 此時報文類型爲icmp，源目IP：192.168.2.100-->192.168.1.100

由於經過ipsec ***解密等操作後防火牆重新封裝的報文，所以源區域

爲local，目標區域爲trust。

4. 缺少isakmp的報文，無法連接。原理和上面第3點類似。