UCloud基于Linux內(nèi)核新特性的下一代外網(wǎng)網(wǎng)關設計及相關開源工作

UCloud外網(wǎng)網(wǎng)關是為了承載外網(wǎng)IP、負載均衡等產(chǎn)品的外網(wǎng)出入向流量，當前基于Linux內(nèi)核的OVS/GRE tunnel/netns/iptables等實現(xiàn)，很好地支撐了現(xiàn)有業(yè)務。同時，我們也在不斷跟蹤開源社區(qū)的新技術發(fā)展，并將之用于下一代外網(wǎng)網(wǎng)關的設計。這些新特性可將系統(tǒng)性能和管理能力再提上一檔，滿足未來幾年的需求。在方案設計研發(fā)過程中發(fā)現(xiàn)，新特性存在不少缺陷和Bug，為此我們向開源社區(qū)回饋了10多個patch，并融入到kernel 5.0版本中，幫助完善kernel功能并提升穩(wěn)定性。

當前業(yè)界的多租戶外網(wǎng)網(wǎng)關很多都是基于OpenFlow的OpenvSwitch（OVS）方案，然而隨著內(nèi)核路由轉(zhuǎn)發(fā)功能的不斷完善，利用內(nèi)核原生路由轉(zhuǎn)發(fā)方式進行設計多租戶外網(wǎng)網(wǎng)關系統(tǒng)成為一種可能。在這種方式下能有效的使用傳統(tǒng)iproute2路由工具以及iptables、nftables等Firewall工具，并且隨著SwitchDev技術的興起，未來將網(wǎng)關系統(tǒng)遷移到Linux Switch上也成為一種可能。

現(xiàn)有kernel 3.x的不足

當前廣泛使用的內(nèi)核版本為3.x系列，例如CentOS 7全系列標準支持的內(nèi)核為3.10版本，F(xiàn)edora/Ubuntu等Linux發(fā)行版也有大量使用。在3.x系列內(nèi)核下存在著IP tunnel管理復雜、租戶隔離性能損耗等問題。

1. IP tunnel管理復雜

Linux內(nèi)核創(chuàng)建IP tunnel設備來建立點對點的隧道連接，創(chuàng)建時需指定tunnel dst和 tunnel key。因為宿主機之間兩兩建立連接，面向宿主機的目的地址眾多，這樣就會導致網(wǎng)關節(jié)點上需要創(chuàng)建成千上萬的tunnel設備，在大規(guī)模業(yè)務環(huán)境下，tunnel的管理將變得及其復雜。

2. 多租戶隔離導致的性能下降

a. 公有云需要實現(xiàn)多租戶隔離以確保用戶間的安全和隱私。由于VPC網(wǎng)絡下不同租戶的內(nèi)網(wǎng)地址可以重合，導致路由也有重合的可能性，此時需要通過大量的策略路由去隔離租戶的路由規(guī)則，由于策略路由的鏈表屬性，性能會隨著鏈表長度的增加而急劇下降。

b. 由于Firewall和NAT的實現(xiàn)基于同樣鏈式的iptables，性能損耗同樣可觀。

3. netns帶來性能開銷

通過netns實現(xiàn)租戶路由和Firewall規(guī)則的隔離，但是netns會引入虛擬網(wǎng)卡和協(xié)議棧重入開銷，使整體性能下降20%左右。

三項內(nèi)核新技術

為了解決原有方案存在的困擾，我們調(diào)研了大量行業(yè)主流方案和內(nèi)核上游的新動向，發(fā)現(xiàn)Lightweight tunneling（輕量級隧道，簡稱lwtunnel）、Virtual Routing Forwarding（虛擬路由轉(zhuǎn)發(fā)，簡稱VRF）以及nftable & netfilter flow offload（流卸載）三項內(nèi)核新技術的特性，可以幫助規(guī)避原方案存在的缺陷。

1. Lightweight tunneling

Linux內(nèi)核在4.3版本中引入了輕量級隧道Lightweight tunneling，它提供了通過route方式設置tunnel屬性的方法，這樣可以避免管理大量的tunnel設備。

創(chuàng)建隧道設備時指定external模式，利用路由設置的輕量級隧道通過tun設備發(fā)送報文。

2. Virtual Routing Forwarding

Linux內(nèi)核在4.3版本中引入了VRF的初步支持，并在4.8版本形成完備版本。Virtual Routing Forwarding虛擬路由轉(zhuǎn)發(fā)，可以將一臺Linux Box的物理路由器當多臺虛擬路由器使用，能很好的解決租戶路由隔離問題，避免直接使用策略路由。因此，可以將不同租戶的網(wǎng)卡加入租戶所屬的虛擬路由器中來實現(xiàn)多租戶的虛擬路由。

3. flow offload

