UCloud外網閘道器是為了承載外網IP、負載均衡等產品的外網出入向流量，當前基於Linux核心的OVS/GRE tunnel/netns/iptables等實現，很好地支撐了現有業務。同時，我們也在不斷跟蹤開源社群的新技術發展，並將之用於下一代外網閘道器的設計。這些新特性可將系統效能和管理能力再提上一檔，滿足未來幾年的需求。在方案設計研發過程中發現，新特性存在不少缺陷和Bug，為此我們向開源社群回饋了10多個patch，並融入到kernel 5.0版本中，幫助完善kernel功能並提升穩定性。
當前業界的多租戶外網閘道器很多都是基於OpenFlow的OpenvSwitch（OVS）方案，然而隨著核心路由轉發功能的不斷完善，利用核心原生路由轉發方式進行設計多租戶外網閘道器係統成為一種可能。在這種方式下能有效的使用傳統iproute2路由工具以及iptables、nftables等Firewall工具，並且隨著SwitchDev技術的興起，未來將閘道器係統遷移到Linux Switch上也成為一種可能。
現有kernel 3.x的不足
當前廣泛使用的核心版本為3.x系列，例如CentOS 7全系列標準支援的核心為3.10版本，Fedora/Ubuntu等Linux發行版也有大量使用。在3.x系列核心下存在著IP tunnel管理複雜、租戶隔離效能損耗等問題。
1. IP tunnel管理複雜
Linux核心建立IP tunnel裝置來建立點對點的隧道連線，建立時需指定tunnel dst和 tunnel key。因為宿主機之間兩兩建立連線，面向宿主機的目的地址眾多，這樣就會導致閘道器節點上需要建立成千上萬的tunnel裝置，在大規模業務環境下，tunnel的管理將變得及其複雜。
2. 多租戶隔離導致的效能下降
a. 公有云需要實現多租戶隔離以確保使用者間的安全和隱私。由於VPC網路下不同租戶的內網地址可以重合，導致路由也有重合的可能性，此時需要通過大量的策略路由去隔離租戶的路由規則，由於策略路由的連結串列屬性，效能會隨著連結串列長度的增加而急劇下降。
b. 由於Firewall和NAT的實現基於同樣鏈式的iptables，效能損耗同樣可觀。
3. netns帶來效能開銷
通過netns實現租戶路由和Firewall規則的隔離，但是netns會引入虛擬網路卡和協議棧重入開銷，使整體效能下降20%左右。
三項核心新技術
為了解決原有方案存在的困擾，我們調研了大量行業主流方案和核心上游的新動向，發現Lightweight tunneling（輕量級隧道，簡稱lwtunnel）、Virtual Routing Forwarding（虛擬路由轉發，簡稱VRF）以及nftable & netfilter flow offload（流解除安裝）三項核心新技術的特性，可以幫助規避原方案存在的缺陷。
1. Lightweight tunneling
Linux核心在4.3版本中引入了輕量級隧道Lightweight tunneling，它提供了通過route方式設定tunnel屬性的方法，這樣可以避免管理大量的tunnel裝置。
建立隧道裝置時指定external模式，利用路由設定的輕量級隧道通過tun裝置傳送報文。
2. Virtual Routing Forwarding
Linux核心在4.3版本中引入了VRF的初步支援，並在4.8版本形成完備版本。Virtual Routing Forwarding虛擬路由轉發，可以將一臺Linux Box的物理路由器當多臺虛擬路由器使用，能很好的解決租戶路由隔離問題，避免直接使用策略路由。因此，可以將不同租戶的網路卡加入租戶所屬的虛擬路由器中來實現多租戶的虛擬路由。
3. flow offload
Nftables是一種新的資料包分類框架，旨在替代現存的{ip,ip6,arp,eb}_tables。在nftables中，大部分工作是在使用者態完成的，核心只知道一些基本指令（過濾是用偽狀態機實現的）。nftables的一個高階特性就是對映，可以使用不同型別的資料並對映它們。例如，我們可以對映iif device到專用的規則集合（之前建立的儲存在一個鏈中）。由於是hash對映的方式，可以完美的避免鏈式規則跳轉的效能開銷。
Linux核心在版本4.16引入了flow offload功能，它為IP forward提供了基於流的解除安裝功能。當一條新建連線完成首回合原方向和反方向的報文時，完成路由，Firewall和NAT工作後，在處理反方向首報文的forward hook，根據報文路由、NAT等資訊建立可解除安裝flow到接收網路卡ingress hook上。後續的報文可以在接收ingress hook上直接轉發，不需要再進入IP stack處理。此外，將來flow offload還將支援hardware offload模式，這將極大提高系統轉發效能。
方案設計與優化實踐
通過對上述三項新技術的研究，我們發現可以嘗試設計一套基於路由的方式，實現多租戶overlay網路的外網閘道器。在方案設計過程中，我們也碰到了諸如lwtunnel和flow offload功能不足，以及VRF和flow offload不能一起有效的工作等問題。最終我們都設法解決了，並針對這些核心的不足提交patch給Linux開源社群。
1. lwtunnel傳送報文tunnel_key丟失
**問題描述：**我們利用lwtunnel路由方式傳送報文時，建立了一個external型別的gretap tunnel，我們將命令設定了id為1000，但是傳送成功報文中沒有tunnel_key欄位。
**問題定位：**我們研究iproute2程式碼，發現由於TUNNEL_KEY flag並沒有開放給使用者態，所以iproute2工具並沒有對lwtunnel路由設定TUNNEL_KEY，導致報文不會建立tunnel_key欄位。
提交patch： 我們給核心和使用者態iproute2分別提交patch來解決這一問題：
iptunnel: make TUNNEL_FLAGS available in uapi
git.kernel.org/pub/scm/lin…? id=1875a9ab01dfa96b06cb6649cb1ce56efa86c7cb
iproute: Set ip/ip6 lwtunnel flags
git.kernel.org/pub/scm/net… 提交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無效
**問題發現：**為了能有效隔離租戶路由，我們給每個租戶建立一個基於tunnel_key的gretap tunnel裝置。如下圖，建立一個tunnel_key 1000的gretap tunnel裝置，把tunnel裝置加入租戶所屬VRF，tunnel裝置能有效地接收報文，但並不能傳送報文。
問題定位：研究核心發現，IP tunnel在非external模式下即使指定了輕量級隧道路由，傳送報文也沒有使用它，導致報文路由錯誤被丟棄。
提交patch：
ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel
git.kernel.org/pub/scm/lin… 提交patch後，在未指定tunnel_dst的非external模式IP tunnel下，能使用輕量級隧道路由進行傳送報文。
3. external IP tunnel ARP無法正常執行
**問題描述：**鄰居IP tunnel進行了ARP請求，但是本端的ARP迴應報文的隧道頭中並沒帶tunnel_key欄位。
**問題定位：**研究程式碼發現，tunnel收到了對端的ARP 請求，在傳送報文ARP回覆的時候會複製請求報文的tunnel資訊，但是遺漏了所有tun_flags。
提交patch：
iptunnel: Set tun_flags in the iptunnel_metadata_reply from src
4. Flow offload不能與DNAT有效工作
**問題描述：**Firewall建立規則從eth0收到目的地址2.2.2.11的報文，DNAT為10.0.0.7， flow offload無法工作。
**問題定位：**分析發現，客戶端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去獲取，而是應該根據10.0.0.7這個值去獲取
addr = ct->tuplehash[dir].tuple.src.u3.ip
提交patch：
netfilter: nft_flow_offload: Fix reverse route lookup
git.kernel.org/pub/scm/lin… 5. Flow offload不能與VRF有效工作
問題描述： 將網路卡eth0和eth1加入VFR後，flow offload不起作用。
**問題定位：**檢視程式碼發現，原方向和反方向首報文進入協議堆疊後skb->dev會設定為vrf device user1，建立flow offload規則的iif就是user1。但是offload規則下發在eth0和eth1的ingress hook上，所以後續報文在eth0和eth1的ingress hook上不能匹配flow規則。
提交patch：
netfilter: nft_flow_offload: fix interaction with vrf slave device
git.kernel.org/pub/scm/lin… 最終，我們根據兩個方向查詢路由的結果，設定flow offload規則的iif和oif資訊來解決此問題。
6. VRF PREROUTING hook重入問題
**問題描述：**配置網路卡加入VRF，firewall ingress方向規則為接收目的地址2.2.2.11 、TCP 目的埠22的報文，egress方向規則為丟棄TCP 目的埠 22的報文。出現異常結果: 收到目的地址2.2.2.11 TCP 22目的埠的報文卻被丟棄。
**問題定位：**研究發現網路卡加入VRF後收到的報文會兩次進入PREROUTING hook，因為在進入IP stack時會進第一次PREROUTING hook，然後被VRF裝置接管後會再次進入PREROUTING hook。上述規則第一次在rule-1000-ingress chain中dst nat為10.0.0.7，第二次由於報文被DNAT後會錯誤的進入rule-1000-egress，導致報文被丟棄。
**提交patch：**我們給核心加了一個支援判斷網路卡型別的match專案，讓使用者態避免可知的第二次無效重入，核心態和使用者態nftables分別提交了如下的patch：
netfilter: nft_meta: Add NFT_META_I/OIFKIND meta type
git.kernel.org/pub/scm/lin… meta: add iifkind and oifkind support
git.netfilter.org/nftables/co…
使用方法:
nft add rule firewall rules-all meta iifkind "vrf" counter accept
原型驗證
最終，我們成功地利用lwtunnel、VRF和flow offload實現多租戶外網閘道器的原型驗證。驗證過程如下：
1. 首先建立原型環境。
a. netns cl模擬外網client, 地址為1.1.1.7，tunnel src 172.168.0.7，配置傳送路由；
b. netns ns1模擬租戶1，內網地址為10.0.0.7，外網地址為 2.2.2.11，tunnel src 172.168.0.11 tunnel_key 1000，配置傳送路由；
c. netns ns2模擬租戶2，內網地址為10.0.0.7，外網地址為 2.2.2.12，tunnel src 172.168.0.12 tunnel_key 2000，配置傳送路由；
d. Host模擬外網閘道器，tunnel src 172.168.0.1，建立租戶VRF user1和use2，建立租戶IP tunnel tun1和tun2，配置轉發路由。
原型環境圖如下：
2. 建立firewall規則：
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埠服務。
待後續hardware offload功能完善以及網路卡廠商支援後，我們會做進一步的開發驗證。
寫在最後
以上是本專案涉及的部分核心問題，這些patch特性都可以在Linux kernel 5.0版本里獲取。我們把這期間為Linux kernel社群貢獻的patch整理成了一份列表，希望能為開發者提供幫助，讀者可以點選“閱讀原文”閱覽完整patch list。
Linux作為成熟的開源套件，一直是雲廠商使用的主流作業系統，但在技術的更新迭代過程中，一些新特性在實際應用上也會存在穩定性、相容性等方面的問題。我們在研究使用上游技術的同時，也一直積極探索、豐富開源技術功能，幫助提高開源技術穩定性。並將產出持續回饋給社群，與社群共同構建一個繁榮的開源生態。