5. 详解: IPsec 穿越 NAT 之道
1. IPsec与NAT矛盾
在文章《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的问题，但是穿越以后会有如下问题：
-
- 穿越NAT后的身份确认:穿越NAT后的身份确认;在IP网络中IP地址是最好的身份标识，IPsec VPN中标准身份标识也是IP地址。NAT处理过程中会改变IP地址，因此IPsec的身份确认机制必须能够适应IP地址变化。目前解决此问题的方法主要有两种，第一种是使用数字证书替代IP地址作为身份标识，第二种是使用字符串取代IP地址作为身份标识；我国内市场范围内，第二种方法更为常见，部署也更为简单，所以本文主要对第二种方法着重进行介绍。
-
- IP地址复用：ESP的IP协议号是50，并不是基于UDP和TCP的协议（虽然其封装的是整个IP层数据，包含TCP/UDP等传输层协议），因此当NAT网关背后存在多个ESP应用端时，无法只根据协议号进行反向映射，为了使ESP能够在NAT环境中进行地址复用，ESP必须做出改变。
下文将对上述问题及NAT-T进行介绍。
2. 身份确认
图 1 展示了IPsec穿越NAT时的身份认证过程：
图 1 IPsec穿越NAT时的身份认证
- 数字证书方式，通过CA数字证书体系确认身份，是最为安全、可靠的方式
- 身份标识+预共享密钥方式，通过发起方和响应方预先配置相同的密钥，如bigtree，完成双方对彼此身份的认证，这是最为常见的方式
在预共享秘密钥认证机制中，身份标识则可以分为几类：
- 指定IP地址，使用IP地址作为身份标识，是IKE的默认方式，响应方只允许指定IP地址发起协商，安全性比较高
- 指定IP地址范围，这种方式依然使用IP地址作为身份标识，由于发起方必须要指定IP地址，否则无法发起协商，指定IP地址范围是响应方特性，如响应方可以指定2.0.0.0/8范围内的地址都可以发起协商，而不是只允许2.1.1.2发起协商，能够减少配置，但安全性略有下降
- 什么都不指定，也是使用IP地址作为身份标识，但允许任意IP地址发起协商，只要预共享密钥一致，双方就能够通过身份确认，通常适用于发起方动态获取公网地址，如PPPoE接入互联网方式，还适用于发起方众多，而响应方不想单独为每个发起方单独指定预共享密钥，这种方式虽然不是非常安全，但是可以简化配置，安全性再次下降
- 指定对端名字，发起方和响应方都预先配置好本端名字，使用该名字作为身份标识，与指定IP地址类似，通过指定对端名字方式，即使双方预共享密钥一致，只要对端名字不合法，立即中断协商，由于名字未与IP地址进行绑定，而且名字在网络中明文传递，估安全性不如指定IP地址方式高，但这种身份标识方式可以穿越NAT
使用数字证书进行身份认证过程如图 2所示，发起方Spartacus及响应方Crixus通过数字证书颁发机构CA进行身份认证。
图 2 使用数字证书进行身份认证
使用数字证书进行身份认证需要CA服务器（一般是在公网），此种方式可以穿越NAT。
在预共享密钥身份确认体系中，使用名字作为身份标识，也能穿越NAT，由于该方式不需要搭建CA服务器，在穿越NAT的应用场景中，该方式使用较广。
图 3 使用名字进行身份认证
如果要使用名字作为身份标识，那么IKE协商就必须要使用一种特殊的协商方式——野蛮模式（Aggressive Mode）或者叫激进模式：
- 发起方协商的第一条信息就包含身份信息，并且是明文显示，因此有身份泄露的隐患
- 响应方根据发起方的身份信息进行确认，并使用预共享密钥信息计算hash
- 发起方根据响应方的身份信息也进行hash计算，与响应方提供的hash进行比较，如果一致则身份确认通过，进行IKE SA密钥种子确认，如果不一致则双方协商结束
- IKE SA协商完毕之后，利用该SA协商IPsec SA，从第三条报文开始都是加密的，但双方身份信息都使用明文传送
图 4 野蛮模式结合名字身份协商SA
预共享认证方式只能使用IP地址作为身份标识，预共享认证中既可以使用IP地址也可以使用名字方式作为身份标识。
IKE协商IPsec SA的过程称为快速模式（Quick Mode），和野蛮模式一样只需要3条报文即可协商完成。
图 5 IPsec 快速模式
3. NAT-T
为了使IPsec穿越NAT，RFC3948提出了如下的方法：当需要穿越NAT设备时，ESP报文会被封装在一个UDP头中，源和目的端口号均是4500。有了这个UDP头就可以正常进行转换。
那么问题来了，如何知道对端是否支持NAT-T及是否采用NAT-T？
3.1 NAT-T流程
使用IKEV1协议的NAT-T流程如下：
-
开启NAT穿越时，IKEv1协商第一阶段的前两个消息会发送标识NAT-T能力的Vendor ID载荷（主模式和野蛮模式都是）。用于检查通信双方是否支持NAT-T。当双方都在各自的消息中包含了该载荷时，才会进行相关的NAT-T协商。
图 6 探测是否支持NAT-T -
主模式消息3和消息4（野蛮模式消息2和消息3）中发送NAT-D（NAT Discovery）载荷。NAT-D载荷用于探测两个要建立IPsec隧道的网关之间是否存在NAT网关以及NAT网关的位置。
图 7 探测NAT网关信息 -
通过协商双方向对端发送源和目的的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”。
图 8 IPsec- NAT-T 4500端口
- 在第二阶段会启用NAT穿越协商。在IKE中增加了两种IPsec报文封装模式：UDP封装隧道模式报文（UDP-Encapsulated-Tunnel）和UDP封装传输模式报文（UDP-Encapsulated-Transport）。通过为ESP报文封装UDP头，当封装后的报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。
图 9 NAT-T报文交互
发起方和响应方把IKE安全提议、密钥相关信息和身份信息一股脑地全放在一个ISAKMP消息中发送给对方，IKE协商效率提高了。但由于身份信息是明文传输，没有加密和完整性验证过程，IKE SA的安全性降低了。既然这样不够安全，为什么野蛮模式还会出现？
在IPsec VPN出现的早期，由于主模式+预共享密钥身份认证方式下，IPsec需要通过对端的IP地址来在本地查找预共享密钥（主模式中已经详细解释了这个问题）。这种密钥查找方式在对端没有固定IP地址的情况下（比如IPsec NAT穿越场景，网络出口动态获取IP地址场景）行不通。此时，野蛮模式可以“野蛮”地解决这个问题。野蛮模式中“身份信息”没有加密，IPsec就直接用对端发送来的身份信息来查找预共享密钥即可。
IKEv2安全性更高，有兴趣的可以了解一下。
3.2 报文格式
当使用隧道模式来传输报文时，内部IP头可以包含与当前网络不相配的地址，必须进行下列操作之一：
- 如果策略中给来自对端的封装报文定义了一个有效的源IP地址空间，则根据该策略检查内部报文的源IP地址是否有效
- 如果一个地址已经赋给了远程的对端，则检查内部报文中的源IP地址是否是所赋值的IP地址
- 对该报文进行网络地址转换（NAT）处理，使其能在本地网络中传输
隧道模式下的ESP封装格式如图 10所示：
图 10 隧道模式ESP封装
隧道模式ESP封装步骤如下：
- 进行通常的ESP封装过程
- 在图所示的地方插入一个正确格式的UDP头
- 把新IP头中的整个长度（Total Length），协议（Protocol），和头校验和（Header Checksum）（对于IPv4）字段被修改成符合结果的IP报文
隧道模式ESP的解封步骤如下:
- 把UDP头从报文中删去
- 把新IP头中的整个长度（Total Length），协议（Protocol），和头校验和（Header Checksum）（对于IPv4）字段修改成符合结果的IP报文
- 进行通常的ESP解封装过程
- 执行隧道模式解封的NAT过程
传输模式下的ESP封装格式如图 11 所示：
图 11 传输模式下ESP封装格式
传输模式ESP的封装：
- 进行通常的ESP封装过程
- 在图所示的地方插入一个正确格式的UDP头
- 把IP头中的整个长度（Total Length），协议（Protocol），和头校验和 （Header Checksum）（对于IPv4）字段修改成符合结果的IP报文
传输模式ESP的解封：
- 把UDP头从报文中删去
- 把新IP头中的整个长度（Total Length），协议（Protocol），和头校验和（Header Checksum）（对于IPv4）字段修改成符合结果的IP报文
- 进行通常的ESP解封装过程
- 执行传输模式解封的NAT过程
4. 地址复用
4.1. 隧道模式下的冲突
如图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地址为本地唯一地址。
图 11 隧道模式下的冲突
4.2. 传输模式下的冲突
如图 12所示，当有3个客户端：Ari和Bob，Cliff，它们都在同一个NAT设备后面。其中Air和Bob和Server进行安全的通信，而Cliff准备以明文方式和Server通信。
图12 传输模式下的冲突
由于Ari和Bob都通过NAT和Server进行安全的通信，此时Cliff想通过明文和Server进行交互，那么此时服务器很难做。服务器把NAT设备后面的所有客户端都看成是一个相同的IP地址，因为服务器已经有一个策略（从服务器到NAT设备的外部地址）来保护其与NAT后面已有客户的通信。所以对同一个通信描述符而设置的不同策略在原则上是不可能的。
服务器有可能误把Bob的通信以明文发送了。因为这不能与Cliff以明文发送通信时相区分。所以当允许从同一个NAT设备后面的不同客户端以明文通信的时候，不可能保证从一个NAT设备后面的某些客户端的安全。但是如果服务器的安全策略允许这样做，无论如何，它都做了尽量有效的安全工作：如果来自NAT设备后面的客户端发起安全，它的连接将会是安全的。如果它发送的是明文，那么服务器将继续接收明文数据。
4.3. 同一个NAT下的冲突
如果两台电脑连接在同一个NAT下，并且同时要访问Server，由于两者进行IKE协商时使用的都是4500端口，那么NAT在收到回包时将包转发给谁呢？
多重NAT-T客户端支持技术可以解决上述问题。该技术在NAT-T协商和处理过程中引入了端口等消息封装机制，以使IPsec服务器能够识别使用同一个NAT地址的多个IPsec终端发出的不同隧道协商请求，并建立彼此独立的安全关联。
Q And A
Q1：ESP协议下，为什么要添加新的IP头
A1：新的IP头中的IP可能与原来的目的IP、源IP地址不同，是为了将报文可以发送给安全网关等设备。
参考资料
技术点详解—IPSec穿越NAT
强叔侃墙 VPN篇 IPSec遭遇NAT处变不惊，见招拆招化险为夷
强叔侃墙 VPN篇 IPSec携手IKE，珠联璧合显神威
UDP封装IPsec ESP报文
RFC3948
构建穿越NAT设备的IPSec隧道