張入文，羅俊，胡曉勤，龔勛

(四川大學網(wǎng)絡空間安全學院，成都 610065)

0 引言

云計算是一種將云端物理資源以虛擬資源池的方式供租戶使用的模式，在云計算模式下可以通過網(wǎng)絡實現(xiàn)租戶的資源按需分配與獲取[1]。其具有的高可用性、彈性伸縮、便宜性和部署靈活等特點，能在提高人們工作效率的同時，在各個行業(yè)帶創(chuàng)新[2]。云計算模式下，用戶只需要通過網(wǎng)絡向云服務提供商申請并支付相應的費用，即可方便快捷地獲取所需要的計算、存儲等資源，相比于購買并部署昂貴的硬件設備，資源的按需購買更為經(jīng)濟便捷。經(jīng)過多年的發(fā)展，云計算技術(shù)已經(jīng)越來越被人們廣泛使用。

盡管有云計算有眾多優(yōu)勢，但仍存在數(shù)據(jù)丟失、數(shù)據(jù)破壞和流量劫持等方面的安全問題[3]。因此，需要在云環(huán)境下有效的VPN解決方案?？梢酝ㄟ^虛擬專用網(wǎng)絡即服務(VPNaaS)提供與租戶網(wǎng)絡的連接。通過加密可以確保云環(huán)境中敏感信息的數(shù)據(jù)保護和機密性，這可以通過在云中部署VPN服務來實現(xiàn)。傳統(tǒng)意義的VPN主要以硬件為主，將VPN功能集成到特定的專用硬件中，實現(xiàn)軟硬一體的VPN系統(tǒng)[4]，但這樣也存在許多問題，例如：可用性差、不易于擴展、部署困難等。將VPN服務遷移到云環(huán)境中，可以有效解決這些問題，在云環(huán)境下，VPN系統(tǒng)應滿足：組件快速部署；VPN資源的動態(tài)分配與快速擴展，支持多租戶、多VPN實例；租戶VPN系統(tǒng)的相互隔離等諸多要求。

目前國內(nèi)外的研究主要集中在傳統(tǒng)VPN，對云環(huán)境下VPN服務的研究仍然較少，Goethals等人對云上VPN軟件的可伸縮性進行了評估，對VPN軟件是否以及如何應用于包含邊緣節(jié)點的大規(guī)模集群中進行了研究[5]，本文主要研究Kubernetes環(huán)境下的VPN服務的應用；選擇合適的開源VPN，制作VPN鏡像；利用Multus-CNI插件實現(xiàn)Kubernetes的多網(wǎng)絡平面。

1 相關(guān)技術(shù)

1.1 傳統(tǒng)VPN

傳統(tǒng)VPN通常以設備的形式部署在網(wǎng)絡邊界處。VPN的關(guān)鍵技術(shù)包括隧道技術(shù)、密鑰管理技術(shù)、加密技術(shù)和身份認證技術(shù)[6]。其中，隧道技術(shù)是VPN最為關(guān)鍵的一項技術(shù)，其實質(zhì)是在傳輸兩點之間通過相同的隧道協(xié)議建立安全的傳輸信道；加密技術(shù)的主要用于傳輸過程中的信息保護，以防止非授權(quán)用戶獲取真實數(shù)據(jù)；密鑰管理技術(shù)主要用于實現(xiàn)在公用數(shù)據(jù)網(wǎng)上安全地傳遞密鑰而不被竊??；通常在隧道連接開始前還要進行用戶身份認證，保證只有擁有合法身份的用戶能夠通過VPN訪問網(wǎng)絡內(nèi)部資源。

1.2 容器技術(shù)與Kubernetes

容器是一個輕量級的操作系統(tǒng)級別的虛擬化技術(shù)，它允許應用程序在資源隔離的環(huán)境下，運行應用程序及其各種依賴項，通過將應用程序所需的所有必要組件都打包為鏡像，運行在獨立環(huán)境中，相比于虛擬機而言，容器不需要整個操作系統(tǒng)，從而節(jié)省出大量資源，同時容器運行也更加快速，性能更好。此外不需要在虛擬機上安裝配套的軟件環(huán)境，更便于業(yè)務的遷移。

Kubernetes是Google開源的容器集群管理系統(tǒng)，它基于docker技術(shù)，提供資源調(diào)度、部署運行、服務發(fā)現(xiàn)、縮擴容等一整套功能，本質(zhì)上可看做是基于容器技術(shù)的Micro-PaaS平臺，即第三代PaaS的代表性項目[8]。其整體架構(gòu)如圖1所示。

圖1 Kubernetes總體架構(gòu)圖

如圖1所示，Kubernetes的核心組件，主要有以下幾個：

etcd：保存整個集群的各種狀態(tài)信息；

