小编给大家分享一下Rancher Managed Network的示例分析，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！
创新互联于2013年创立，是专业互联网技术服务公司，拥有项目网站建设、做网站网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元新乡做网站,已为上家服务,为新乡各地企业和个人服务,联系电话:18982081108
这一节不准备详细讲解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网络是如何工作的。
通过进入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">
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隧道的拓扑如下所示：
说了这么多，各位都已经蒙圈了吧。话不多少，修改代码环节隆重上场。代码的修改相对简单，只需要将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/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。
看完了这篇文章，相信你对“Rancher Managed Network的示例分析”有了一定的了解，如果想了解更多相关知识，欢迎关注创新互联行业资讯频道，感谢各位的阅读！
