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

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

當前業(yè)界的多租戶外網(wǎng)網(wǎng)關(guān)很多都是基于OpenFlow的OpenvSwitch(OVS)方案，然而隨著內(nèi)核路由轉(zhuǎn)發(fā)功能的不斷完善，利用內(nèi)核原生路由轉(zhuǎn)發(fā)方式進行設(shè)計多租戶外網(wǎng)網(wǎng)關(guān)系統(tǒng)成為一種可能。在這種方式下能有效的使用傳統(tǒng)iproute2路由工具以及iptables、nftables等Firewall工具，并且隨著SwitchDev技術(shù)的興起，未來將網(wǎng)關(guān)系統(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管理復(fù)雜、租戶隔離性能損耗等問題。

1. IP tunnel管理復(fù)雜

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

2. 多租戶隔離導(dǎo)致的性能下降

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

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

3. netns帶來性能開銷

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

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

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

1. Lightweight tunneling

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

創(chuàng)建隧道設(shè)備時指定external模式，利用路由設(shè)置的輕量級隧道通過tun設(shè)備發(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ā)性能。

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

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

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

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

問題定位：我們研究iproute2代碼，發(fā)現(xiàn)由于TUNNEL_KEY flag并沒有開放給用戶態(tài)，所以iproute2工具并沒有對lwtunnel路由設(shè)置TUNNEL_KEY，導(dǎo)致報文不會創(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后，可以通過以下方式設(shè)置路由。

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設(shè)備。如下圖，創(chuàng)建一個tunnel_key 1000的gretap tunnel設(shè)備，把tunnel設(shè)備加入租戶所屬VRF，tunnel設(shè)備能有效地接收報文，但并不能發(fā)送報文。

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

提交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回應(yīng)報文的隧道頭中并沒帶tunnel_key字段。

問題定位：研究代碼發(fā)現(xiàn)，tunnel收到了對端的ARP 請求，在發(fā)送報文ARP回復(fù)的時候會復(fù)制請求報文的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過，真正的路由不應(yīng)該通過2.2.2.7去獲取，而是應(yīng)該根據(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會設(shè)置為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ù)兩個方向查找路由的結(jié)果，設(shè)置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)異常結(jié)果: 收到目的地址2.2.2.11 TCP 22目的端口的報文卻被丟棄。

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

提交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)關(guān)的原型驗證。驗證過程如下：

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)關(guān)，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設(shè)備上支持flow offload。

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

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

寫在最后

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

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=wenxu%40ucloud.cn地址閱覽完整patch list。

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

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。