apiserver：提供了資源操作的唯一入口，并提供認證、授權(quán)、訪問控制、API注冊和發(fā)現(xiàn)等機制；

controller manager：負責維護集群的狀態(tài)，例如故障檢測、自動擴展、滾動更新等；

scheduler：負責資源的調(diào)度，按照預定的調(diào)度策略將Pod調(diào)度到相應的機器上；

kubelet：負責維護容器的生命周期，同時也負責Volume(CVI)和網(wǎng)絡(CNI)的管理；

kube-proxy：負責為Service提供cluster內(nèi)部的服務發(fā)現(xiàn)和負載均衡。

為便于理解，下面將對Kubernetes的重要概念進行簡單介紹。

Pod：Pod是Kubernetes中一個抽象化概念，是一組共享資源(包括存儲、網(wǎng)絡等)的容器，Pod內(nèi)的容器在同一個namespace命名空間。master節(jié)點通過controler組件把Pod調(diào)度到合適的node工作節(jié)點上，并與容器運行時協(xié)調(diào)以啟動容器在Kubernetes中，Pod是調(diào)度的最小元素。

Master：集群控制節(jié)點，負責整個集群的管理控制，在master節(jié)點上運行這集群的關(guān)鍵組件，如apiserver、controller manager、scheduler等。Master節(jié)點通常占據(jù)整個服務器，由于master的重要性，高可用方案建議部署3臺服務器以保證整個集群的安全穩(wěn)定。

Node：除了master，集群其他的機器均為node節(jié)點，node是集群的工作負載節(jié)點，由master分配工作負載，其上運行著kubelet、kube-proxy、Docker Engine等關(guān)鍵進程。當某個node宕機時，其上的工作負載會自動轉(zhuǎn)移到其他節(jié)點。

2 K8S環(huán)境下的VPN服務設計

2.1 容器化VPN服務的基本架構(gòu)

Kubernetes網(wǎng)絡被設計為一個扁平化的網(wǎng)絡中，集群外部訪問只能通過以下幾種方式：

(1)通過port-forward轉(zhuǎn)發(fā)，這種方式最為方便快捷，但只適合調(diào)試時使用，不適用于生產(chǎn)環(huán)境。

(2)通過NodePort，NodePort方式為集群中每一個節(jié)點(Node)指定對應的監(jiān)聽端口，通過任意節(jié)點的端口即可訪問到指定服務。

(3)通過LoadBalance來暴露服務，LoadBalance(負載均衡LB)通常由云服務商提供，如果云環(huán)境中不提供LB服務，通常直接使用Ingress，或使用MetalLB來自行配置LB。

(4)通過Ingress公開多個服務，Ingress Controller基于Ingress規(guī)則將客戶端請求直接轉(zhuǎn)發(fā)到Service對應的后端pod上。

這些服務暴露方式使集群內(nèi)部服務可以對外訪問，但這些方式?jīng)]有任何安全驗證機制，且外部網(wǎng)絡中的各類客戶端皆可訪問，對于需要建立可信的安全連接，而又不希望外部網(wǎng)絡隨意訪問的服務，使用VPN服務是非常必要的。

以傳統(tǒng)VPN與常見的開源VPN Strongswan作為參考，將傳統(tǒng)VPN與K8S環(huán)境相結(jié)合，將Strongswan制作為容器鏡像，部署到Kubernetes容器集群，其整體架構(gòu)如圖2所示。

圖2 容器化VPN總體架構(gòu)圖

以三個節(jié)點搭建的Kubernetes集群為例，其中節(jié)點1為master節(jié)點，為集群控制節(jié)點，負責整個集群的管理與控制，是整個集群的核心，在其上通常不運行工作負載，也可以通過特殊命令使其作為工作節(jié)點使用，master節(jié)點上運行著API server、Controller Manager、Scheduler等重要進程。節(jié)點2與節(jié)點3為Node工作節(jié)點，每個Node節(jié)點可運行多個pod，pod是Kubernetes中最基本的單元，其中包含多個與業(yè)務相關(guān)的容器，為Kubernetes調(diào)度的最小單元，VPN服務運行在node節(jié)點，負責容器內(nèi)服務與外部通信。

