目录

1. IPsec与NAT矛盾

2.  身份确认

3.  NAT-T

3.1 NAT-T流程

3.2 报文格式

4.  地址复用

4.1. 隧道模式下的冲突

4.2. 传输模式下的冲突 

4.3. 同一个NAT下的冲突

Q And A

参考资料

在文章《IPsec》及《NAT》中介绍了IPsec及NAT的基本知识。我们知道IPsec的协议分为AH及ESP，封装模式分为传输模式及隧道模式，也知道由于NAT会对IP头进行修改导致AH协议下的IPsec不能穿越NAT。

那么ESP协议能不能穿越NAT？ESP协议对数据进行完整性检查，不包括外部的IP头，IP地址转换不会破坏ESP的Hash值。但ESP报文中TCP/UDP的端口已经加密无法修改，所以对于同时转换端口及IP地址的NAT来说，ESP无法穿越NAT。如果NAT只转换IP地址，那么不管是传输模式还是隧道模式，均能穿越NAT。

对于同时转换IP地址及端口的NAT而言，IPsec如何穿越？那就是NAT-T（NAT Traversal）。虽然NAT-T能解决IPsec穿越NAT的问题，但是穿越以后会有如下问题：

1.  穿越NAT后的身份确认：穿越NAT后的身份确认：在IP网络中IP地址是最好的身份标识，IPsec VPN中标准身份标识也是IP地址。NAT处理过程中会改变IP地址，因此IPsec的身份确认机制必须能够适应IP地址变化。目前解决此问题的方法主要有两种，第一种是使用数字证书替代IP地址作为身份标识，第二种是使用字符串取代IP地址作为身份标识；我国内市场范围内，第二种方法更为常见，部署也更为简单，所以本文主要对第二种方法着重进行介绍。

2.  IP地址复用：ESP的IP协议号是50，并不是基于UDP和TCP的协议（虽然其封装的是整个IP层数据，包含TCP/UDP等传输层协议），因此当NAT网关背后存在多个ESP应用端时，无法只根据协议号进行反向映射，为了使ESP能够在NAT环境中进行地址复用，ESP必须做出改变。

下文将对上述问题及NAT-T进行介绍。

图 1 展示了IPsec穿越NAT时的身份认证过程：

IPsec的身份确认最常见是通过IKE，IKE支持的身份认证机制有两种：

1. 数字证书方式，通过CA数字证书体系确认身份，是最为安全、可靠的方式

2. 身份标识+预共享密钥方式，通过发起方和响应方预先配置相同的密钥，如bigtree，完成双方对彼此身份的认证，这是最为常见的方式

 在预共享秘密钥认证机制中，身份标识则可以分为几类：

1. 指定IP地址，使用IP地址作为身份标识，是IKE的默认方式，响应方只允许指定IP地址发起协商，安全性比较高

2. 指定IP地址范围，这种方式依然使用IP地址作为身份标识，由于发起方必须要指定IP地址，否则无法发起协商，指定IP地址范围是响应方特性，如响应方可以指定2.0.0.0/8范围内的地址都可以发起协商，而不是只允许2.1.1.2发起协商，能够减少配置，但安全性略有下降

3. 什么都不指定，也是使用IP地址作为身份标识，但允许任意IP地址发起协商，只要预共享密钥一致，双方就能够通过身份确认，通常适用于发起方动态获取公网地址，如PPPoE接入互联网方式，还适用于发起方众多，而响应方不想单独为每个发起方单独指定预共享密钥，这种方式虽然不是非常安全，但是可以简化配置，安全性再次下降

4. 指定对端名字，发起方和响应方都预先配置好本端名字，使用该名字作为身份标识，与指定IP地址类似，通过指定对端名字方式，即使双方预共享密钥一致，只要对端名字不合法，立即中断协商，由于名字未与IP地址进行绑定，而且名字在网络中明文传递，估安全性不如指定IP地址方式高，但这种身份标识方式可以穿越NAT

使用数字证书进行身份认证过程如图 2所示，发起方Spartacus及响应方Crixus通过数字证书颁发机构CA进行身份认证。

使用数字证书进行身份认证需要CA服务器（一般是在公网），此种方式可以穿越NAT。         

