Rancher Managed Network实践


需求提出

我们知道,Rancher原生的Managed网络是通过IPsec来建立起安全隧道来保障各service之间可达性的。相比于其他一些VPN技术,IPSec最大的优势在于其安全性;这种安全除了指业务数据加密传输外,还包括了一套秘钥交换的安全机制,这是诸如VXLAN之类的其他L3 VPN技术无法匹敌的。但正是为了提供这一层安全机制,IPSec需要在数据交换过程中对报文做逐一加密,势必消耗CPU资源,影响传输效率。

我们做过一些测试:在与Host网络的iperf测试比较中,Managed网络表现出来的性能损耗较严重(当然这也与运行Rancher的主机配置有关)。可惜在Rancher当前正式的Release版本中,除Managed网络外,并未提供其他的Overlay网络作为可选项。

现实是某些用户拥有自建数据中心,Rancher被部署到数据中心内部,网络安全相对已经较有保障。受到业务性质的影响,一些场景对网络传输效率的要求较高。此时Managed网络就显得有些无法覆盖需求了。于是,我们思考能否在不考虑安全性的前提下对Rancher的Managed网络做一些修改,从而提高网络传输效率。

一个较直接的思路就是去除对业务报文的加密过程。

IPSec基本概念

这一节不准备详细讲解IPSec原理,只将一些重要概念点到为止,有兴趣的同学可以下来研究IETF的RFC。

我们首先用一张图来认识IPSec框架:

这里写图片描述

IPSec模式

  1. 传输模式:适用于两台主机之间的数据保护。

  2. 隧道模式:适用于建立site-2-site的安全VPN隧道。(Rancher Managed网络显然是要为Host上的所有Containers打通一条加密隧道,是使用隧道模式)


IPSec安全协议

安全协议包括AH、ESP以及它们的组合AH-ESP,Rancher中使用的是ESP,通过下图我们可以形象的了解IPSec的模式和安全协议之间的关系:

这里写图片描述

另外,有抓过包的同学会发现,Rancher的IPSec报文与这里基于Tunnel模式+ESP安全协议的封包格式有些不同。实际抓到的报文在外层的IP头部之后,ESP域之前,还包含了一个使用4500端口的UDP头部。这是NAT-T功能,它的实现机制是首先判断是否两端设备是否都支持NAT-T,然后检测链路上是否存在NAT,一旦两个条件都满足就启动NAT-T,将所有的业务报文使用UDP的4500端口进行传输。

保障私密性

IPSec支持使用多种加密算法对传输的业务数据进行加密。通过加密把数据从明文变成无法读懂的密文,从而确保数据的私密性。

加密算法分为:对称加密算法(DES/AES/3DES等)与非对称加密算法(比如RSA)

这里写图片描述

保障完整性

通过对数据进行HASH运算,产生类似于指纹的数据摘要,连同数据一起传输到对端,以确认数据未被非法篡改,保障数据完整性。

常见的HASH算法有MD5/SHA等。

这里写图片描述

保障真实性

对称加密和HASH都要求通信双方具有相同的密钥,在双方之间安全地传递密钥就需要一套密钥交换算法。

通过身份认证可以保证数据的真实性,确保数据确实是由特定的对端发出的。

常用的身份认证方式包括:Pre-shared key 预共享密钥、 RSA Signature 数字签名等。

下图是隧道模式的ESP封包流程,它反映了如何使用加密算法和验证算法来生成最终的加密报文。

这里写图片描述

IKE

另外,IPSec还包括IKE。IKE是一种安全机制,提供端与端之间的动态认证,为IPsec提供了自动协商交换密钥、建立SA的服务,简化IPsec的使用、管理(配置和维护)工作。IKE不是在网络上直接传输密钥,而是通过一系列数据的交换,最终计算出双方共享的密钥。有了IKE,IPsec很多参数(如:密钥)都可以自动建立,降低了手工配置的复杂度。

IKE使用UDP端口500,通过使用特定的密钥交换算法进行秘钥交换。常见的算法有DH和RSA算法。

讲了这么多理论的东西,现在我们回到Rancher,来看看Rancher的Managed网络是如何工作的。

Rancher Managed网络原理

通过进入agent-instance容器查看进程信息可以发现其主要启动了如下进程:
1. rancher-metadata
2. rancher-dns
3. rancher-net
4. charon
5. haproxy
6. host-api

rancher-metadata启动了一个web server,用于响应该agent所辖containers的metadata请求。

rancher-dns实现了一个监听在IP地址:169.254.169.250上的skydns实例,用于响应该agent所辖container的dns请求。

haproxy其实是一个负载均衡程序,其自带对member指定端口的healthcheck,此处主要用它来对配置了healthcheck的容器做健康检查。

host-api在该container内用于将haproxy采集到的数据上报到cattle。

我们重点来分析rancher-net和charon:

