Rancher Managed Network实践
需求提出
我们知道，Rancher原生的Managed网络是通过IPsec来建立起安全隧道来保障各service之间可达性的。相比于其他一些×××技术，IPSec最大的优势在于其安全性；这种安全除了指业务数据加密传输外，还包括了一套秘钥交换的安全机制，这是诸如VXLAN之类的其他L3 ×××技术无法匹敌的。但正是为了提供这一层安全机制，IPSec需要在数据交换过程中对报文做逐一加密，势必消耗CPU资源，影响传输效率。
我们做过一些测试：在与Host网络的iperf测试比较中，Managed网络表现出来的性能损耗较严重（当然这也与运行Rancher的主机配置有关）。可惜在Rancher当前正式的Release版本中，除Managed网络外，并未提供其他的Overlay网络作为可选项。
现实是某些用户拥有自建数据中心，Rancher被部署到数据中心内部，网络安全相对已经较有保障。受到业务性质的影响，一些场景对网络传输效率的要求较高。此时Managed网络就显得有些无法覆盖需求了。于是，我们思考能否在不考虑安全性的前提下对Rancher的Managed网络做一些修改，从而提高网络传输效率。
一个较直接的思路就是去除对业务报文的加密过程。
IPSec基本概念
这一节不准备详细讲解IPSec原理，只将一些重要概念点到为止，有兴趣的同学可以下来研究IETF的RFC。
我们首先用一张图来认识IPSec框架：
IPSec模式
传输模式：适用于两台主机之间的数据保护。
隧道模式：适用于建立site-2-site的安全×××隧道。（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容器查看进程信息可以发现其主要启动了如下进程：
rancher-metadata
rancher-dns
rancher-net
charon
haproxy
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" 代表：
使用对称加密方式为null（不加密）；
使用sha1的HASH算法；
使用modp2048的非对称加密算法进行秘钥交换。
然后使用Dockerfile.dapper重新编译代码，确保没有编译错误。
我们知道，所有agent上的包均是启动时从cattle拉下来的；因此，通过更新docker p_w_picpath的方式来替换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/pipermail/dev/2011-February/000253.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。