在预共享密钥身份确认体系中，使用名字作为身份标识，也能穿越NAT，由于该方式不需要搭建CA服务器，在穿越NAT的应用场景中，该方式使用较广。

如果要使用名字作为身份标识，那么IKE协商就必须要使用一种特殊的协商方式——野蛮模式（Aggressive Mode）或者叫激进模式：

1. 发起方协商的第一条信息就包含身份信息，并且是明文显示，因此有身份泄露的隐患

2. 响应方根据发起方的身份信息进行确认，并使用预共享密钥信息计算hash

3. 发起方根据响应方的身份信息也进行hash计算，与响应方提供的hash进行比较，如果一致则身份确认通过，进行IKE SA密钥种子确认，如果不一致则双方协商结束 

4. IKE SA协商完毕之后，利用该SA协商IPsec SA，从第三条报文开始都是加密的，但双方身份信息都使用明文传送

预共享认证方式只能使用IP地址作为身份标识，预共享认证中既可以使用IP地址也可以使用名字方式作为身份标识。

IKE协商IPsec SA的过程称为快速模式（Quick Mode），和野蛮模式一样只需要3条报文即可协商完成。

为了使IPsec穿越NAT，RFC3948提出了如下的方法：当需要穿越NAT设备时，ESP报文会被封装在一个UDP头中，源和目的端口号均是4500。有了这个UDP头就可以正常进行转换。

那么问题来了，如何知道对端是否支持NAT-T及是否采用NAT-T？

使用IKEV1协议的NAT-T流程如下：

1. 开启NAT穿越时，IKEv1协商第一阶段的前两个消息会发送标识NAT-T能力的Vendor ID载荷（主模式和野蛮模式都是）。用于检查通信双方是否支持NAT-T。当双方都在各自的消息中包含了该载荷时，才会进行相关的NAT-T协商。

2. 主模式消息3和消息4（野蛮模式消息2和消息3）中发送NAT-D（NAT Discovery）载荷。NAT-D载荷用于探测两个要建立IPsec隧道的网关之间是否存在NAT网关以及NAT网关的位置。

3.  通过协商双方向对端发送源和目的的IP地址与端口的Hash值，就可以检测到地址和端口在传输过程中是否发生变化。若果协商双方计算出来的Hash值与它收到的Hash值一样，则表示它们之间没有NAT。否则，则说明传输过程中对IP或端口进行了NAT转换。

第一个NAT-D载荷为对端IP和端口的Hash值，第二个NAT-D载荷为本端IP和端口的Hash值。发现NAT网关后，后续ISAKMP消息（主模式从消息5、野蛮模式从消息3开始）的端口号转换为4500（开始为500）。ISAKMP报文标识了“Non-ESP Marker”。

4. 在第二阶段会启用NAT穿越协商。在IKE中增加了两种IPsec报文封装模式：UDP封装隧道模式报文（UDP-Encapsulated-Tunnel）和UDP封装传输模式报文（UDP-Encapsulated-Transport）。通过为ESP报文封装UDP头，当封装后的报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。 

发起方和响应方把IKE安全提议、密钥相关信息和身份信息一股脑地全放在一个ISAKMP消息中发送给对方，IKE协商效率提高了。但由于身份信息是明文传输，没有加密和完整性验证过程，IKE SA的安全性降低了。既然这样不够安全，为什么野蛮模式还会出现？

在IPsec VPN出现的早期，由于主模式+预共享密钥身份认证方式下，IPsec需要通过对端的IP地址来在本地查找预共享密钥（主模式中已经详细解释了这个问题）。这种密钥查找方式在对端没有固定IP地址的情况下（比如IPsec NAT穿越场景，网络出口动态获取IP地址场景）行不通。此时，野蛮模式可以“野蛮”地解决这个问题。野蛮模式中“身份信息”没有加密，IPsec就直接用对端发送来的身份信息来查找预共享密钥即可。

IKEv2安全性更高，有兴趣的可以了解一下。

当使用隧道模式来传输报文时，内部IP头可以包含与当前网络不相配的地址，必须进行下列操作之一：

1. 如果策略中给来自对端的封装报文定义了一个有效的源IP地址空间，则根据该策略检查内部报文的源IP地址是否有效

2. 如果一个地址已经赋给了远程的对端，则检查内部报文中的源IP地址是否是所赋值的IP地址

