背景

IPsec在兩個(gè)通信實(shí)體之間建立安全的數(shù)據(jù)傳輸通道, 但它卻與網(wǎng)絡(luò)中廣泛存在的NAT設(shè)備(以及PAT)有天生的不兼容性(incompatible)。

我們以一個(gè)TCP報(bào)文為例來(lái)看看在不同IPsec的不同模式(Transport和Tunnel)和協(xié)議(AH和ESP)下，這種不兼容是如何發(fā)生的。

先來(lái)看Transport模式

對(duì)AH協(xié)議，由于其Authenticate范圍是整個(gè)IP報(bào)文，所以如果兩個(gè)IPsec之間存在NAT設(shè)備，修改了報(bào)文IP Header中的地址，就會(huì)導(dǎo)致接收方的Authenticate失敗。
對(duì)ESP協(xié)議，其Authenticate返回不包括IP Header,所以接收方的Authenticate會(huì)通過(guò)，但如果中間的NAT設(shè)備修改了IP Header中的地址，理論上后面的TCP checksum也會(huì)隨之修改，但這部分在ESP協(xié)議中是
加密的，NAT設(shè)備沒有辦法修改，所以接收端在TCP接收時(shí)會(huì)出現(xiàn)checksum校驗(yàn)失敗。

再來(lái)看Tunnel模式

對(duì)AH協(xié)議, Tunnel模式和Transport模式?jīng)]什么不同，Authenticate范圍包含了外層IP Header，因此同樣會(huì)造成接收方Authenticate失敗。
對(duì)ESP協(xié)議，與Transport模式不同的是，經(jīng)過(guò)NAT設(shè)備。內(nèi)層IP Header并不會(huì)改變，所以TCP checksum也不會(huì)變化，接收方不會(huì)出現(xiàn)checksum校驗(yàn)失敗。

這樣看起來(lái)，ESP-Tunnel似乎成為了在有NAT設(shè)備環(huán)境下，唯一可行的協(xié)議-模式組合。但即使是這種組合也是有缺點(diǎn)的：它只能支持一對(duì)一的NAT(NAT設(shè)備后面只有一臺(tái)內(nèi)網(wǎng)主機(jī))。在很多組網(wǎng)中，NAT設(shè)備通常作為網(wǎng)關(guān)使用，其背后可能有很多臺(tái)主機(jī)。這時(shí)地址轉(zhuǎn)換就不夠了，它還需要端口轉(zhuǎn)換，顯然，NAT設(shè)備對(duì)ESP-Tunnel的報(bào)文是無(wú)能為力的，因?yàn)門CP部分已經(jīng)被加密了，已經(jīng)沒有端口字段了。
所以，IPsec需要想辦法能繞開NAT設(shè)備的影響，也就是進(jìn)行NAT穿越(NAT-Tranversal)。

UDP-Encapsulate

IPsec采用的辦法是在ESP Header前加上一個(gè)UDP Header, 這個(gè)方法同時(shí)適用于ESP-Transport和ESP-Tunnel模式。
下圖展示了ESP-Transport下的UDP-Encapsulate過(guò)程。

UDP Header是有端口字段的，有了端口，NAT設(shè)備便可以進(jìn)行端口轉(zhuǎn)換。RFC3948中規(guī)定UDP Header中的端口要使用和IKE協(xié)商時(shí)相同的端口號(hào)，這個(gè)端口號(hào)在RFC3947中規(guī)定為4500.

在下面這樣的拓?fù)渲?，NAT設(shè)備背后有兩臺(tái)內(nèi)網(wǎng)主機(jī)，它們都與Server建立IPsec連接。

Host 1與Host 2發(fā)出的IPsec報(bào)文都附加了一個(gè)UDP Header。NAT網(wǎng)關(guān)替換該報(bào)文的Source IP和Source Port。

還有一個(gè)問題, 對(duì)于ESP-Transport模式, 內(nèi)層TCP報(bào)文的checksum校驗(yàn)的問題如何解決呢？要知道，經(jīng)過(guò)NAT設(shè)備之后，報(bào)文的IP地址發(fā)生了變化，這勢(shì)必導(dǎo)致接收端校驗(yàn)失敗。IPsec采用的方法是在IKE協(xié)商時(shí)，就將自己原始IP地址信息發(fā)給對(duì)端，這樣Server在解密出TCP報(bào)文后，可以根據(jù)這個(gè)信息修正checksum

