UCloud外網網關是為了承載外網IP、負載均衡等産品的外網出入向流量，當前基于Linux内核的OVS/GRE tunnel/netns/iptables等實現，很好地支撐了現有業務。
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
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無效
問題發現：為了能有效隔離租戶路由，我們給每個租戶創建一個基于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
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d71b57532d70c03f4671dd04e84157ac6bf021b0
提交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
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7bdca378b2301b1fc6a95c60d6d428408ae4e39e
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
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a799aea0988ea0d1b1f263e996fdad2f6133c680
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
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10f4e765879e514e1ce7f52ed26603047af196e2
最終，我們根據兩個方向查找路由的結果，設置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
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實現多租戶外網網關的原型驗證。驗證過程如下：
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整理成了一份列表，希望能為開發者提供幫助，讀者可以在
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=wenxu%40ucloud.cn地址閱覽完整patch list。
Linux作為成熟的開源套件，一直是雲廠商使用的主流操作系統，但在技術的更新疊代過程中，一些新特性在實際應用上也會存在穩定性、兼容性等方面的問題。我們在研究使用上遊技術的同時，也一直積極探索、豐富開源技術功能，幫助提高開源技術穩定性。并将産出持續回饋給社區，與社區共同構建一個繁榮的開源生态。
免責聲明：本文僅代表作者個人觀點，與每日科技網無關。其原創性以及文中陳述文字和内容未經本站證實，對本文以及其中全部或者部分内容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，并請自行核實相關内容。
本網站有部分内容均轉載自其它媒體，轉載目的在于傳遞更多信息，并不代表本網贊同其觀點和對其真實性負責，若因作品内容、知識産權、版權和其他問題，請及時提供相關證明等材料并與我們聯系，本網站将在規定時間内給予删除等相關處理.