其中，VPN pod有兩個網(wǎng)絡接口，外部網(wǎng)絡訪問的數(shù)據(jù)由flannel網(wǎng)絡負責轉(zhuǎn)發(fā)，內(nèi)部訪問的數(shù)據(jù)由calico網(wǎng)絡轉(zhuǎn)發(fā)，Kubernetes可以是公有云上由租戶搭建的集群或是異地的數(shù)據(jù)中心，本地數(shù)據(jù)中心采用傳統(tǒng)的方式，在網(wǎng)絡邊界處部署VPN設備，集群中的VPN封裝在容器中，通過kubelet作為pod啟動，IPSec隧道建立在本地網(wǎng)關(guān)與Kubernetes中VPN pod之間，本地中心與Kubernetes集群建立連接時首先通過互聯(lián)網(wǎng)將數(shù)據(jù)發(fā)送到云上彈性公網(wǎng)ip或真實物理ip，master節(jié)點上運行的ingress controller組件負責將數(shù)據(jù)轉(zhuǎn)發(fā)到Node工作節(jié)點上的VPN服務pod上，再通過VPN pod將數(shù)據(jù)轉(zhuǎn)發(fā)到相應的pod，通過在本地數(shù)據(jù)中心的VPN網(wǎng)關(guān)與VPN pod間建立安全隧道，實現(xiàn)對集群內(nèi)部的安全訪問。

2.2 雙網(wǎng)絡平面的實現(xiàn)

由于VPN服務同時需要內(nèi)網(wǎng)與外網(wǎng)網(wǎng)卡，而Kubernetes設計之初，一直遵循One Pod One IP的策略，即一個Pod分配一個網(wǎng)卡，一個IP地址，在這種情況下顯然不滿足要求，為了支持多網(wǎng)絡平面，本文以Multus-CNI為例進行了多網(wǎng)絡平面實踐。目前Kubernetes中最常用的跨主機容器之間的通信組件為flannel與calico，flannel在主機網(wǎng)絡之上創(chuàng)建了覆蓋網(wǎng)絡(overlay網(wǎng)絡)，通過這個覆蓋網(wǎng)絡，將數(shù)據(jù)包原封不動地傳遞到目標容器內(nèi)，calico使用BGP路由協(xié)議配置一個3層網(wǎng)絡在主機之間路由數(shù)據(jù)包。為實現(xiàn)多網(wǎng)絡平面，首先需要在Kubernetes集群中安裝flannel與calico網(wǎng)絡插件，并安裝Multus-CNI插件，通過創(chuàng)建與calico和flannel組件同名的NetworkAttachmentDefinition類型的CRD自定義資源，并注冊到kubernetes的apiserver，創(chuàng)建方式如下：

可以通過kubectl get命令查看自定義資源是否創(chuàng)建成功，在multus的cni讀取目錄下，新建并編寫calico和flannel的cni配置文件，以便multus能獲取到calico和flannel的組件信息，動態(tài)進行網(wǎng)絡的配置。創(chuàng)建pod時可以通過添加annotations參數(shù)選擇默認網(wǎng)絡或創(chuàng)建雙網(wǎng)卡pod。

本文中，以calico網(wǎng)絡作為內(nèi)網(wǎng)網(wǎng)絡，負責Kubernetes內(nèi)部pod與pod，service與pod或各節(jié)點之間的通信，flannel作為外網(wǎng)網(wǎng)絡，負責集群外部數(shù)據(jù)接收后通過VPN Service內(nèi)網(wǎng)網(wǎng)口轉(zhuǎn)發(fā)到集群內(nèi)部通信。多網(wǎng)絡平面下的數(shù)據(jù)流圖如圖3所示。

圖3 集群內(nèi)pod與本地數(shù)據(jù)中心通信的數(shù)據(jù)流圖

通過本地數(shù)據(jù)中心VPN網(wǎng)關(guān)和VPN pod之間建立安全隧道，本地數(shù)據(jù)中心內(nèi)網(wǎng)的服務器與集群內(nèi)pod的通信過程大致如下：

(1)本地數(shù)據(jù)中心內(nèi)網(wǎng)的服務器發(fā)出源IP為本機(內(nèi)網(wǎng)網(wǎng)段)，目的IP為集群內(nèi)pod IP的數(shù)據(jù)包，根據(jù)本機路由策略發(fā)送到本地數(shù)據(jù)中心的VPN網(wǎng)關(guān)。

(2)VPN網(wǎng)關(guān)根據(jù)其目的地址查找相應的VPN安全策略，將數(shù)據(jù)包重新封裝后，發(fā)送到互聯(lián)網(wǎng)。

(3)數(shù)據(jù)包通過公共網(wǎng)絡傳輸?shù)郊旱墓W(wǎng)ip后，由master節(jié)點的ingress組件將數(shù)據(jù)轉(zhuǎn)發(fā)到flannel0設備。

(4)flannel網(wǎng)絡的flannel0根據(jù)存儲在etcd上的網(wǎng)絡配置信息，將數(shù)據(jù)包轉(zhuǎn)發(fā)給VPN pod。

(5)數(shù)據(jù)包到達VPN pod，根據(jù)數(shù)據(jù)包源地址，查找安全策略，對其進行相應的解包工作，并根據(jù)安全策略，由內(nèi)網(wǎng)接接口發(fā)送到calico網(wǎng)絡的canal0設備。

