干货 | 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框架:

2a24fc86a8696302da9904302f43f428.jpg


IPSec模式
1.传输模式:适用于两台主机之间的数据保护。
2.隧道模式:适用于建立site-2-site的安全VPN隧道。(Rancher Managed网络显然是要为Host上的所有Containers打通一条加密隧道,是使用隧道模式)

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

161231986cc6286004990cc55705b1cf.jpg


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

保障私密性
IPSec支持使用多种加密算法对传输的业务数据进行加密。通过加密把数据从明文变成无法读懂的密文,从而确保数据的私密性。加密算法分为:对称加密算法(DES/AES/3DES等)与非对称加密算法(比如RSA)

aab03db0739135a17110087640ac141b.jpg


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

5f28d4177312cd50f932b3b3522f1bdd.jpg


保障真实性
对称加密和HASH都要求通信双方具有相同的密钥,在双方之间安全地传递密钥就需要一套密钥交换算法。通过身份认证可以保证数据的真实性,确保数据确实是由特定的对端发出的。常用的身份认证方式包括:Pre-shared key 预共享密钥、 RSA Signature 数字签名等下图是隧道模式的ESP封包流程,它反映了如何使用加密算法和验证算法来生成最终的加密报文。

15fd170f7dd007b62286cf4abce26f65.jpg


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地址信息。
具体格式如下:

6568d51d4a8a218cb2c8c611b851c733.jpg


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

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

e1c4d9708878ce17a8528d8a2a2c0cde.jpg


2c33acd06683159db4f727a75687d7fa.jpg


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

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

f7dc66aea070586bcf6d6436d828caff.jpg


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

6eb49ef6c50d4ad05659a5cb1907f8f6.jpg


综上,rancher-net的功能包含:
监听8111端口,响应reload和ping的HTT请求。
当有reload请求时,读取配置文件,将到达配置文件中所有IP的路径都校验一遍:

a.如果有新加主机,添加ipsec隧道;
b.如果有新加container,但是已经存在IPSec,更新xfrm policy;
c.如果有删除执行相反操作。
监听eth0上的ARP请求,响应需要到达IPSec对端IP的ARP请求。整个IPSec隧道的拓扑如下所示:

5891db363e19955aadf3bfd655aeea1a.jpg


Managed网络实践

说了这么多,各位都已经蒙圈了吧。话不多少,修改代码环节隆重上场。代码的修改相对简单,只需要将proposals的第一个加密方式改为null。如:“null-sha1-modp2048” 代表:
1.使用对称加密方式为null(不加密);
2.使用sha1的HASH算法;
3.使用modp2048的非对称加密算法进行秘钥交换。

2d6414d68d9a339721365ff1bf0db2e9.jpg


然后使用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所致:

f7cf0a07f224a36c5f0146378e19f61a.jpg


修改方法是charon编译的时候指定参数--enable-openssl 见:
[https://lists.strongswan.org/p ... .html]
分析代码发现agent-instance在初始化的时候是通过安装“rancher/strongswan-package”生成的包来得到charon的。因此,
转到rancher/strongswan-package重新指定./configure --enable-openssl编译charon。

f7cf0a07f224a36c5f0146378e19f61a.jpg


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

f16eb522dd43b49e93817b8d5cb30319.jpg


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

fb4f5ca6ab1b4d0009cec5cfe8d1d422.jpg


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

7e19d7134f0eeedcacca7fdc760fbf05.jpg


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

ae4ebfc33fdaf2e954a76cef4a15d283.jpg


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

跨主机测试

在两台主机上的iperf容器,一个作为iperf服务端,另一个作为客户端做带宽测试。在测试过程中,需要抓包确认是否修改已经生效,如下:

9d933bdfb4e332a9138e397144d78889.jpg


可以看到,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地址;因此,可以判断此时报文是没有经过加密的;我们的修改已生效。

更改前

5ef4eccae170dce278da39b0af58a391.jpg


更改后

7cbfdb7e6cef2685ff5d2c887646dd43.jpg


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

作者陈乐吉(Henry Chen),睿云智合软件研发工程师,有近十年网络方面的开发经验;曾先后在Alpha-Networks、Nokia Siemens Networks、中电科华云从事以太网交换设备、Openstack网络、SDN等方面的研究和开发。主要负责Docker和Rancher的开发工作。
提醒:有任何问题请后台狂戳小编,如果没有及时回复您,那小编一定在狂奔的路上~

微信截图_20170104095538.png


01e5c73f387ac132cdc51b8d15276a49.jpg


微信号:wise2c

0 个评论

要回复文章请先登录注册