3. 对该报文进行网络地址转换（NAT）处理，使其能在本地网络中传输

隧道模式下的ESP封装格式如图 10所示：

隧道模式ESP封装步骤如下：

1. 进行通常的ESP封装过程

2. 在图所示的地方插入一个正确格式的UDP头

3. 把新IP头中的整个长度（Total Length），协议（Protocol），和头校验和（Header Checksum）（对于IPv4）字段被修改成符合结果的IP报文

隧道模式ESP的解封步骤如下:

1. 把UDP头从报文中删去

2. 把新IP头中的整个长度（Total Length），协议（Protocol），和头校验和（Header Checksum）（对于IPv4）字段修改成符合结果的IP报文

3. 进行通常的ESP解封装过程

4. 执行隧道模式解封的NAT过程

传输模式下的ESP封装格式如图 11 所示：

传输模式ESP的封装：

1. 进行通常的ESP封装过程

2. 在图所示的地方插入一个正确格式的UDP头

3. 把IP头中的整个长度（Total Length），协议（Protocol），和头校验和 （Header Checksum）（对于IPv4）字段修改成符合结果的IP报文

传输模式ESP的解封：

1. 把UDP头从报文中删去

2. 把新IP头中的整个长度（Total Length），协议（Protocol），和头校验和（Header Checksum）（对于IPv4）字段修改成符合结果的IP报文

3. 进行通常的ESP解封装过程

4. 执行传输模式解封的NAT过程

如图11所示，如果Ari和Bob的局域网IP地址都是10.1.2.3，分别连接NAT1及NAT2，NAT1及NAT2均连接到安全网关SGW上，因为SGW现在会把两个SA都看作是到10.1.2.3的，往哪里发送来自Suzy的服务器 的报文将是很迷惑的。实现者必须想出防止这种事情发生的方法。 推荐该SGW给Ari和Bob的笔记本都赋予本地的唯一IP地址（通过使用一个例如DHCP通过IPsec的协议），或者在发送报文去Suzy的服务器之前， 使用NAT来改变Ari和Bob笔记本的源IP地址为本地唯一地址。

如图 12所示，当有3个客户端：Ari和Bob，Cliff，它们都在同一个NAT设备后面。其中Air和Bob和Server进行安全的通信，而Cliff准备以明文方式和Server通信。

由于Ari和Bob都通过NAT和Server进行安全的通信，此时Cliff想通过明文和Server进行交互，那么此时服务器很难做。服务器把NAT设备后面的所有客户端都看成是一个相同的IP地址，因为服务器已经有一个策略（从服务器到NAT设备的外部地址）来保护其与NAT后面已有客户的通信。所以对同一个通信描述符而设置的不同策略在原则上是不可能的。

服务器有可能误把Bob的通信以明文发送了。因为这不能与Cliff以明文发送通信时相区分。所以当允许从同一个NAT设备后面的不同客户端以明文通信的时候，不可能保证从一个NAT设备后面的某些客户端的安全。但是如果服务器的安全策略允许这样做，无论如何，它都做了尽量有效的安全工作：如果来自NAT设备后面的客户端发起安全，它的连接将会是安全的。如果它发送的是明文，那么服务器将继续接收明文数据。

如果两台电脑连接在同一个NAT下，并且同时要访问Server，由于两者进行IKE协商时使用的都是4500端口，那么NAT在收到回包时将包转发给谁呢？

多重NAT-T客户端支持技术可以解决上述问题。该技术在NAT-T协商和处理过程中引入了端口等消息封装机制，以使IPsec服务器能够识别使用同一个NAT地址的多个IPsec终端发出的不同隧道协商请求，并建立彼此独立的安全关联。 

Q1：ESP协议下，为什么要添加新的IP头

A1：新的IP头中的IP可能与原来的目的IP、源IP地址不同，是为了将报文可以发送给安全网关等设备。 

技术点详解---IPSec穿越NAT

强叔侃墙 VPN篇 IPSec遭遇NAT处变不惊，见招拆招化险为夷

强叔侃墙 VPN篇 IPSec携手IKE，珠联璧合显神威

UDP封装IPsec ESP报文

RFC3948 

构建穿越NAT设备的IPSec隧道