淺談常見的隧道技術之IPSec

作者：吳琪，單位：中國移動智慧家庭運營中心

IPSec（IP security）是IETF制定的三層隧道加密協(xié)議，它為Internet上傳輸?shù)臄?shù)據(jù)提供了高質量的、可互操作的、基于密碼學的安全保證。因為其安全性特點，IPSec被廣泛應用。

IPSec不是一個單獨的協(xié)議，而是一套網絡安全協(xié)議族，包括網絡認證協(xié)議AH（Authentication Header，認證頭）、ESP（Encapsulating Security Payload，封裝載荷）和密鑰管理協(xié)議IKE（Internet Key Exchange， 因特網密鑰交換）以及用戶網絡認證及加密的一些算法等。

IPSec工作模式分為：傳輸模式（transport）和隧道模式（tunnel）兩種。簡單來說傳輸模式是原始二層數(shù)據(jù)包不再附加二三四層頭、隧道模式是原始二層數(shù)據(jù)包經過協(xié)議隧道封裝是添加上二三四層頭，IPSec的隧道模式就是在原始的ip數(shù)據(jù)包外面再封裝了一層ip頭，所以IPSec也經常被大家稱作三層隧道協(xié)議。下面就帶大家詳細的了解一些這些具體的協(xié)議，以及IPSec協(xié)議實際應用中占據(jù)重要地位的穿越NAT實現(xiàn)。

Part 01●??安全協(xié)議——AH協(xié)議?●

AH協(xié)議是一種基于IP的傳輸協(xié)議，協(xié)議號為51。具體工作方式是在每一個數(shù)據(jù)包的標準IP報文頭部后面添加一個AH報文頭：

AH協(xié)議發(fā)送方會對數(shù)據(jù)包和認證密鑰進行hash計算，接收方收到報文之后，按照一樣的算法進行hash計算并與原計算結果進行比較，如果不一致，可以推斷出數(shù)據(jù)包在傳輸過程中遭到了修改或者破壞。通過這樣的方式，能提供數(shù)據(jù)來源認證和數(shù)據(jù)完整性校驗。值得一提的是AH協(xié)議的完整性校驗范圍是整個IP報文。

AH報文頭中有幾個重要的字段值得關注：安全參數(shù)索引（SPI）用于唯一標識IPSec安全聯(lián)盟，序列號唯一標識每一個數(shù)據(jù)包，能用于防重放攻擊。

Part 02●? 安全協(xié)議——ESP協(xié)議?●

和AH協(xié)議一樣，ESP協(xié)議也是一種基于IP的傳輸層協(xié)議，協(xié)議號為50。具體的工作方式是在每一個數(shù)據(jù)包的IP報文頭后面添加一個ESP報文頭，值得注意的是，在數(shù)據(jù)包尾部還追加一個ESP尾部（ESP Tail和ESP Auth Data），同時還有一點與AH協(xié)議不同的是，ESP協(xié)議僅對IP數(shù)據(jù)包的有效載荷進行加密，對IP報文頭是沒有進行加密保護的。

和AH協(xié)議類似，ESP報文頭中也有安全參數(shù)索引（SPI）和序列號兩個字段，并且，AH協(xié)議和ESP協(xié)議的認證算法是相通的。

AH協(xié)議和ESP協(xié)議具體的比較如下：

總結：AH協(xié)議不能提供數(shù)據(jù)包加密功能，ESP協(xié)議驗證范圍不包括IP頭部，故在安全性要求較高的場景中可以考慮聯(lián)合使用AH協(xié)議和ESP協(xié)議。

Part 03●??IKE協(xié)議?●

簡單來說，IKE協(xié)議是動態(tài)協(xié)商IPSec隧道的協(xié)議，能完成身份驗證、密鑰交換、生成IPSec SA，協(xié)商過程中，數(shù)據(jù)包具體采用AH協(xié)議還是ESP協(xié)議封裝以及身份認證就定下來了。

IKE協(xié)議目前有兩個版本：IKEv1和IKEv2，IKEv2在v1的基礎上，不僅簡化了SA的協(xié)商過程，提高了協(xié)商效率，而且修復了多處公認的密碼學方面的安全漏洞，提高了安全性能，所以實際IKEv2應用更加廣泛。

