预计阅读18分钟
IPSec基础简介
IPSec(Internet Protocol Security) 是一种安全网络协议套件,用于在IP网络中实现安全通信。它可以为IPv4和IPv6提供加密和认证,确保数据在传输过程中的机密性、完整性和真实性。IPSec旨在保护数据不受未经授权的访问、窃听、篡改或其他形式的攻击。
IPSec最初是为了解决互联网上的安全通信问题而开发的,它的发展可以追溯到1990年代,随着互联网的普及和使用范围不断增加,随之而来的安全问题也日益突出。为了应对这些挑战,IPSec标准被制定出来,成为确保互联网通信安全的关键技术之一。
IPSec目前被广泛应用于企业、政府机构和个人的虚拟私人网络(VPN)连接,可以很好的保护网络层数据传输。通过IPSec建立加密隧道,组织或个人可以确保其数据在互联网传输过程中的安全性,免受网络攻击和未经授权的访问。
IPsec结构
IPsec 由以下协议组成:
- AH(Authentication Header) 为 IP 数据报提供无连接的数据完整性和数据来源认证,并提供对 IP 头修改攻击和重放攻击的保护。
- ESP(Encapsulating Security Payload) 提供保密性、无连接的数据完整性、数据来源认证、反重放服务(一种形式的部分序列完整性)以及有限的流量流保密性。
- ISAKMP(Internet Security Association and Key Management Protocol) 提供了一个用于认证和密钥交换的框架,实际的认证密钥材料由手动配置的预共享密钥(Pre-shared Key)、互联网密钥交换(IKE 和 IKEv2)、Kerberized 互联网密钥协商(KINK)或 IPSECKEY DNS 记录提供。其目的是生成安全关联(SA),包括执行 AH 和/或 ESP 操作所需的算法和参数集合。
IPsec报文
IPSec报文分为AH报文和ESP报文两种。
AH报文
- Next Header(8位) 指示被保护的上层协议的类型,取自 IP协议号列表 。
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers - Payload Length(8位) 以 4 字节的倍数计算AH的长度再减2。IPv6下,AH的头部为 8 字节的倍数。
- Reserved(16位) 保留供将来使用(目前为全零)。
- SPI(32位) 一个协商的任意值,用于接收方识别关联SA。
- Sequence Number(32位) 一个递增的序列号(每发送一个包增加 1)以防止重放攻击。当启用重放检测时,序列号永远不会复用,在序列号用到最大值之前,必须重新协商一个新的SA。
- ICV(32的倍数) 变长检查值。用于填充 IPv6 的 8 字节或 IPv4 的 4 字节。
ESP报文
- SPI(32位) 一个协商的任意值,用于接收方识别SA。
- Sequence Number(32位) 一个递增的序列号(每发送一个包增加 1)以防止重放攻击。每个SA都有一个单独的计数器。
- Payload data(可变长度) 原始 IP 数据包的受保护内容,被保护的内容类型由Next Header字段表示。
- Padding(0-255字节) 用于加密的填充,以将有效载荷数据扩展到符合加密的密码块大小,并对齐下一个字段。
- Pad Length(8位) 填充的大小。
- Next Header(8位) 下一个头部的类型。其值从 IP 协议号列表中取得。
- ICV(32位的倍数) 变长检查值。对齐到 IPv6 的 8 字节或 IPv4 的 4 字节,它可能包含填充。
IPsec工作模式
IPSec支持两种工作模式:传输模式(Transport Mode)和隧道模式(Tunnel Mode)。
- 传输模式 通常只有 IP 数据包的数据被加密或认证。由于 IP 头部没有被修改或加密,路由路径保持不变;当使用AH时,IP 地址不能经过网络地址转换(NAT),否则会使哈希值无效。传输层和应用层总是通过哈希进行保护,因此它们不能被修改,包括端口号等。
- 隧道模式 在隧道模式中,整个 IP 数据包都被加密和认证。然后,它被封装到一个外层新 IP 头部的新 IP 数据包中。隧道模式用于创建VPN站点之间的通信,包括主机到网络通信和主机到主机的通信。
IPSec加密算法
IPSec常用的加密算法包括:
对称加密算法:
- AES:一种广泛使用的对称加密算法,支持128位(AES128)、192位(AES192)和256位(AES256)的密钥长度。
- DES:一种较旧的对称加密算法,但由于其密钥长度较短(56位),现在已经不够安全很少使用。
- 3DES:DES的增强版本,通过应用三次DES来提高安全性。
密钥交换算法:
- Diffe-Hellman(DH):一种基于离散对数的密钥交换协议,用于在两端之间建立共享密钥。
身份验证算法:
- RSA:一种非对称加密算法,通过公钥和私钥的配合使用来加密和解密数据。
- PSK:一种基于预共享密钥的身份验证算法,不需要使用公钥和私钥,只需要在两端预配置一个共享密钥。
- ECDSA:一种基于椭圆曲线的公开密钥加密算法。
IPsec主要使用对称加密进行数据传输加密,非对称加密主要用于密钥交换(IKE)阶段。
安全关联(SA)
IPSec使用安全关联(Security association)来建立和管理加密和认证参数。SA是两个通信实体之间的一组安全参数,包括加密算法、密钥、哈希算法等。
IPsec的SA是通过互联网安全关联和密钥管理协议(ISAKMP)建立的。ISAKMP 通过手动配置预共享密钥、互联网密钥交换(IKE 和 IKEv2)等等方式实现。
为了确定数据包应怎样来保护,IPsec使用安全参数索引(SPI),这是一个对安全关联数据库(SADB)的索引,再加上数据包头部的目的地址,这两者共同标识了唯一数据包的SA。
对于出站和入站数据包,都会执行类似的过程,因此IPsec通信需要至少两个SA(一个用于入站流量,一个用于出站流量)。IPSec通常使用IKE(Internet Key Exchange) 协议来建立、协商和管理SA。
互联网密钥交换(IKE)
IPsec中IKE协议采用UDP 500端口发起和响应协商,在NAT场景下,使用UDP 4500端口进行通信。
IKEv1和IKEv2
IKEv1包含两个阶段,IKE phase 1和IKE phase 2。
-
IKE阶段1
IKE阶段1的目标是建立一个安全的、加密的通道,用于两个通信实体之间的安全通信。这个阶段主要对通信双方进行身份验证,并且协商一个共享的会话密钥,该密钥将用于IKE阶段2的通信加密。IKE阶段1有两种模式:主模式(Main Mode)和侵入模式(Aggressive Mode),其中主模式提供更好的安全性,但是侵入模式更快。
在阶段1完成后,双方将建立一个IKE SA,这个SA是专用于IKE自身消息的安全通道,并不用于IPsec传输数据的保护。 -
IKE阶段2
IKE阶段2的目的是使用阶段1中建立的安全通道来协商用于保护IP数据包的IPsec SA参数。阶段2通常使用快速模式(Quick Mode)的交换来实现。
在阶段2完成后,就建立了用于实际数据传输的IPsec SA。这个SA是单向的,因此通常会建立两个SA,一个用于入站数据,另一个用于出站数据。
IKEv2是对IKEv1的改进,提供了更高的安全性和更有效的SA协商机制。它简化了协议流程,只包含一个阶段,这个阶段既建立了IKE SA,也协商了IPsec SA。IKEv2还引入了许多改进,比如对NAT穿越的支持、EAP认证、对断开连接后的自动重新连接等。
IPSec工作流程
通信过程
-
识别“感兴趣流(interested traffic)”。网络设备接收到报文后,通常会将报文的五元组等信息和IPsec策略进行匹配来判断报文是否要通过IPsec隧道传输,需要通过IPsec隧道传输的流量通常被称为“感兴趣流”。
-
协商安全关联(SA)。SA是通信双方对某些协商要素的约定,比如双方使用的安全协议、数据传输采用的封装模式、协议采用的加密和验证算法、用于数据传输的密钥等,通信双方之间只有建立了SA,才能进行安全的数据传输。
识别出感兴趣流后,本端网络设备会向对端网络设备发起SA协商。在这一阶段,通信双方之间通过IKE协议先协商建立IKE SA(用于身份验证和密钥信息交换),然后在IKE SA的基础上协商建立IPsec SA(用于数据安全传输)。 -
数据传输。IPsec SA建立成功后,双方就可以通过IPsec隧道传输数据了。
IPsec为了保证数据传输的安全性,在这一阶段需要通过AH或ESP协议对数据进行加密和验证。加密机制保证了数据的机密性,防止数据在传输过程中被窃取;验证机制保证了数据的真实可靠,防止数据在传输过程中被仿冒和篡改。
如图所示,IPsec发送方会使用加密算法和加密密钥对报文进行加密,将原始数据封装起来。然后发送方和接收方分别通过相同的验证算法和验证密钥对加密后的报文进行处理得到完整性校验值ICV。如果两端计算的ICV相同则表示该报文在传输过程中没有被篡改,接收方对验证通过的报文进行解密处理;如果ICV不相同则直接丢弃报文。 -
隧道拆除。通常情况下,通信双方之间的会话老化即代表通信双方数据交换已经完成,因此为了节省系统资源,通信双方之间的隧道在空闲时间达到一定值后会自动删除。
IPsec流量匹配
在IPsec隧道配置中,还有一个重要的条件是确保两端的感兴趣流配置匹配。例如A站点的地址为10.0.1.0/24和10.0.2.0/24;B站点的地址范围为10.10.10.0/24。因此,为了更好的兼容,确保隧道的正确建立:
- A站点(本地)的策略应定义为从10.0.1.0/24和10.0.2.0/24到B站点的目的子网10.10.10.0/24。
- B站点(对端)的策略应该相应地反映这一配置,但是方向相反。因此B站点需要定义10.10.10.0/24到A站点对应的10.0.1.0/24和10.0.2.0/24,而尽量不要使用10.10.10.0/24到A站点的10.0.0.0/22。
当你将多个C类地址(例如10.0.0.0/24 - 10.0.3.0/24)聚合为一个较大的子网时,可能会由于配置不一致导致设备间协商SA失败的问题,因此要将两边的策略配置一致。
例如,Router-1配置acl为两条明细,他将建立两条出站SA(因为没有活跃的流量,目前没有建立IPSec SA)。
Router-2配置的则为聚合的网段,他就只会建立一条出站SA。
当VPC10(10.10.10.10)->VPC2(10.0.2.10)时
Router-2会根据自己的感兴趣流配置协商建立出站SA
- 源地址: 10.10.10.0/24
- 目的地址: 10.0.0.0/22
- SPI: TBD
Router-1收到会发现这个不在自己感兴趣流里面,于是协商不成,从而导致无法访问。
反之,当VPC2(10.0.2.10)->VPC10(10.10.10.10)时,Router-1会根据明细的10.0.2.0/24到10.10.10.0/24建立出站SA
- 源地址: 10.0.2.0/24
- 目的地址: 10.10.10.0/24
- SPI: 0x77716905
Router-2收到检查这个子网会匹配到自己的感兴趣流,于是成功协商,建立相应的SA。
查看Router-1会发现,对应的IPSec SA已经处于active状态,并且outbound和inbound都协商成功
再查看Router-2可以看到,匹配到感兴趣的流后,创建了一个相应的IPSec SA并且协商的inbound和outbound的spi和Router-1一致。
同时,当我们再次尝试从VPC10(10.10.10.10)->VPC2(10.0.2.10)的访问,将会发现,可以通过这个新建立的IPSec SA完成通信。
所以,当我们在正式环境下配置IPSec时,需要尽可能得保持两端配置一致,否则可能造成IPSec无法正常使用的问题。
总结
虽然IPSec看起来比较复杂,用到很多协议,有各种各样的加密算法,但是就简而言之,你其实不需要过深入地关心它们具体怎么进行安全的协商,加密算法如何完成数据加密,你只需要关心它的隧道建立需要经过哪些过程,它内部数据要能正常通信又需要经过怎样的过程。
了解了这些内容之后,相信会有助于你理解需要完成哪些内容才能成功建立IPSec站点,并在维护过程中遇到问题时,如何缩小问题范围并定位问题所在。
最后,希望这篇文章的讲解足够清晰,能够帮助你加深对IPSec的理解。
实用工具
IPsec 数据包长度计算工具:
https://ipsec-overhead-calculator.netsec.us/
https://community.cisco.com/legacyfs/online/legacy/4/8/7/27784-IPSec_Calculator_NAT_GRE-Key.htm
参考资料
https://www.cisco.com/c/en/us/td/docs/net_mgmt/vpn_solutions_center/2-0/ip_security/provisioning/guide/IPsecPG1.html
https://datatracker.ietf.org/doc/html/rfc2409
https://en.wikipedia.org/wiki/IPsec
https://support.huawei.com/enterprise/en/doc/EDOC1100193603