Nftables是一種新的數(shù)據(jù)包分類框架，旨在替代現(xiàn)存的{ip,ip6,arp,eb}_tables。在nftables中，大部分工作是在用戶態(tài)完成的，內(nèi)核只知道一些基本指令（過濾是用偽狀態(tài)機實現(xiàn)的）。nftables的一個高級特性就是映射，可以使用不同類型的數(shù)據(jù)并映射它們。例如，我們可以映射iif device到專用的規(guī)則集合（之前創(chuàng)建的存儲在一個鏈中）。由于是hash映射的方式，可以完美的避免鏈式規(guī)則跳轉(zhuǎn)的性能開銷。

Linux內(nèi)核在版本4.16引入了flow offload功能，它為IP forward提供了基于流的卸載功能。當一條新建連接完成首回合原方向和反方向的報文時，完成路由，F(xiàn)irewall和NAT工作后，在處理反方向首報文的forward hook，根據(jù)報文路由、NAT等信息創(chuàng)建可卸載flow到接收網(wǎng)卡ingress hook上。后續(xù)的報文可以在接收ingress hook上直接轉(zhuǎn)發(fā)，不需要再進入IP stack處理。此外，將來flow offload還將支持hardware offload模式，這將極大提高系統(tǒng)轉(zhuǎn)發(fā)性能。

方案設計與優(yōu)化實踐

通過對上述三項新技術的研究，我們發(fā)現(xiàn)可以嘗試設計一套基于路由的方式，實現(xiàn)多租戶overlay網(wǎng)絡的外網(wǎng)網(wǎng)關。在方案設計過程中，我們也碰到了諸如lwtunnel和flow offload功能不足，以及VRF和flow offload不能一起有效的工作等問題。最終我們都設法解決了，并針對這些內(nèi)核的不足提交patch給Linux開源社區(qū)。

1. lwtunnel發(fā)送報文tunnel_key丟失

問題描述：我們利用lwtunnel路由方式發(fā)送報文時，創(chuàng)建了一個external類型的gretap tunnel，我們將命令設置了id為1000，但是發(fā)送成功報文中沒有tunnel_key字段。

問題定位：我們研究iproute2代碼，發(fā)現(xiàn)由于TUNNEL_KEY flag并沒有開放給用戶態(tài)，所以iproute2工具并沒有對lwtunnel路由設置TUNNEL_KEY，導致報文不會創(chuàng)建tunnel_key字段。

提交patch：我們給內(nèi)核和用戶態(tài)iproute2分別提交patch來解決這一問題：

iptunnel: make TUNNEL_FLAGS available in uapi

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?

id=1875a9ab01dfa96b06cb6649cb1ce56efa86c7cb

iproute: Set ip/ip6 lwtunnel flags

https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=3d65cefbefc86a53877f1e6461a9461e5b8fd7b3

提交patch后，可以通過以下方式設置路由。

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

2. lwtunnel對指定key的IP tunnel無效

問題發(fā)現(xiàn)：為了能有效隔離租戶路由，我們給每個租戶創(chuàng)建一個基于tunnel_key的gretap tunnel設備。如下圖，創(chuàng)建一個tunnel_key 1000的gretap tunnel設備，把tunnel設備加入租戶所屬VRF，tunnel設備能有效地接收報文，但并不能發(fā)送報文。

問題定位：研究內(nèi)核發(fā)現(xiàn)，IP tunnel在非external模式下即使指定了輕量級隧道路由，發(fā)送報文也沒有使用它，導致報文路由錯誤被丟棄。

提交patch：

ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d71b57532d70c03f4671dd04e84157ac6bf021b0

提交patch后，在未指定tunnel_dst的非external模式IP tunnel下，能使用輕量級隧道路由進行發(fā)送報文。

3. external IP tunnel ARP無法正常運行

問題描述：鄰居IP tunnel進行了ARP請求，但是本端的ARP回應報文的隧道頭中并沒帶tunnel_key字段。

問題定位：研究代碼發(fā)現(xiàn)，tunnel收到了對端的ARP 請求，在發(fā)送報文ARP回復的時候會復制請求報文的tunnel信息，但是遺漏了所有tun_flags。

提交patch：

iptunnel: Set tun_flags in the iptunnel_metadata_reply from src

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7bdca378b2301b1fc6a95c60d6d428408ae4e39e

4. Flow offload不能與DNAT有效工作

問題描述：Firewall創(chuàng)建規(guī)則從eth0收到目的地址2.2.2.11的報文，DNAT為10.0.0.7， flow offload無法工作。

問題定位：分析發(fā)現(xiàn)，客戶端1.1.1.7 ---> 2.2.2.7 DNAT到server 10.0.0.7，第一個reply反向報文(syc+ack)使用了錯的目的地址獲取反向路由

daddr = ct->tuplehash[!dir].tuple.dst.u3.ip

此時dir為反方向，所以daddr獲取為原方向的目的地址，這個值是2.2.2.7, 但是由于被DNAT過，真正的路由不應該通過2.2.2.7去獲取，而是應該根據(jù)10.0.0.7這個值去獲取

addr = ct->tuplehash[dir].tuple.src.u3.ip

提交patch：

netfilter: nft_flow_offload: Fix reverse route lookup

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a799aea0988ea0d1b1f263e996fdad2f6133c680

