edgemesh利用iptables劫持流量时遇到的问题分析

kubeedge相比kubernetes，主要的提供了跨子网构建集群的方案；其最强大的特点就是让kubernetes不在局限于一个物理机房之内；集群中的主机节点可以在不同的私有局域网内。

不同私有网络之下的主机要进行相互通信，最主要的就是受限于防火墙NAT形态：

上面的各组网方案之中，依次安全性增强，在对称锥形的网络中，所有主机都在各自的防火墙背后，直接穿透访问就非常困难，所以直接edgemesh提供了两种穿透访问方案：

edgemesh-server: Deployment 云端

edgemesh-agent: DaemonSet 云端+边缘

对于全锥形NAT、受限性NAT、部分端口受限锥形NAT访问可以直接采用如下方案；

对于直接穿透访问不了的请求，edgemesh-agent就会将流量转发到edgemesh-server上进行中继，因为所有的edgemesh-agent在启动后，就会于云端的edgemesh-server建立一个隧道网络；

在kubernetes+kubeedge组成的边缘云集群上，无论云端or边缘主机，都部署了edgemesh-agent，其有两个主要功能：

环境：

mkedge3 10.136.77.2 北四环办公室边缘盒子 edgemesh-agent role : edgenode kernel : 5.2.14-1.el7.elrepo.x86_64

mkedge2 10.201.82.131 天坛机房 edgemesh-agent role : edgenode kernel : 4.15.6-1.el7.elrepo.x86_64

用例：

在mkedge2上启动tcp-echo-cloud容器，通过mkedge3上的busybox容器进行远程telnet tcp-echo-cloud 2701

说明：

从实际流量抓包看来看，从办公室机房能够直接访问到天坛机房主机，不需要中继；

mkedge3发起请求tcp抓包

mkedge2上接收载荷tcp抓包

环境：

mkmaster1 10.200.50.118 国贸机房 edgemesh-server, edgemesh-agent role : master kernel : 5.2.14-1.el7.elrepo.x86_64

mkworker3 10.202.42.112 亦庄机房 edgemesh-agent role : cloudnode kernel : 5.2.14-1.el7.elrepo.x86_64

mkedge3 10.136.77.2 北四环办公室边缘盒子 edgemesh-agent role : edgenode kernel: 3.10.0-514.el7.x86_64

用例：

在mkworker3 上启动tcp-echo-cloud容器，通过mkedge3上的busybox容器进行远程telnet tcp-echo-cloud 2701

说明：

从实际流量抓包看来看，从办公室机房不能直接访问到亦庄机房主机，需要国贸机房的edgemesh-server中继；

mkedge3发起请求tcp抓包

mkmaster1进行中继tcp抓包

mkworker3上接收载荷tcp抓包

先说结论，怀疑主机默认内核 4.15.6-1.el7.elrepo.x86_64 (centos7) 存在调用系统内核函数getsockopt的严重bug！！！

环境：

mkmaster1 10.200.50.118 国贸机房 edgemesh-server, edgemesh-agent role : master kernel : 5.2.14-1.el7.elrepo.x86_64

mkworker1 10.201.82.139 天坛机房 edgemesh-agent role : cloudnode kernel : 5.2.14-1.el7.elrepo.x86_64

mkworker2 10.201.83.74 天坛机房 edgemesh-agent role : cloudnode kernel : 5.2.14-1.el7.elrepo.x86_64

mkedge1 10.201.82.148 天坛机房 edgemesh-agent role : edgenode kernel : 4.15.6-1.el7.elrepo.x86_64

mkedge2 10.201.82.131 天坛机房 edgemesh-agent role : edgenode kernel : 4.15.6-1.el7.elrepo.x86_64

mkedge3 10.136.77.2 北四环办公室边缘盒子 edgemesh-agent role : edgenode kernel: 3.10.0-514.el7.x86_64

用例：

在mkworker1、mkworker2、mkedge1、mkedge2上启动同时启动tcp-echo-cloud容器，通过mkedge1上的busybox容器进行远程访问这些服务，发现一个都不通；

现状：

从实际流量抓包看来看，从业务容器发送请求给到edgemesh-agent:40001端口，之后流量就不见了踪影；

[图片上传失败...(image-2899d1-1641166544225)]

究竟是Go的版本不对？容器镜像问题？逐个进行了排查：

给edgemesh-agent：proxy.go的Run()函数中，realServerAddress(&conn)调用之前，增加了打印日志，同时在这个函数调用中，增加了一些日志输出标记位，重新制作容器进行测试，发现输出日志 555 ，但未输出 666 ，同时进程状态异常变为了 D ：

然后就开始怀疑是这个内核调用出现了问题，先编写了一个go程序： https://gitee.com/Hu-Lyndon/gogetsockopt.git

如下是在mkedge3宿主机上， kernel: 3.10.0-514.el7.x86_64，一个终端上先将程序启动监听18011端口，然后在另外一个连接mkedge3终端上，直接telnet这个端口，程序能够正确通信，并输出打印日志 address: 192.168.127.1:18011

如下是在mkedge1上测试， kernel : 4.15.6-1.el7.elrepo.x86_64, 发现telnet之后，无法输出打印日志，并且程序在第三个终端窗口里也无法 kill -9 ，并且进程状态变为了 D ；

不死心 ，程序在mkedge2上依然如上；

不死心 ，找了台内核升级为 kernel : 4.19.12-1.el7.elrepo.x86_64的主机，结果是正确的；

不死心： 虽然严重怀疑了 kernel : 4.15.6-1.el7.elrepo.x86_64，那么就近是Go的问题，还是系统内核的问题呢？于是又写了一个C程序来测试： https://gitee.com/Hu-Lyndon/unix-network-programming ，在compile-on-kernel4.15.6分支的/sockopt/sockoptchk.c

依然出现了上面出现的问题，说明应该就是kernel的问题了，需要推荐运维以后不要安装这个版本的内核了，目前看4.19.12以上的版本或者干脆就是3.10的内核都是打过patch的。

https://go.dev/play/p/GMAaKucHOr

https://elixir.bootlin.com/linux/latest/C/ident/sys_getsockopt

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/socket.c

https://bugzilla.kernel.org/show_bug.cgi?id=198791

http://patchwork.ozlabs.org/project/netfilter-devel/patch/a4752d0887579496c5db267d9db7ff77719436d8.1518088560.git.pabeni@redhat.com/

https://github.com/cybozu-go/transocks/pull/14

简介：深圳市联华世纪通信技术有限公司是一家拥有信息产业部颁发的多项电信增值业务许可证的电信增值业务服务商，专注于为客户提供卓越的网和云解决方案，公司成立于2006年，总部位于深圳，分公司“联华电信国际有限公司”位于香港。公司宗旨：给我一个连接点，还您一个地球村。联华世纪主要经营：云主机、数据中心解决方案、服务器托管、服务器租用、机柜租赁、IPEL专线上网等服务。数据中心包括：深圳白沙机房、深圳留创机房、深圳软件园机房、东莞TGT数据中心、香港TGT数据中心、香港将军澳机房、深圳电信横岗雅力数据中心、北京电信亦庄数据中心、北京通州台湖数据中心、中国电信（沈阳）数据中心、江苏电信天目湖国际数据中心；可选择互联网线路：电信、联通、移动、BGP多线（动态与静态）等。

法定代表人：万孝义

成立时间：2006-01-11

注册资本：2200万人民币

工商注册号：440301102919060

企业类型：有限责任公司

公司地址：深圳市南山区沙河西路3011号白沙物流公司仓库之二8楼V区

---