以IKEv2為例，通過初始交換可以協(xié)商建立第一對IPSec SA，這其中包含兩次交互四條消息，包含加密和驗證算法等參數(shù)協(xié)商，生成共享密鑰，完成身份認證、消息認證。如果需要創(chuàng)建多對IPSec SA，可以通過創(chuàng)建子SA交換過程協(xié)商出來，同時在協(xié)商過程中存在一些控制信息的傳遞，例如錯誤消息或者通告消息，這些信息是通過通知交換完成的。

Part 04●??NAT穿越?●

IPSec協(xié)議能得到廣泛應用，除了能提供安全加密的傳輸之外，另一個重要原因是能夠實現(xiàn)NAT穿越，這在現(xiàn)網傳輸中是極其重要的，因為公網IP資源有限，絕大部分設備都是通過NAT轉換之后共享公網IP資源傳輸交換報文的，所以穿越NAT在現(xiàn)網應用中是極其重要的。

如前文描述的AH協(xié)議和ESP協(xié)議的特點，我們發(fā)現(xiàn)AH協(xié)議不能穿越NAT，原因是NAT會修改報文的IP頭，但是AH完整性校驗是基于整個IP報文的，所以導致AH協(xié)議下IPSec不能穿越NAT。而ESP報文的完整性校驗不包括IP頭，IP地址轉換也不會破壞ESP的hash值，所以在只做IP轉換的NAT場景下，ESP協(xié)議封裝是支持NAT穿越的。但是很多時候，公網IP是共用的，所以NAT轉換不僅需要轉換IP，同時需要轉換端口，但是ESP協(xié)議對IP有效載荷進行加密了，導致無法對端口號進行修改，這也是很多IP in IP的隧道無法穿越NAT的根本原因，解決辦法是再加一個UDP報文頭——NAT-T（NAT Traversal），源目的端口號均是4500。

NAT-T的方式隧道能解決IPSec穿越NAT的問題，但是穿越NAT之后同樣存在以下兩個問題：一是穿越NAT后的身份認證及IP地址復用的問題。在目前的IP網絡中，IP即為身份標識，但是NAT之后IP會發(fā)生變化，當前國內主要采用字符串取代IP地址作為身份標識的方式，這樣就不受NAT影響了。二是ESP協(xié)議是基于IP的協(xié)議，當NAT網關背后存在多個ESP應用端，且

地址復用一個，那么無法只根據(jù)IP協(xié)議號進行反向映射，ESP協(xié)議必須要做出改變。這一點在NAT-T流程中會有具體的體現(xiàn)，下面我們詳細闡述NAT-T流程。

首先判斷雙方是否支持NAT-T。當開啟NAT穿越時，IKE協(xié)商過程中會發(fā)送標識NAT-T能力的vendor ID載荷，用于檢查通信雙方是否支持NAT-T，只有當雙方都在各自的消息中包含了該載荷，后續(xù)才會進行相關的NAT-T協(xié)商。

其次是判斷鏈路上是否存在NAT設備。在IKE協(xié)商中，會發(fā)送NAT-D（NAT Discovery）載荷，這個載荷用于探測NAT設備，雙方都會向對方發(fā)送源目的IP和端口的hash值，存放在該載荷中，如果在傳輸過程中發(fā)生改變，hash值會相應的改變，判斷hash值就可以判斷鏈路中是否存在NAT轉換。

最后是ESP處理，在前兩步的前提下，當發(fā)現(xiàn)NAT網關之后，后續(xù)的IKE報文端口號轉換成4500。

上述技術雖然能實現(xiàn)NAT穿越，但是也存在一定的局限性：使用NAT-T功能會導致在IKE協(xié)商過程中增加大約200字節(jié)的開銷，數(shù)據(jù)傳輸過程中也會增加大約20字節(jié)的開銷；同時不能采用AH協(xié)議，一定程度上也會降低安全性；NAT設備無法保證始終固定的IP和固定的端口為內部主機提供訪問映射，所以IPSec必須能夠自動檢測變化，以保證通訊始終暢通。

Part 05●??后記?●

IPSec自從1990年被開發(fā)出來以來，目前為止已經應用超過30年，技術的發(fā)展經過一代代的積累也日漸成熟，基礎的交換流程也比較完備，未來的發(fā)展方向大概率是在認證和加密算法上面。美國NIST在2020年也發(fā)布過特別出版物《IPSec VPNs指南》，文中指出IETF正著力于研究各類IKE與IPSec擴展議題，同時也介紹了在組播與組認證、ESP中的隱式IV、后量子密鑰交換等方面的努力。未來我們將及時關注最新的IPSec技術，在實際生產和工作中進行應用，為中國移動新型網絡架構添磚加瓦。