IPsec與NAT Traversal(NAT-T)

背景

IPsec在兩個通訊實體之間創建安全的數據傳輸通道, 但它卻與網絡中普遍存在的NAT設備(以及PAT)有天生的不兼容性(incompatible)。

咱們以一個TCP報文爲例來看看在不一樣IPsec的不一樣模式(Transport和Tunnel)和協議(AH和ESP)下，這種不兼容是如何發生的。

先來看Transport模式

對AH協議，因爲其Authenticate範圍是整個IP報文，因此若是兩個IPsec之間存在NAT設備，修改了報文IP Header中的地址，就會致使接收方的Authenticate失敗。
對ESP協議，其Authenticate返回不包括IP Header,因此接收方的Authenticate會經過，但若是中間的NAT設備修改了IP Header中的地址，理論上後面的TCP checksum也會隨之修改，但這部分在ESP協議中是
加密的，NAT設備沒有辦法修改，因此接收端在TCP接收時會出現checksum校驗失敗。

再來看Tunnel模式

對AH協議, Tunnel模式和Transport模式沒什麼不一樣，Authenticate範圍包含了外層IP Header，所以一樣會形成接收方Authenticate失敗。
對ESP協議，與Transport模式不一樣的是，通過NAT設備。內層IP Header並不會改變，因此TCP checksum也不會變化，接收方不會出現checksum校驗失敗。

這樣看起來，ESP-Tunnel彷佛成爲了在有NAT設備環境下，惟一可行的協議-模式組合。但即便是這種組合也是有缺點的：它只能支持一對一的NAT(NAT設備後面只有一臺內網主機)。在不少組網中，NAT設備一般做爲網關使用，其背後可能有不少臺主機。這時地址轉換就不夠了，它還須要端口轉換，顯然，NAT設備對ESP-Tunnel的報文是無能爲力的，由於TCP部分已經被加密了，已經沒有端口字段了。
因此，IPsec須要想辦法能繞開NAT設備的影響，也就是進行NAT穿越(NAT-Tranversal)。

UDP-Encapsulate

IPsec採用的辦法是在ESP Header前加上一個UDP Header, 這個方法同時適用於ESP-Transport和ESP-Tunnel模式。
下圖展現了ESP-Transport下的UDP-Encapsulate過程。

UDP Header是有端口字段的，有了端口，NAT設備即可以進行端口轉換。RFC3948中規定UDP Header中的端口要使用和IKE協商時相同的端口號，這個端口號在RFC3947中規定爲4500.

在下面這樣的拓撲中，NAT設備背後有兩臺內網主機，它們都與Server創建IPsec鏈接。

Host 1與Host 2發出的IPsec報文都附加了一個UDP Header。NAT網關替換該報文的Source IP和Source Port。

還有一個問題, 對於ESP-Transport模式, 內層TCP報文的checksum校驗的問題如何解決呢？要知道，通過NAT設備以後，報文的IP地址發生了變化，這勢必致使接收端校驗失敗。IPsec採用的方法是在IKE協商時，就將本身原始IP地址信息發給對端，這樣Server在解密出TCP報文後，能夠根據這個信息修正checksum

NAT-T 協商過程

IPsec的通訊實體之間須要在IKE時完成協商才能使用上面UDP-Encapsulate，完成NAT-T。

在IKE的PHASE1

• 雙方探測出雙方都支持NAT-T
• 雙方探測出了報文傳輸路徑上存在NAT設備

在IKE的PHASE2

• 雙方協商NAT-T的封裝模式，UDP-Encapsulated-Tunnel仍是UDP-Encapsulated-Transport
• (UDP-Encapsulated-Transport)模式向對方發送本身的原始IP地址, 讓對方能夠據此修正後續TCP報文的checksum

爲了更好的說明我用虛擬機搭建了下面這個拓撲，用來展現IPsec的NAT-T協商過程

其中Alice和Carol上運行Strongswan, 而Moon做爲NAT設備。配置IPsec爲Transport模式，使用IKEv1進行協商

探測支持 NAT-T

IPsec的兩端在PHASE1的消息1和消息2中會經過交換vendor ID payload來向對方通告本身支持NAT, 其內容正是字符串"rfc3947"

探測是否存在 NAT

在IKE PHASE1的消息3和消息4，通訊雙方會交換本身的和本身眼中對方的IP和Port的哈希值，若是中間存在NAT設備，則該值必定與該報文自己的IP和Port計算出的值不一致。

改變端口從500到4500

IKE PHASE1的前4個消息都是使用Sport=Dport=500進行通訊。但當探測到NAT設備存在時，做爲Initiator的Alice就再消息5須要將端口切換到Sport=Dport=4500, 做爲Responder的Carol在收到該消息後，若是解密成功，也會使用新的4500端口

在此以後，後續的IKE PHASE2和業務流量都會使用4500端口進行UDP-Encapsulate。爲了與業務流量進行區分，IKE階段的流量緊隨UDP Header後的是一個32bit全爲0的Non-ESP Marker (業務流量的這個地方是填寫的是非零的SPI)

內核相關實現

內核使用xfrm框架完成IPsec報文收發功能。普通狀況下, IP根據協議字段分流IPsec報文和TCP UDP報文。

在NAT-T場景中，IPsec爲報文進行了UDP-Encapsulate，那麼，接收端看到的就是一個UDP報文了，會調用udp_rcv()進行報文接收。那麼此時又如何進入xfrm框架呢？

答案是：Strongswan經過設置UDP套接字UDP_ENCAP選項，內核爲套接字綁定一個回調函數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()接收過程當中，最終會調用到該回調函數

REF

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