VPN：IPSec VPN工作原理

在Internet公網進行的數據傳輸中，絕大部分數據的內容都是采用明文方式進行的，如我們在QQ、微信中的聊天、平時所進行的數據傳輸等。這樣就會存在很多潛在的危險，比如銀行賬戶、密碼，或者其他一些敏感的信息被一些別有用心的人非法竊取、篡改，最終可能導致用戶的身份被冒充，銀行賬戶被非法取現等。

如果在網絡中部署IPSec，不僅可以保證數據的完整性和來源的合法性，還可以確保數據傳輸的機密性，保障了用戶業務傳輸的安全，降低信息泄漏的風險。

IPSec VPN主要也是利用Internet構建VPN的，用戶可以任意方式（如專線接入方式、PPPo E撥號接入方式，甚至傳統的Modem、ISDN撥號方式）接入Internet，且不受地理因素的限制。所以，IPSec VPN不僅適用于移動辦公員工、商業伙伴接入，也適用于企業分支機構之間站點到站點（Site-to-Site）的互連互通，如圖1所示。

圖1 IPSec VPN的應用

在出差員工、SOHO辦公用戶通過IPSec VPN訪問公司總部網絡的情形中，這些移動辦公用戶需要部署使用Windows（Windows 7/8/10系統中支持采用IKEv2動態協商）、Linux桌面操作系統中自帶的IPSec VPN客戶功能。

1. IPSec的安全機制

IPSec是“IP Security”（IP安全）的簡稱，不是一個單獨的協議，是一個框架性架構，是一系列為IP網絡提供安全性的協議和服務的集合，如AH（Authentication Header，認證頭）、ESP（Encapsulating Security Payload，封裝安全載荷）安全協議，IKE（Internet Key Exchange，Internet密鑰交換）協議、ISAKMP（Internet Security Association and Key Management Protocol，因特網安全與密鑰管理協議），以及各種認證、加密算法等，它們之間的關系如圖2所示。

圖2 IPSec體系架構

AH和ESP是IPSec的兩種安全協議，用于實現IPSec在身份認證和數據加密方面的安全機制。身份認證機制可使IP通信的數據接收方能夠確認數據發送方的真實身份和數據在傳輸過程中是否遭篡改；數據加密機制通過對數據進行加密運算來保證數據的機密性，以防數據在傳輸過程中被竊聽。IPSec架構中的AH協議定義了認證的應用方法，提供數據源認證和完整性保證；ESP協議定義了加密和可選認證的應用方法，比AH協議可提供更全面的安全保證。

具體來說，AH協議提供數據源認證、數據完整性校驗和防報文重放功能。它能保護通信數據免受篡改，但不能防止竊聽（因為它不會對數據進行加密），適合用于傳輸非機密數據。AH的工作原理是在原始數據包中添加一個身份認證報文頭，為數據提供完整性保護。AH可選擇的認證算法有MD5（Message Digest，消息摘要）、SHA-1（Secure Hash Algorithm 1，安全哈希算法-1）、SM3等。

ESP協議提供數據加密、數據源認證、數據完整性校驗和防報文重放功能，比AH協議功能更全面。ESP的工作原理是在原始數據包中添加一個ESP報文頭，并在數據包后面追加一個ESP尾和可選的ESP認證數據。ESP可選的加密算法有DES（Data Encryption Standard，數據加密標準）、3DES（Triple DES，三倍DES）、AES（Advanced Encryption Standard，高級加密標準）、SM1等。同時，作為可選項，在ESP認證數據部分，還可選擇MD5、SHA-1、SM3算法保證報文的完整性和真實性。

在進行IP通信時，可以根據實際安全需求選擇使用其中的一種或同時使用這兩種協議，但同時使用兩種安全協議比較少見，因為AH和ESP的認證功能是重疊的，且在一個數據包同時增加兩種協議頭，會影響數據的有效傳輸率。

