UCloud基于Linux内核新特性的下一代外网网关设计及相关开源工作\n

UCloud外网网关是为了承载外网IP、负载均衡等产品的外网出入向流量，当前基于Linux内核的OVS/GRE tunnel/netns/iptables等实现，很好地支撑了现有业务。同时，我们也在不断跟踪开源社区的新技术发展，并将之用于下一代外网网关的设计。这些新特性可将系统性能和管理能力再提上一档，满足未来几年的需求。在方案设计研发过程中发现，新特性存在不少缺陷和Bug，为此我们向开源社区回馈了10多个patch，并融入到kernel 5.0版本中，帮助完善kernel功能并提升稳定性。

\n

当前业界的多租户外网网关很多都是基于OpenFlow的OpenvSwitch（OVS）方案，然而随着内核路由转发功能的不断完善，利用内核原生路由转发方式进行设计多租户外网网关系统成为一种可能。在这种方式下能有效的使用传统iproute2路由工具以及iptables、nftables等Firewall工具，并且随着SwitchDev技术的兴起，未来将网关系统迁移到Linux Switch上也成为一种可能。

\n

现有kernel 3.x的不足

\n

当前广泛使用的内核版本为3.x系列，例如CentOS 7全系列标准支持的内核为3.10版本，Fedora/Ubuntu等Linux发行版也有大量使用。在3.x系列内核下存在着IP tunnel管理复杂、租户隔离性能损耗等问题。

\n

1. \n
2. IP tunnel管理复杂
   \nLinux内核创建IP tunnel设备来建立点对点的隧道连接，创建时需指定tunnel dst和 tunnel key。因为宿主机之间两两建立连接，面向宿主机的目的地址众多，这样就会导致网关节点上需要创建成千上万的tunnel设备，在大规模业务环境下，tunnel的管理将变得及其复杂。\n
3. 多租户隔离导致的性能下降
   \na. 公有云需要实现多租户隔离以确保用户间的安全和隐私。由于VPC网络下不同租户的内网地址可以重合，导致路由也有重合的可能性，此时需要通过大量的策略路由去隔离租户的路由规则，由于策略路由的链表属性，性能会随着链表长度的增加而急剧下降。
   \nb. 由于Firewall和NAT的实现基于同样链式的iptables，性能损耗同样可观。\n
4. netns带来性能开销
   \n通过netns实现租户路由和Firewall规则的隔离，但是netns会引入虚拟网卡和协议栈重入开销，使整体性能下降20%左右。\n

\n

三项内核新技术

\n

为了解决原有方案存在的困扰，我们调研了大量行业主流方案和内核上游的新动向，发现Lightweight tunneling（轻量级隧道，简称lwtunnel）、Virtual Routing Forwarding（虚拟路由转发，简称VRF）以及nftable \u0026amp; netfilter flow offload（流卸载）三项内核新技术的特性，可以帮助规避原方案存在的缺陷。

\n

1. \n
2. Lightweight tunneling\n

\n

Linux内核在4.3版本中引入了轻量级隧道Lightweight tunneling，它提供了通过route方式设置tunnel属性的方法，这样可以避免管理大量的tunnel设备。

\n

创建隧道设备时指定external模式，利用路由设置的轻量级隧道通过tun设备发送报文。

\n

\n

1. \n
2. Virtual Routing Forwarding\n

\n

Linux内核在4.3版本中引入了VRF的初步支持，并在4.8版本形成完备版本。Virtual Routing Forwarding虚拟路由转发，可以将一台Linux Box的物理路由器当多台虚拟路由器使用，能很好的解决租户路由隔离问题，避免直接使用策略路由。因此，可以将不同租户的网卡加入租户所属的虚拟路由器中来实现多租户的虚拟路由。

\n

\n

\n

1. \n
2. flow offload\n

\n

Nftables是一种新的数据包分类框架，旨在替代现存的{ip,ip6,arp,eb}_tables。在nftables中，大部分工作是在用户态完成的，内核只知道一些基本指令（过滤是用伪状态机实现的）。nftables的一个高级特性就是映射，可以使用不同类型的数据并映射它们。例如，我们可以映射iif device到专用的规则集合（之前创建的存储在一个链中）。由于是hash映射的方式，可以完美的避免链式规则跳转的性能开销。

\n