5. Flow offload不能與VRF有效工作

問題描述：將網(wǎng)卡eth0和eth1加入VFR后，flow offload不起作用。

問題定位：查看代碼發(fā)現(xiàn)，原方向和反方向首報文進入?yún)f(xié)議堆棧后skb->dev會設置為vrf device user1，創(chuàng)建flow offload規(guī)則的iif就是user1。但是offload規(guī)則下發(fā)在eth0和eth1的ingress hook上，所以后續(xù)報文在eth0和eth1的ingress hook上不能匹配flow規(guī)則。

提交patch：

netfilter: nft_flow_offload: fix interaction with vrf slave device

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10f4e765879e514e1ce7f52ed26603047af196e2

最終，我們根據(jù)兩個方向查找路由的結果，設置flow offload規(guī)則的iif和oif信息來解決此問題。

6. VRF PREROUTING hook重入問題

問題描述：配置網(wǎng)卡加入VRF，firewall ingress方向規(guī)則為接收目的地址2.2.2.11 、TCP 目的端口22的報文，egress方向規(guī)則為丟棄TCP 目的端口 22的報文。出現(xiàn)異常結果: 收到目的地址2.2.2.11 TCP 22目的端口的報文卻被丟棄。

問題定位：研究發(fā)現(xiàn)網(wǎng)卡加入VRF后收到的報文會兩次進入PREROUTING hook，因為在進入IP stack時會進第一次PREROUTING hook，然后被VRF設備接管后會再次進入PREROUTING hook。上述規(guī)則第一次在rule-1000-ingress chain中dst nat為10.0.0.7，第二次由于報文被DNAT后會錯誤的進入rule-1000-egress，導致報文被丟棄。

提交patch：我們給內(nèi)核加了一個支持判斷網(wǎng)卡類型的match項目，讓用戶態(tài)避免可知的第二次無效重入，內(nèi)核態(tài)和用戶態(tài)nftables分別提交了如下的patch：

netfilter: nft_meta: Add NFT_META_I/OIFKIND meta type

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0fb4d21956f4a9af225594a46857ccf29bd747bc

meta: add iifkind and oifkind support

http://git.netfilter.org/nftables/commit/?id=512795a673f999fb04b84dbbbe41174e9c581430

使用方法:

nft add rule firewall rules-all meta iifkind "vrf" counter accept原型驗證

最終，我們成功地利用lwtunnel、VRF和flow offload實現(xiàn)多租戶外網(wǎng)網(wǎng)關的原型驗證。驗證過程如下：

1. 首先創(chuàng)建原型環(huán)境。

a. netns cl模擬外網(wǎng)client, 地址為1.1.1.7，tunnel src 172.168.0.7，配置發(fā)送路由；

b. netns ns1模擬租戶1，內(nèi)網(wǎng)地址為10.0.0.7，外網(wǎng)地址為 2.2.2.11，tunnel src 172.168.0.11 tunnel_key 1000，配置發(fā)送路由；

c. netns ns2模擬租戶2，內(nèi)網(wǎng)地址為10.0.0.7，外網(wǎng)地址為 2.2.2.12，tunnel src 172.168.0.12 tunnel_key 2000，配置發(fā)送路由；

d. Host模擬外網(wǎng)網(wǎng)關，tunnel src 172.168.0.1，創(chuàng)建租戶VRF user1和use2，創(chuàng)建租戶IP tunnel tun1和tun2，配置轉(zhuǎn)發(fā)路由。

原型環(huán)境圖如下：

2. 創(chuàng)建firewall規(guī)則：

a. 租戶1入向允許TCP目的端口22和ICMP訪問，出向禁止訪問外部TCP 22目的端口；

b. 租戶2入向允許TCP端口23和ICMP訪問，出向禁止訪問外部TCP 23目的端口；

c. 在租戶tun1和tun2設備上支持flow offload。

最終，client可以通過2.2.2.11成功訪問user1 tcp 22端口服務，user1不能訪問client tcp 22端口服務；client可以通過2.2.2.12成功訪問user2 tcp 23端口服務，user1不能訪問client tcp 23端口服務。

待后續(xù)hardware offload功能完善以及網(wǎng)卡廠商支持后，我們會做進一步的開發(fā)驗證。

寫在最后

以上是本項目涉及的部分核心問題，這些patch特性都可以在Linux kernel 5.0版本里獲取。我們把這期間為Linux kernel社區(qū)貢獻的patch整理成了一份列表，希望能為開發(fā)者提供幫助，讀者可以點擊“閱讀原文”閱覽完整patch list。

Linux作為成熟的開源套件，一直是云廠商使用的主流操作系統(tǒng)，但在技術的更新迭代過程中，一些新特性在實際應用上也會存在穩(wěn)定性、兼容性等方面的問題。我們在研究使用上游技術的同時，也一直積極探索、豐富開源技術功能，幫助提高開源技術穩(wěn)定性。并將產(chǎn)出持續(xù)回饋給社區(qū)，與社區(qū)共同構建一個繁榮的開源生態(tài)。