在實際的應用中，更多的是選擇ESP協議，原因主要有兩個：一是因為AH無法提供數據加密，所以數據傳輸的安全性較差，而ESP提供數據加密；二是因為AH協議的認證范圍包括整個IP數據包，如果兩端IPSec設備間存在NAT設備會導致數據包的IP報頭中的IP地址發生改變，從而最終導致認證失敗，無法實現NAT穿越；而ESP協議的認證范圍是不包括最外層的IP報頭的，所以即使IP報頭部分的地址信息發生改變，也不會導致最終的認證失敗，即可以實現NAT穿越，應用范圍更廣。

2. IPSec的兩種封裝模式

IPSec有“隧道”和“傳輸”兩種封裝模式。數據封裝是指將AH或ESP協議相關的字段插入到原始IP數據包中，以實現對報文的身份認證和加密，下面分別具體介紹。

（1）隧道（Tunnel）模式

隧道模式下的安全協議用于保護整個IP數據包，即用戶的整個IP數據包都被用來計算安全協議頭，生成的安全協議頭以及加密的用戶數據（僅針對ESP封裝）被封裝在一個新的IP數據包中。也就是在隧道模式下，封裝后的IP數據包有內、外兩個IP報頭，其中的內部IP報頭為原IP報頭（Raw IP Header），外部IP報頭（New IP Header）是新增加的IP報頭。新添加的IP報頭中的源IP地址是本端IPSec設備應用IPSec安全策略的接口的IP地址，目的IP地址是對端IPSec設備應用IPSec安全策略的接口的IP地址，其目的就是在把用戶發送的數據包從本端IPSec設備傳輸到對端IPSec設備，至于到達對端IPSec設備后數據包的轉發是由IPSec設備所配置的內網路由表來完成，當然，此時路由轉發的是在IPSec設備上解封裝并且解密后的原始IP數據包。

在隧道封裝模式中，AH報頭或ESP報頭插在原IP報頭之前，并另外生成一個“新IP報頭”放到AH報頭或ESP報頭之前。以TCP通信為例（其他協議報文同樣支持），單獨使用AH協議、ESP協議，或者同時使用AH和ESP協議時，重封裝后的IP報文格式分別如圖3的上、中、下所示。

圖3 隧道模式下IP報文重封裝的結構

圖3中的AH報頭包含了對整個新IP報文經過MD5/SHA/SM3等認證算法運算后的摘要消息，用于進行身份認證。ESP協議的認證信息是在“ESP認證數據”字段中，包括了“ESP報頭”，以及經過加密的整個原IP報文和“ESP尾”這幾個部分（不包括新IP報頭）的數據經過MD5/SHA/SM3等算法運算后的摘要。但ESP協議僅對原IP報文和“ESP尾”通過DES/AES/3DES/SM1等加密算法運算進行加密。

從圖3中可以看出，在隧道模式中，如果采用了AH協議，AH協議的認證范圍是整個新生成的IP數據包（包括新生成的IP報頭），只要發生了數據變化（包括協議所識別的最外層IP報頭地址信息：最初是原IP報頭，重封裝后是新IP報頭）則會導致認證失敗，這也決定了采用AH協議時是不能實現NAT穿越的，因為如果有NAT設備的話，最外層IP報頭的地址信息肯定會發生變化。而如果單獨采用ESP協議，認證范圍則不包括“新IP報頭”和“ESP認證數據”這兩個字段，而原IP報頭信息不會發生變化，所以單獨采用ESP作為安全協議時，是可以穿越NAT的。

采用ESP協議進行數據加密時的加密范圍則包括“原IP報頭、數據部分（包括傳輸層協議頭和“數據”字段）、“ESP尾”這三個字段，使得“原IP報頭”也受到保護，防止了惡意用戶修改了原始報頭地址信息。

隧道模式在兩臺主機點對點連接的情況下，因為原始IP報頭放在了AH或ESP報頭之后，隱藏了內網主機的私網IP地址（新生成的IP 報頭源IP地址為網關的公網IP地址），可保護整個原始數據包傳輸的安全。隧道模式通常用于保護兩個安全網關之間的數據，實現站點到站點（Site-to-Site）的安全連接，如圖4所示。

