NAT穿越(NAT-T)原理

IPSec NAT 穿越简介

IPSec NAT穿越的场景：

本质上解决ESP协议无法提供转换端口，插入UDP 4500端口

有以下两种场景，需要进行进行NAT穿越。

• 场景一、FW既做IPSEC网关，又做NAT转换

  此种场景下，是当运营商给客户的动态分配的私网地址情况下，FW需要穿越运营商的nat。

  IPSEC网关与NAT在同一台设备 ，如果运营商给分配的是公网地址，需要做NAT旁路(NAT豁免）

• 场景二、FW处于内部只做IPSEC网关，前面有专门的设备做NAT(可以FW也可以ROUTER）

IPSec的封装协议分析：

图：传输模式下AH和ESP的封装

如上图，在传输模式下，AH认证整个IP报文，当经过NAT转化后，肯定会认证不成功。在ESP封装下，虽然认证访问不包括IP头，但是因为通过nat后，nat修改了外层IP地址，由于TCP/UDP校验和的计算包含IP源目地址，所以TCP/UDP的校验和需要更新，但是现在TCP/UDP已经被ESP加密，中间路由器无法更新TCP/UDP的校验和，所以TCP的校验和检查最终会失败。

图：隧道模式下AH和ESP的封装

如上图，在隧道模式下，AH认证整个IP头部，包括新生成的IP头，这种情况当经过nat后， IP地址发送变化，也肯定不能认证成功。在ESP的封装下，ESP的认证范围是从ESP头部到ESP尾部。当通过nat时，改变的仅仅是外层IP头部，而内层TCP校验和因为内层IP头不变，所以校验会成功。但是也仅仅是可以通过nat的一对一的转化，即不能转化端口号。因为端口是加密的。

总结：

• AH的传输模式和隧道模式都不支持NAT穿越
• ESP传输模式也是不支持的
• ESP隧道模式默认只支持一对一NAT转换，不支持PAT

解决方案：

NAT-T技术，即在IP和ESP报文之间插入一个8个字节UDP头部(端口号默认为4500）

图：NAT-T技术原理

关键NAT-T的3个问题：

1. IPSEC网关如何知道自己是否支持NAT-T？

   决定双方是否支持NAT-T和判断peers之间是否有NAT存在的任务在IKEv1的第一阶段完成，NAT-T能力探测使用IKEv1第一阶段1-2个包交换来实现，双方互相交换NAT-T的Vendor ID来表示本段是否支持NAT-T。

2. IPSEC网关如何判定经过NAT的设备？

   为了决定Peers之间是否有NAT存在，Peer会发送一个hash负载（源目IP和端口计算），如果双方计算的hash和接受的hash值匹配，那么Peers之间就没有NAT存在（就采用ESP封装），如果hash值不同，那么Peers就需要使用NAT-T技术封装穿越NAT。

   hash负载也叫作NAT-D负载，在主模式中的3-4个包发送，在野蛮模式的2-3个包中发送。

   IKEV1通过3-4个包的NAT-D参数来判定
   通过源IP源端口, 目的IP 目的端口算HASH值

   如果HASH值相同，说明没有经过NAT，如果HASH值不等，说明经过了NAT

3. 什么时候添加UDP的端口？

   如果确定了经过nat，就在IKEV1的通过5 6的时候，增加 UDP 4500端口

IKEv1的NAT穿越协商过程：

IKEv1的NAT穿越场景中，需要在IKEv1阶段1协商中对NAT执行两种探测：

• 探测是否支持NAT穿越（NAT-T能力）。

  IKEv1使用VID载荷来确定是否支持NAT穿越。

• 探测在网络中是否存在NAT网关。

  IKEv1使用NAT-D载荷探测两个IKE对等体之间是否存在NAT网关以及存在的位置（即谁在NAT网关的后面）。

由于NAT网关会改变IKE UDP的源端口，所以响应方必须能处理源端口不是500的IKE报文。

IKEv1主模式NAT-T协商过程：

图：IKEv1主模式下第一个包中携带支持的nat-t参数

消息①：发起方在IKE消息中插入VID载荷来告知对方自己支持NAT穿越。

---

图：IKEv1主模式下第二个包中携带双方都支持nat-t参数

消息②：响应方在IKE消息中插入VID载荷表明自己支持NAT-T能力.

若双方发的IKEv1消息中都包含该载荷，说明双方都支持NAT-T，协商继续，否则终止。从而可以协商出是否支持NAT-T功能。

---

图：IKEv1主模式第3个包，携带NAT-D参数

消息3：相应方插入了两个NAT-D载荷。第一个NAT-D载荷包含IKE对等体的IP地址和端口的Hash值，第二个NAT-D载荷包含本端的IP地址和端口的Hash值，接收方也计算这两个Hash值，两方计算的哪个Hash值不相等，表明哪个设备在NAT网关后面。

---

完成NAT-T检测和NAT网关探测后，如果发现NAT网关，则后续UDP报文端口号修改为4500。

当前UDP封装的是ISAKMP消息，此处增加了一个non-ESP marker（为4个值为0的字节），以示跟封装ESP报文有区别。

IKEv1阶段2的SA协商时，需确认是否使用NAT穿越以及NAT穿越的封装模式：UDP-Encapsulated-tunnel和UDP-Encapsulated-transport。确认后，后续传输的ESP报文将都采用UDP封装（AH协议不支持NAT穿越，故只能封装ESP报文）。UDP封装ESP报文时，没有non-ESP marker字段，该位置为SPI，为非0字节。

IKEv2判断是否支持NAT-T协商过程：

KEv2的NAT穿越场景中，IKE协商的发起方和响应方在IKE_SA_INIT交换中增加两个N载荷（在Ni和Nr载荷之后），一个消息类型为NAT_DETECTION_SOURCE_IP，标识发起方的IP地址；另一个消息类型为NAT_DETECTION_DESTINATION_IP，标识响应方的IP地址。

IKEv2的NAT穿越协商过程如下：

图：IKEv2下NAT-T协商过程

---

IKEv2报文协商NAT-T过程

图：IKEv2第1个包，携带两个Notify负载

消息①、②：在IKE消息中插入两个N载荷，第一个N载荷包含本端的IP地址和端口的Hash值，第二个N载荷包含IKE对等体的IP地址和端口的Hash值，响应方也计算这两个Hash值，两方计算的哪个Hash值不相等，表明哪个设备在NAT网关后面。

---

图：IKEv2第3个包，采用UDP4500封装

消息③、④：完成IKE_SA_INIT后，如果发现NAT设备，则后续UDP报文端口号修改为4500。

两端必须都开启NAT穿越功能，才能保证IKE协商成功。

IPSec NAT-T实验配置

图：NAT-T实验拓扑图

配置思路：

阶段一：
ike proposal 10
 authentication-algorithm sha2-256
 integrity-algorithm aes-xcbc-96 hmac-sha2-256
#
ike peer  10             
 pre-shared-key Huawei@123
 ike-proposal 10

阶段二： 
acl number 3000
 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255

ipsec proposal  10
 encapsulation-mode auto
 esp authentication-algorithm sha2-256

ipsec policy-template 10 ipsec_temp
 security acl 3000
 ike-peer 10
 proposal  10

ipsec policy ipsec_policy  100   isakmp template  ipsec_temp
 

interface GigabitEthernet0/0/2
 ipsec policy ipsec_policy 

对端配置：
阶段一: 

ike proposal 10
 authentication-algorithm sha2-256
 integrity-algorithm aes-xcbc-96 hmac-sha2-256
#
ike peer  10                
 pre-shared-key Huawei@123
 ike-proposal 10
 remote-address 202.100.1.10

阶段二：
acl number 3000
 rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255

#
ipsec proposal 10 
 encapsulation-mode auto
 esp authentication-algorithm sha2-256
#
ipsec policy ipsec_policy  100 isakmp
 security acl 3000
 ike-peer 10
 proposal 10

interface GigabitEthernet0/0/2
 ipsec policy ipsec_policy  

注意： IKEV2默认开启NAT-T功能
默认华为防火墙NAT-T 无论在IKEV1还是IKEV2都是默认开启的。

开启命令：
nat traversal
关闭命令NAT-T
ike-peer fw2
undo nat traversal

---

图：FW2的安全策略配置

测试与检查：

图：IPSec协商状态

---

图：FW1的IPSec SA状态，因为FW1不知道对端地址，所以需要采用模板方式

图：FW2 的IPSec SA状态，作为IPSec的发起方

---

//通过查看会话表，从而证明走的是udp4500端口
<FW2>display firewall session table  
 Current Total Sessions : 2
  udp  VPN:public --> public 10.1.21.10:4500-->202.100.1.10:4500
   //用的是udp的4500端口

---

参考文档：华为HedEx文档

---

来源：https://blog.csdn.net/qq_38265137/article/details/89423809