IPSec

惋安

已于 2022-08-10 12:02:39 修改

阅读量3.4k

点赞数 5

分类专栏： HCIE 文章标签：网络

于 2022-08-10 11:32:33 首次发布

本文链接：https://blog.csdn.net/Loners_fan/article/details/126263031

版权

HCIE 专栏收录该内容

5 篇文章 2 订阅

订阅专栏

安全协议—AH/ESP

SA—安全联盟

sa是通信的ipsec对等体之间对某些要素的约定；例如l对等体间使用何种安全协议、需要保护的数据流特征、对等体间传输的数据的封装模式、协议采用的加密算法、验证算法、密钥以及SA的生存周期等。IPSec安全联盟简称IPSec SA；
sa有一个三元组来唯一标识：安全参数索引SPI/目的IP地址/使用的安全协议号（AH<IP协议号51>或ESP<IP协议号50>）；
SA是单向的，In和Out方向各需要一个SA；

封装模式—传输模式（不做隧道）：

请添加图片描述

AH在三层和四层之间加入了AH头部，验证的数据在AH Header中；AH的认证范围为三层及三层以上（不作TTL值的校验）；
ESP头部提供加密的功能/ESP尾部提供认证功能/ESP尾部前是填充位（ESP Tail）。头部和尾部之间是加密的数据；ESP对IP头之后的数据做加密以及认证；
AH-ESP先用ESP对整个三层以上的数据进行加密和验证处理，然后整体做一次AH的认证；弥补了ESP不能认证IP头的缺陷；

封装模式—隧道模式

在这里插入图片描述

AH Header在旧IP Header之前，新增了新的IP Header用于nat穿越；认证范围为三层及三层以上；
ESP对旧的IP Header及ESP填充位以及之间的数据进行加密；认证范围包含ESP Header；
AH- ESP在ESP加密和验证处理之后，对整体进行认证处理；

IKE SA

在确认身份合法的情况下传递密钥，身份校验也得处于安全的环境下；

安全传输的前提是有密钥（重点—传递密钥的前提是身份是可信的）/算法的各个参数的协商/身份认证，身份认证也需要有安全的环境—>安全环境的算法参数协商—>IKE会先形成一个安全传输的环境，用来做身份认证，进而传输密钥；（这里有两个安全传输通道—一个是传输真正数据的通道，一个是IKE形成用来做身份认证的通道）
在这里插入图片描述

IKE为了构成安全的环境，它会形成一个IKE SA的安全联盟（相应的整个过程中也有两个安全联盟—一个是传输真正数据时候形成的一个安全联盟(IPsec SA)，一个是IKE形成安全环境是形成的安全联盟(IKE SA)）

IKE SA是为IPsec SA服务的，为IPsec提供了自动协商密钥，建立IPsec SA的服务；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KZ9eEMla-1660101838488)(assets/image-20220803194849669.png)]

IKE通过UDP500传递（源目都是500）
因特网密钥交换KE (Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP的应用层协议，可为数据加密提供所需的密钥，能够简化IPSec的使用和管理，大大简化了IPSec的配置和维护工作。
对等体之间建立一个北ESA完成身份验证和密钥信息交换后，在KE SA的保护下，根据配置的AHVESP安全协议等参数协商出一对PSeC SA。此后，对等体间的数据将在IPsec隧道中加密传输。

IPsec加解密及验证过程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qRTrWrYu-1660101838489)(assets/image-20220804112928786.png)]

IP报文经过对称密钥计算，得到加密后的IP报文，再经过验证算法验证后，用密钥计算在报文末段加上ICV，该报文在经过公网传递到对端以后，会用对称密钥解出一个ICV，与之前的ICV进行比较，如果两端的计算得出的ICV相同，则将加密报文继续解密接收，反之，则丢弃；

封装模式对比

隧道模式隐藏原IP头，安全性更好
隧道模式有一个额外的IP头，比传输模式更占用带宽

IKE与IPsec的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jJc7Z1f2-1660101838490)(assets/image-20220804143303673.png)]

对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输；

IKE的安全机制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rK0ACefW-1660101838491)(assets/image-20220804145137523.png)]

IKE具有一套自保护机制，可以在不安全的网络上安全地认证身份、分发密钥、建立IPSec SA：
- 身份认证：身份认证确认通信双方的身份（对等体的IP地址或名称）
  - 预共享密钥PSK（pre-shared）认证
    - 通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
  - 数字证书RSA（rsa-signature）认证
    - 通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败
  - 数字信封认证
    - 发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败
- 身份保护：通信双方的身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
- DH（Diffie-Hellman）密钥交换算法：IKE采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。同时，通信双方通过交换密钥交换材料来计算共享的密钥，即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥。
- 完善的前向安全性PFS（Perfect Forward Secrecy）<完美向前法>：PFS是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。PFS是由DH算法保障的。

NAT- T（NAT穿越）

AH
- AH传输模式下，nat穿越会修改IP Header中的源信息，而这一部分则是AH校验的部分，所以会校验失败；
- AH隧道模式下同理，New IP Header也是AH校验的内容；
ESP
- ESP传输模式下，理论上来说，修改的IP Headr不在校验范围内，应该是可以通过校验的，但是，因为TCP中存在校验字段，会进行一个伪首部校验，会对三层的部分字段，如源目IP以及协议等字段做校验，故报文虽然通过了ESP的校验，但是，在到达主机以后，TCP校验失败，会被主机丢弃；（这儿存在一个疑问：既然这样，那普通的NAT为什么可以成功呢？其实，普通NAT对TCP的校验字段作了修改，而ESP对TCP以及data做了加密处理，无法修改；）
- ESP隧道模式下同理，但是TCP校验的是旧的IP Header，是可以通过校验的；
ESP会加密原始数据包的传输层端口信息，所以不支持PAT（端口转换），所以，只支持一对一的NAT；
- 如图所示，R6和R7是内网，各有一个IPsec VPN，R3上实现NAT穿越，因为ESP加密了传输层的端口信息，R6和R7在返回时，无法依据不同的端口号找到对应的路由器；
- ESP第一阶段的时候，是基于UDP500来传输的，在R3上，R6/R7的源IP同时转换为相同的IP地址，端口号也相同；R3发现同时出现两个四层端口号相同时，会将一个转换为1024以后的一个随机端口号；但是IPsec规定必须为UDP500，所以第一阶段也会出问题；
NAT- T
- NAT-T技术在ESP封装和外层IP报头之间插入8个字节的UDP报文，端口号为4500，并且规定源端口号可变；
- NAT设备对于私网用户来说是不可见的，这里就有个问题，网络设备怎么知道是否有 NAT的存在，什么时候该添加UDP报头，什么时候不该添加？
  — IPSec一般要先经过IKE协商，交互密钥之后才发送数据。NAT-T技术在IKE协商阶段通过某种机制来发现是否有NAT的存在。有NAT存在的时候添加UDP报头，没有NAT的时候就不添加。