圖4 隧道模式下的典型應用

當在IPSec設備是由路由器或防火墻設備提供時，即數據包進行安全傳輸的起點或終點不為數據包的實際起點和終點時，則必須使用隧道模式，因為這時需要對原始IP數據包中的私網地址進行轉換（通過重封裝，添加新IP報頭來實現，而不是NAT），否則不能在公網Internet中進行路由轉發。此時的IPSec隧道就是在兩端的IPSec設備之間。

（2）傳輸（Transport）模式

傳輸模式下的安全協議主要用于保護上層協議（如傳輸層協議）報文，僅傳輸層數據被用來計算安全協議頭，生成的安全協議頭以及加密的用戶數據（僅針對ESP封裝）被放置在原IP報頭后面。即在傳輸模式下，不對原IP報文進行重封裝，只是把新添加的認證頭當成原始IP報文的數據部分進行傳輸。

此時，AH報頭或ESP報頭被插入到IP報頭之后，但在傳輸層協議頭之前。也以TCP通信為例（其他協議報文同樣支持），單獨使用AH協議、ESP協議，或者同時使用AH和ESP協議時，重封裝后的IP報文格式分別如圖5的上、中、下所示。

圖5 傳輸模式下IP報文重封裝的結構

從圖5中可以看出，在傳輸模式中，AH報頭中也包括了對整個IP報文采用MD5/SHA/SM3等認證算法運算后的摘要；ESP協議的認證信息也是在“ESP認證數據”字段中，是對經過加密的“ESP報頭”、IP報文的數據部分（包括傳輸層協議頭和“數據”字段）和“ESP尾”這三部分的數據經過MD5/SHA/SM3等算法運算后的摘要，ESP協議僅對IP報文中的數據部分和“ESP尾”這兩部分通過DES/AES/3DES/SM1等加密算法運算進行加密。所以，從認證或加密的范圍來看，它與隧道模式是一樣的，即采用AH協議時，認證的范圍包括整個IP數據包：僅采用ESP協議時認證的范圍是除“IP報頭”“ESP認證數據”這兩個字段之外的其他部分，而ESP對數據的加密范圍仍僅包括IP報文的數據部分“ESP尾”這幾個部分，因為這是由AH和ESP協議的特性決定的。

當要求點對點（或稱“端到端”—End-to-End）的安全保障，即數據包進行安全傳輸的起點和終點為數據包的實際起點和終點時才可以使用傳輸模式（這種情形下也可以采用隧道模式），因為這時不用對用戶發送的IP數據包進行重封裝，只需要實現點對點的通信即可。所以，傳輸模式通常用于保護兩臺主機之間的數據通信，如圖6所示。這時兩端主機需要分別配置為IPSec VPN客戶端和IPSec VPN服務器，可分別使用Windows、Linux桌面/服務器操作系統來配置。

圖6 傳輸模式下的典型應用

（3）兩種封裝模式的比較

傳輸模式應用的比較少，僅適用于點對點的安全保護模式，站點到站點，或者點對站點的連接情形均不能采用傳輸模式。下面總體比較隧道模式和傳輸模式的主要特性。

從安全性來講，隧道模式優于傳輸模式，因為隧道模式可以完全地對原始IP數據包進行認證和加密，隱藏客戶機的私網IP地址，而傳輸模式中的數據加密是不包括原始IP報頭的。

從性能來講，因為隧道模式有一個額外的IP頭，所以它將比傳輸模式占用更多帶寬，有效傳輸率較低。

使用傳輸模式的充要條件：要保護的數據流必須完全在發起方、響應方IP地址范圍內，如發起方IP地址為6.24.1.2，響應方IP地址為2.17.1.2，那么要保護的數據流僅可以是源6.24.1.2/32、目的是2.17.1.2/32，而不能是其他任意地址。當然這里IP地址后綴32僅代表必須與發起方，或響應方的地址精確匹配（類似于ACL中的通配符掩碼），不代表所在的網絡。