Linux内核在版本4.16引入了flow offload功能，它为IP forward提供了基于流的卸载功能。当一条新建连接完成首回合原方向和反方向的报文时，完成路由，Firewall和NAT工作后，在处理反方向首报文的forward hook，根据报文路由、NAT等信息创建可卸载flow到接收网卡ingress hook上。后续的报文可以在接收ingress hook上直接转发，不需要再进入IP stack处理。此外，将来flow offload还将支持hardware offload模式，这将极大提高系统转发性能。

\n

\n

\n

方案设计与优化实践

\n

通过对上述三项新技术的研究，我们发现可以尝试设计一套基于路由的方式，实现多租户overlay网络的外网网关。

\n

在方案设计过程中，我们也碰到了诸如lwtunnel和flow offload功能不足，以及VRF和flow offload不能一起有效的工作等问题。最终我们都设法解决了，并针对这些内核的不足提交patch给Linux开源社区。

\n

1. \n
2. lwtunnel发送报文tunnel_key丢失\n

\n

问题描述：我们利用lwtunnel路由方式发送报文时，创建了一个external类型的gretap tunnel，我们将命令设置了id为1000，但是发送成功报文中没有tunnel_key字段。

\n

\n

问题定位：我们研究iproute2代码，发现由于TUNNEL_KEY flag并没有开放给用户态，所以iproute2工具并没有对lwtunnel路由设置TUNNEL_KEY，导致报文不会创建tunnel_key字段。

\n

提交patch：我们给内核和用户态iproute2分别提交patch来解决这一问题：

\n

iptunnel: make TUNNEL_FLAGS available in uapi
\nhttps://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?
\nid=1875a9ab01dfa96b06cb6649cb1ce56efa86c7cb
\niproute: Set ip/ip6 lwtunnel flags
\nhttps://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=3d65cefbefc86a53877f1e6461a9461e5b8fd7b3

\n

提交patch后，可以通过以下方式设置路由。

\n

ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

\n

1. \n
2. lwtunnel对指定key的IP tunnel无效\n

\n

问题发现：为了能有效隔离租户路由，我们给每个租户创建一个基于tunnel_key的gretap tunnel设备。如下图，创建一个tunnel_key 1000的gretap tunnel设备，把tunnel设备加入租户所属VRF，tunnel设备能有效地接收报文，但并不能发送报文。

\n

\n

问题定位：研究内核发现，IP tunnel在非external模式下即使指定了轻量级隧道路由，发送报文也没有使用它，导致报文路由错误被丢弃。

\n

提交patch：

\n

ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel
\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d71b57532d70c03f4671dd04e84157ac6bf021b0

\n

提交patch后，在未指定tunnel_dst的非external模式IP tunnel下，能使用轻量级隧道路由进行发送报文。

\n

1. \n
2. external IP tunnel ARP无法正常运行\n

\n

问题描述：邻居IP tunnel进行了ARP请求，但是本端的ARP回应报文的隧道头中并没带tunnel_key字段。

\n

\n

问题定位：研究代码发现，tunnel收到了对端的ARP 请求，在发送报文ARP回复的时候会复制请求报文的tunnel信息，但是遗漏了所有tun_flags。

\n

提交patch：

\n

iptunnel: Set tun_flags in the iptunnel_metadata_reply from src
\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7bdca378b2301b1fc6a95c60d6d428408ae4e39e

\n

1. \n
2. Flow offload不能与DNAT有效工作\n

\n

问题描述：Firewall创建规则从eth0收到目的地址2.2.2.11的报文，DNAT为10.0.0.7， flow offload无法工作。

\n

\n

问题定位：分析发现，客户端1.1.1.7 —\u0026gt; 2.2.2.7 DNAT到server 10.0.0.7，第一个reply反向报文(syc+ack)使用了错的目的地址获取反向路由

\n

daddr = ct-\u0026gt;tuplehash[!dir].tuple.dst.u3.ip

\n

此时dir为反方向，所以daddr获取为原方向的目的地址，这个值是2.2.2.7, 但是由于被DNAT过，真正的路由不应该通过2.2.2.7去获取，而是应该根据10.0.0.7这个值去获取

\n

addr = ct-\u0026gt;tuplehash[dir].tuple.src.u3.ip

\n

提交patch：

\n

netfilter: nft_flow_offload: Fix reverse route lookup
\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a799aea0988ea0d1b1f263e996fdad2f6133c680

\n