rancher-net的配置主要基于文件:"/var/lib/cattle/etc/cattle/ipsec/config.json" , 该文件包含了Environment内部所有Managed Network的Container地址信息。

具体格式如下:

这里写图片描述

rancher-net通过启动charon来往xfrm中下发配置,从而维护IPSec的链路和policy。

charon用来实现IKE之间的协商并下发rule到xfrm,下一章节实践中对IPSec加密方式的修改就要通过调用charon的接口来实现。

rancher-net除了通过charon下发xfrm state外,还需要配置xfrm policy,这一块的实现是在rancher-net中直接执行“ip xfrm policy add”来实现的。

这里写图片描述

这里写图片描述

除此之外,还有一个可以查看strongswan状态的命令行接口swanctl:

这里写图片描述

在IPSec之外,rancher-net还需要监听所有的ARP请求,并响应那些目标IP地址通过IPSec tunnel可达,但又不在本Host的ARP请求。

这里写图片描述

综上,rancher-net的功能包含:

监听8111端口,响应reload和ping的HTT请求。

当有reload请求时,读取配置文件,将到达配置文件中所有IP的路径都校验一遍:
a.如果有新加主机,添加ipsec隧道;
b.如果有新加container,但是已经存在IPSec,更新xfrm policy;
c.如果有删除执行相反操作。
监听eth0上的ARP请求,响应需要到达IPSec对端IP的ARP请求。

整个IPSec隧道的拓扑如下所示:

这里写图片描述

Managed网络实践

说了这么多,各位都已经蒙圈了吧。话不多少,修改代码环节隆重上场。

代码的修改相对简单,只需要将proposals的第一个加密方式改为null。

如:“null-sha1-modp2048” 代表:
1. 使用对称加密方式为null(不加密);

2. 使用sha1的HASH算法;
3. 使用modp2048的非对称加密算法进行秘钥交换。

这里写图片描述

然后使用Dockerfile.dapper重新编译代码,确保没有编译错误。

我们知道,所有agent上的包均是启动时从cattle拉下来的;因此,通过更新docker image的方式来替换rancher-net是没有用的。

为了做测试,我们先直接将编译出来的rancher-net可执行文件通过docker cp替换掉agent-instance中的rancher-net。

替换并运行,发现charon协商IKE无法成功,提示“ENCRYPTION_ALGORITHM NULL (key size 20) not supported!”。 这是因为我们将加密算法置为了NULL,系统中的charon不支持。

查询官网发现NULL需要IKE中openssl的支持,有可能是rancher在编译charon的时候没有指定编译openssl plugin所致:

这里写图片描述

修改方法是charon编译的时候指定参数--enable-openssl 见:

[https://lists.strongswan.org/p ... .html]

分析代码发现agent-instance在初始化的时候是通过安装“rancher/strongswan-package”生成的包来得到charon的。因此,转到rancher/strongswan-package重新指定./configure --enable-openssl编译charon。

这里写图片描述

生成新的可执行文件后,先执行“ip xfrm state flush” 和 “ip xfrm policy flush”, 然后再重启rancher-net和charon;如果先不刷掉policy和state会导致新添加的ipsec无法生效。

修改之后,环境如下:

这里写图片描述

两个Network Agent容器分别为IPSec的端点,另外,每台host上各运行有一个Iperf容器用于测试。

这里写图片描述

通过swanctl --list-algs可以看到,所有支持的加密算法,其中由于我们load了openssl,已经能够支持NULL了。

这里写图片描述

查看xfrm里的ipsec规则,encryption已经为ciper_null,即不加密。

这里写图片描述

xfrm里的policy列出了到达对端iperf container的策略,即走IPSec tunnel。

跨主机测试

在两台主机上的iperf容器,一个作为iperf服务端,另一个作为客户端做带宽测试。

在测试过程中,需要抓包确认是否修改已经生效,如下:

这里写图片描述

可以看到,ESP sequence之后是0X45 0X00的,显然这是一个RAW的IP header。

为了确认这个信息,我们decode出该IP header中的src IP和dst IP,分别为:
0x0A 0X2A 0XF4 0XFA 和0x0A 0x2A 0xB4 0xF9
0x0A 0X2A 0XF4 0XFA = 10.42.224.250
0x0A 0x2A 0xB4 0xF9 = 10.42.180.249

这两台IP地址正是我们的iperf服务端和客户端容器的IP地址;因此,可以判断此时报文是没有经过加密的;我们的修改已生效。

这里写图片描述

更改前

这里写图片描述

更改后

经在两台千兆网卡的服务器上5分钟iperf测试,使用Rancher原生Managed网络的带宽为600+Mbps,在修改加密方式为NULL之后,iperf测试带宽提升为800+Mbps。

原文来源:Rancher Labs

2 个评论

写得很好啊。有动手经验,加油。
有任何疑问或者想法,欢迎添加微信助手(rancher2),进官方技术群,和大家一起交流~

要回复文章请先登录注册