3. AH報頭和ESP報頭格式

（1）AH報頭格式

AH協議是位于網絡層，其IP協議號是51，但位于IP協議之上，所以AH報文需要經過IP協議封裝。AH報頭格式如圖7所示，各字段說明如下。

圖7 AH報頭格式

下一個頭部：8位，標識AH報頭之后第一個上層協議頭的類型，傳輸模式下，是被保護的上層協議（TCP或UDP）或ESP協議的編號；隧道模式下，是IP協議或ESP協議的編號。當AH與ESP協議同時使用時，AH報文頭的下一頭部為ESP報文頭。

載荷長度：8位，以4個字節為單位表示接受保護的整個數據的長度。

保留：16位，預留以后使用。

安全參數索引（Security Parameter Index，SPI）：32位，用于唯一標識IPSec安全聯盟。

序列號：32位，是一個從1開始，并以1進行遞增的計數器值，表示通過安全聯盟所發送的數據包序號，用于抗重放攻擊。

認證數據：長度可變，但必須是32位的整數倍，否則要進行填充。包含對數據包通過相應的摘要算法計算的ICV（Integrity Check Value，完整性校驗值），也稱MAC （Message Authentication Code，消息驗證碼），是一個消息摘要，用于接收方進行完整性校驗。可選擇的認證算法有MD5（Message Digest）、SHA-1（Secure Hash Algorithm）、SHA-2、SM3。

（2）ESP報頭格式

ESP協議的IP協議號是50，與AH協議一樣，也位于網絡層的IP協議之上，所以ESP報文也需要經過IP協議封裝。ESP除提供AH協議的功能之外，還提供對有效載荷的加密功能。

在IPv4報文中，ESP報頭緊隨在IPv4報頭之后。在IPv6報文中，ESP報頭的位置與是否存在擴展報頭有關，如果有“目的地選項”擴展報頭，則ESP報頭必須在此擴展報頭之前，如果有其他擴展報頭，則ESP報頭必須在這些擴展報頭之后；如果沒有擴展報頭，IPv6報頭的“下一個頭”字段就會設為50，代表是ESP報頭。

ESP的工作原理是在每一個數據包的標準IP報頭后面添加一個ESP報文頭，并在數據包后面追加一個ESP尾（ESP尾部和ESP認證數據），我們把這整個部分稱之為ESP報頭，格式如圖8所示。

圖8 ESP報頭格式

安全參數索引：32位，用于唯一標識IPSec安全聯盟。

序列號：32位，是一個從1開始，并以1進行遞增的計數器值，表示通過通信的安全聯盟所發送的數據包數，用于抗重放攻擊。

負載數據：包含由下一頭部字段所包括整個的可變長數據。

填充：0～255個字節，填充字段的長度與負載數據的長度和算法有關，用來確保所加密的數據塊長度達到加密算法所需的字節要求，具體的填充方式要視所采用的加密算法而定。

填充長度：表示“填充”字段的長度（以字節為單位）。在使用了填充字節的加密數據塊解密之后，接收方就可知道要刪除多少個填充字節。為0時表示沒有填充。

下一個頭部：8位，標識ESP報文頭后面的下一個負載協議類型。傳輸模式下，是被保護的上層協議（TCP或UDP）的編號；隧道模式下，是IP協議的編號。

認證數據：長度為32比特的整數倍，通常為96比特。包含完整性校驗值（ICV），用于接收方進行完整性校驗，可選擇的認證算法與AH的相同。ESP的驗證功能是可選的，如果啟動了數據包驗證，會在加密數據的尾部添加一個ICV數值。

表1給出AH協議和ESP協議在一些參數特性上的比較。

表1 AH協議與ESP協議的比較

4. IPSec隧道建立原理