NAT-T 協(xié)商過(guò)程

IPsec的通信實(shí)體之間需要在IKE時(shí)完成協(xié)商才能使用上面UDP-Encapsulate，完成NAT-T。

在IKE的PHASE1

• 雙方探測(cè)出雙方都支持NAT-T

• 雙方探測(cè)出了報(bào)文傳輸路徑上存在NAT設(shè)備

在IKE的PHASE2

• 雙方協(xié)商N(yùn)AT-T的封裝模式，UDP-Encapsulated-Tunnel還是UDP-Encapsulated-Transport

• (UDP-Encapsulated-Transport)模式向?qū)Ψ桨l(fā)送自己的原始IP地址, 讓對(duì)方可以據(jù)此修正后續(xù)TCP報(bào)文的checksum

為了更好的說(shuō)明我用虛擬機(jī)搭建了下面這個(gè)拓?fù)?，用?lái)展示IPsec的NAT-T協(xié)商過(guò)程

其中Alice和Carol上運(yùn)行Strongswan, 而Moon作為NAT設(shè)備。配置IPsec為Transport模式，使用IKEv1進(jìn)行協(xié)商

探測(cè)支持 NAT-T

IPsec的兩端在PHASE1的消息1和消息2中會(huì)通過(guò)交換vendor ID payload來(lái)向?qū)Ψ酵ǜ孀约褐С諲AT, 其內(nèi)容正是字符串'rfc3947'

探測(cè)是否存在 NAT

在IKE PHASE1的消息3和消息4，通信雙方會(huì)交換自己的和自己眼中對(duì)方的IP和Port的哈希值，如果中間存在NAT設(shè)備，則該值一定與該報(bào)文本身的IP和Port計(jì)算出的值不一致。

改變端口從500到4500

IKE PHASE1的前4個(gè)消息都是使用Sport=Dport=500進(jìn)行通信。但當(dāng)探測(cè)到NAT設(shè)備存在時(shí)，作為Initiator的Alice就再消息5需要將端口切換到Sport=Dport=4500, 作為Responder的Carol在收到該消息后，如果解密成功，也會(huì)使用新的4500端口

在此之后，后續(xù)的IKE PHASE2和業(yè)務(wù)流量都會(huì)使用4500端口進(jìn)行UDP-Encapsulate。為了與業(yè)務(wù)流量進(jìn)行區(qū)分，IKE階段的流量緊隨UDP Header后的是一個(gè)32bit全為0的Non-ESP Marker (業(yè)務(wù)流量的這個(gè)地方是填寫的是非零的SPI)

內(nèi)核相關(guān)實(shí)現(xiàn)

內(nèi)核使用xfrm框架完成IPsec報(bào)文收發(fā)功能。普通情況下, IP根據(jù)協(xié)議字段分流IPsec報(bào)文和TCP UDP報(bào)文。

在NAT-T場(chǎng)景中，IPsec為報(bào)文進(jìn)行了UDP-Encapsulate，那么，接收端看到的就是一個(gè)UDP報(bào)文了，會(huì)調(diào)用udp_rcv()進(jìn)行報(bào)文接收。那么此時(shí)又如何進(jìn)入xfrm框架呢？

答案是：Strongswan通過(guò)設(shè)置UDP套接字UDP_ENCAP選項(xiàng)，內(nèi)核為套接字綁定一個(gè)回調(diào)函數(shù)xfrm4_udp_encap_rcv()

int udp_lib_setsockopt(struct sock *sk, int level, int optname,

      char __user *optval, unsigned int optlen,

      int (*push_pending_frames)(struct sock *))

{

// code omitted

switch (optname) {

case UDP_ENCAP:

switch (val) {

case 0:

case UDP_ENCAP_ESPINUDP:

case UDP_ENCAP_ESPINUDP_NON_IKE:

up->encap_rcv = xfrm4_udp_encap_rcv;

// code omitted

}

}

而在udp_rcv()接收過(guò)程中，最終會(huì)調(diào)用到該回調(diào)函數(shù)

REF

RFC 3947 Negotiation of NAT-Traversal in the IKE
RFC 3948 UDP Encapsulation of IPsec ESP Packets