1. \n
2. Flow offload不能与VRF有效工作\n

\n

问题描述：将网卡eth0和eth1加入VFR后，flow offload不起作用。

\n

\n

问题定位：查看代码发现，原方向和反方向首报文进入协议堆栈后skb-\u0026gt;dev会设置为vrf device user1，创建flow offload规则的iif就是user1。但是offload规则下发在eth0和eth1的ingress hook上，所以后续报文在eth0和eth1的ingress hook上不能匹配flow规则。

\n

提交patch：

\n

netfilter: nft_flow_offload: fix interaction with vrf slave device
\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10f4e765879e514e1ce7f52ed26603047af196e2

\n

最终，我们根据两个方向查找路由的结果，设置flow offload规则的iif和oif信息来解决此问题。

\n

1. \n
2. VRF PREROUTING hook重入问题\n

\n

问题描述：配置网卡加入VRF，firewall ingress方向规则为接收目的地址2.2.2.11 、TCP 目的端口22的报文，egress方向规则为丢弃TCP 目的端口 22的报文。出现异常结果: 收到目的地址2.2.2.11 TCP 22目的端口的报文却被丢弃。

\n

\n

问题定位：研究发现网卡加入VRF后收到的报文会两次进入PREROUTING hook，因为在进入IP stack时会进第一次PREROUTING hook，然后被VRF设备接管后会再次进入PREROUTING hook。上述规则第一次在rule-1000-ingress chain中dst nat为10.0.0.7，第二次由于报文被DNAT后会错误的进入rule-1000-egress，导致报文被丢弃。

\n

提交patch：我们给内核加了一个支持判断网卡类型的match项目，让用户态避免可知的第二次无效重入，内核态和用户态nftables分别提交了如下的patch：

\n

netfilter: nft_meta: Add NFT_META_I/OIFKIND meta type
\nhttps://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0fb4d21956f4a9af225594a46857ccf29bd747bc
\nmeta: add iifkind and oifkind support
\nhttp://git.netfilter.org/nftables/commit/?id=512795a673f999fb04b84dbbbe41174e9c581430

\n

使用方法:

\n

nft add rule firewall rules-all meta iifkind “vrf” counter accept

\n

原型验证

\n

最终，我们成功地利用lwtunnel、VRF和flow offload实现多租户外网网关的原型验证。验证过程如下：

\n

1. \n
2. 首先创建原型环境。
   \na. netns cl模拟外网client, 地址为1.1.1.7，tunnel src 172.168.0.7，配置发送路由；
   \nb. netns ns1模拟租户1，内网地址为10.0.0.7，外网地址为 2.2.2.11，tunnel src 172.168.0.11 tunnel_key 1000，配置发送路由；
   \nc. netns ns2模拟租户2，内网地址为10.0.0.7，外网地址为 2.2.2.12，tunnel src 172.168.0.12 tunnel_key 2000，配置发送路由；
   \nd. Host模拟外网网关，tunnel src 172.168.0.1，创建租户VRF user1和use2，创建租户IP tunnel tun1和tun2，配置转发路由。\n

\n

原型环境图如下：

\n

\n

\n

1. \n
2. 创建firewall规则：
   \na. 租户1入向允许TCP目的端口22和ICMP访问，出向禁止访问外部TCP 22目的端口；
   \nb. 租户2入向允许TCP端口23和ICMP访问，出向禁止访问外部TCP 23目的端口；
   \nc. 在租户tun1和tun2设备上支持flow offload。\n

\n

\n

最终，client可以通过2.2.2.11成功访问user1 tcp 22端口服务，user1不能访问client tcp 22端口服务；client可以通过2.2.2.12成功访问user2 tcp 23端口服务，user1不能访问client tcp 23端口服务。

\n

待后续hardware offload功能完善以及网卡厂商支持后，我们会做进一步的开发验证。

\n

写在最后

\n

以上是本项目涉及的部分核心问题，这些patch特性都可以在Linux kernel 5.0版本里获取。

\n

Linux作为成熟的开源套件，一直是云厂商使用的主流操作系统，但在技术的更新迭代过程中，一些新特性在实际应用上也会存在稳定性、兼容性等方面的问题。我们在研究使用上游技术的同时，也一直积极探索、丰富开源技术功能，帮助提高开源技术稳定性。并将产出持续回馈给社区，与社区共同构建一个繁荣的开源生态。

\n