IPSec隧道的建立，其實就是在隧道兩端的設備上建立好SA（Security Association，安全聯盟）。但SA的建立有兩種方式：一種是手工方式，直接在兩端的IPSec設備配置好具體的安全參數，包括對等體地址、封裝模式、安全協議、認證方法、認證算法和加密算法，出/入方向SA的認證密鑰和加密密鑰、出/入方向SA的SPI（Security Parameter Index，安全參數索引）等，最終直接在兩端設備間建立雙向IPSec SA，建立IPSec隧道。

IPSec用于在協商發起方和響應方這兩個端點之間提供安全的IP通信，通信的兩個端點被稱為IPSec對等體，可以是網關路由器，也可以是用戶主機。IPSec為對等體間建立IPSec隧道來提供對數據流的安全保護。一對IPSec對等體間可以存在多條IPSec隧道，可以針對不同的數據流各選擇一條隧道對其進行保護，例如有的數據流只需要認證，有的則需要同時認證和加密。

建立IPSec隧道的另一種方式是通過IKE協議來動態協商的，這時IPSec SA的建立不那么直接了，而是要先在隧道兩端協商建立IKE SA（在此過程中會生成認證密鑰和加密密鑰，無需手工配置了），然后再在此基礎上協商建立IPSec SA（此階段還可生成新的直接用于用戶數據加密的加密密鑰），最終建立IPSec隧道。

無論哪種IPSec隧道建立方式，SA的建立是關鍵，在使用IPSec保護數據之前，必須先建立SA。SA是IPSec對等體間對某些要素的約定（即安全策略），例如，所使用的安全協議（AH、ESP或兩者結合使用）、協議報文的封裝模式（傳輸模式或隧道模式）、認證算法（HMAC-MD5或HMAC-SHA1等）、加密算法（DES、3DES或AES等）、共享密鑰以及密鑰的生存時間等。對等體間需要通過手工配置或IKE協議協商匹配的參數后才能建立SA。即對等體間只能在雙方最終確定（可以直接通過手工方式配置確定，或者通過IKE協議協商確定）所采用SA后才能建立對等體關系。手工方式建立SA時，所需的全部信息都必須由我們網絡管理人員手工配置，所建立的SA永不老化。IKE動態協商方式建立SA時，由IKE協議完成密鑰的自動協商，所建立的SA具有生存時間。

SA是出于安全目的而創建的一個單向邏輯連接，所有經過同一SA的數據流都會得到相同的安全服務，如AH或ESP。正因如此，對等體之間的雙向通信需要建立一對（即兩個方向各一個）SA，即一對SA（兩個）對應于一條IPSec隧道。如果兩個對等體希望同時使用AH和ESP來進行安全通信，則每個對等體都會針對每一種協議來構建一個獨立的SA，則在對等體間至少有2對（四個）SA。

IPSec建立的SA和隧道關系如圖9所示，數據從對等體A發送到對等體B時，對等體A對原始數據包進行加密，加密數據包在IPSec隧道中傳輸，到達對等體B后，對等體B對加密數據包進行解密，還原成原始數據包。數據從對等體B發送到對等體A時，處理方式類似，但所用的SA不同。

圖9 IPSec建立的SA和隧道示意

SA由一個三元組來做唯一標識，包括SPI、目的IP地址（對端對等體的IP地址）和使用的安全協議（AH或ESP）。其中，SPI是用于標識SA的一個32比特的數值，在AH或ESP報頭中標識，可用于在接收端識別數據與SA的綁定關系。因為可以從接收到的數據的AH或ESP報頭獲知對應的SPI，然后看與本端配置的哪個入方向的SPI一致，以此可確定所接收的數據是采用哪個SA。在SPI的配置中，要求本端的出方向SA的SPI必須和對端的入方向的SPI一樣，相反，本端的入方向SA的SPI也必須和對端的出方向SA的SPI一樣。為保證SA的唯一性，出/入方向SA的SPI值不能設置成相同值，即不同的SA必須對應于不同的SPI。