(6)calico網(wǎng)絡根據(jù)其路由規(guī)則，將數(shù)據(jù)包轉(zhuǎn)發(fā)到對應的node節(jié)點的canal0設備。

(7)數(shù)據(jù)包到達pod所在的node節(jié)點，canal0根據(jù)路由規(guī)則將數(shù)據(jù)包發(fā)送到對應的pod，至此，整個通信流程結(jié)束。

創(chuàng)建兩個網(wǎng)絡接口的pod的大致流程如下：

(1)當用戶在Kubernetes的master節(jié)點執(zhí)行pod創(chuàng)建命令后，kublet觀察到新pod的創(chuàng)建，于是首先調(diào)用CRI(容器運行時接口)，創(chuàng)建pod內(nèi)的若干容器，包括pause系統(tǒng)容器和其他用戶容器

(2)首先會創(chuàng)建pause系統(tǒng)容器，它是由Kubernetes系統(tǒng)默認創(chuàng)建的第一個容器，里面運行一個功能簡單的C程序，pause容器一經(jīng)創(chuàng)建即把自己永遠阻塞。這個邏輯簡單的容器主要用于在pod創(chuàng)建過程中完成一系列容器初始化過程，并占用一個Linux的network namespace，不同的pod通過Linux的namespace機制實現(xiàn)隔離功能。

(3)pod內(nèi)的其他容器與系統(tǒng)pause容器共享network namespace，在創(chuàng)建階段加入這個namespace，因此，在CRI調(diào)用容器運行時時，其默認網(wǎng)絡模式都為none模式，不會初始化網(wǎng)絡協(xié)議棧。

(4)在pause創(chuàng)建階段，會通過CNI插件完成容器網(wǎng)絡初始化的過程，包括容器網(wǎng)絡接口創(chuàng)建，IP分配等，CNI有多種實現(xiàn)，官方自帶的插件有p2p、bridge等，一般常用的CNI網(wǎng)絡插件有flannel、calico等，用以解決容器之間跨機通信問題。

(5)Kubelet調(diào)用Multus-CNI插件通過cmdAdd創(chuàng)建容器網(wǎng)絡并根據(jù)pod創(chuàng)建時的annotations參數(shù)，再調(diào)用相關(guān)的第三方網(wǎng)絡插件如calico、weave等完成網(wǎng)絡初始化，從而完成雙網(wǎng)絡接口pod的創(chuàng)建。

3 測試與分析3.1 實驗環(huán)境

本實驗通過一臺本地物理機與兩臺公有云租用的ESC搭建測試如圖4所示的測試環(huán)境，物理機1通過路由器連接至互聯(lián)網(wǎng)，在其上運行三個虛擬機VM1、VM2和VM3，將VM1作為集群的master節(jié)點，VM2和VM3作為工作節(jié)點，搭建了Kubernetes集群，VPN pod通過annotation參數(shù)為flannel和calico的yaml文件，以命令方式創(chuàng)建，具有兩個網(wǎng)絡接口，分別連接至flannel和calico網(wǎng)絡，公有云上租用的ECS1上運行strongswan，創(chuàng)建了兩個網(wǎng)絡接口，ESC2的默認網(wǎng)關(guān)為ECS1，通過云管理平臺對VPC網(wǎng)絡進行配置，物理機1可以通過EIP(彈性公網(wǎng)ip)訪問到ECS1，ECS1的eth1 ip與ECS2 ip處于同一子網(wǎng)，可以直接訪問，容器鏡像選擇strongswan-5.9.0。

圖4 測試環(huán)境網(wǎng)絡拓撲圖

3.2 VPN功能有效性測試

使用ping命令對IPSec VPN功能有效性進行測試，測試結(jié)果為：在創(chuàng)建IPSec隧道前，ECS2與pod1無法通信，創(chuàng)建IPSec隧道后，ECS2與pod1能進行正常通信，能實現(xiàn)VPN功能。

3.3 性能測試

通過ping命令測試VPN的通信延遲，作為對比，分別在IPSec VPN連接建立前，測試物理機1與ECS1的通信延遲與IPSec VPN連接建立成功后，測試pod1與ECS2通信時延，測試結(jié)果如圖5和圖6所示，pod1與ECS2通信時延和物理機1與ECS1通信時延均在40ms左右波動，其中pod1與ECS2的平均時延為：42.3ms，物理機1與ECS1的平均時延為40.1ms，結(jié)果表明，VPN隧道建立后的通信時延與物理機到云端經(jīng)過互聯(lián)網(wǎng)訪問的通信時延相差不大，在可接受的范圍內(nèi)。

圖5 VPN時延測試

圖6 互聯(lián)網(wǎng)連接時延測試

4 結(jié)語

本文針對容器VPN在Kubernetes環(huán)境下的應用進行研究，下一步的研究可以擴展到VPN服務的網(wǎng)絡性能與提升上。