tun設備的妙用-VPN篇

大家好,我是二哥。

疫情期間,二哥在家遠程工作了。因為每天都要通過VPN訪問公司內部服務,二哥想起來,何不給大家介紹下VPN的工作原理呢?VPN協議有很多個,最典型的有IPSec和OpenVPN,這里二哥只聊OpenVPN。

通常我們在自己電腦上打開OpenVPN client,輸入賬號密碼進行認證,成功連上服務器之后,就可以像身處辦公室一樣訪問內部服務了。比如:

• 打開瀏覽器可以訪問JIRA。
• 打開terminal可以用git提交代碼。
• 通過proxy可以訪問谷歌等服務。

老鐵們想過這一切背后發生了什么嗎?來吧,進入正題。

tun設備

我們一定見過了令人眼花繚亂的各種網絡設備,有物理網卡,也有如veth和bridge這樣的虛擬設備,現在又來了一個tun設備。

tun設備是什么呢?簡單來說,它是一個虛擬網卡,但它被創建出來的目的主要是為了隧道(tunneling)用,這也正是tun名字的由來。

tun設備和我們之前聊過的eth不一樣的是:它一端連著協議棧,另一端連著打開它的用戶態應用程序。如圖1所示,發往tun0的數據被轉發到了VPN程序,而普通的eth0設備則將會將其送往這個網卡所連著的另一個設備。

圖 1:tun設備和eth設備對比示意圖

現在我們大概能猜得出:使用 tun設備的目的,其實是為了把來自協議棧的數據包,先交給某個打開了/dev/net/tun字符設備的用戶進程處理。然后它再把處理過后的數據包重新發回到協議棧中。

下面這段話摘抄自網絡上,我覺得是對物理網卡和虛擬網卡的一個很好的概括總結。時間久遠,我也不記得原出處是哪里了:

對于一個網絡設備來說,它就像一個管道(pipe)一樣有兩端:從其中任意一端收到的數據將從另一端發送出去。比如一個物理網卡eth0,它的兩端分別是內核協議棧和外面的物理網絡。從物理網絡收到的數據,會轉發給內核協議棧,而從協議棧發過來的數據將會通過它發送給物理網絡。那么對于一個虛擬網絡設備呢?首先它也歸內核的網絡設備子系統管理,對于Linux內核網絡設備管理模塊來說,虛擬設備和物理設備沒有區別,都是網絡設備,都能配置IP,從網絡設備來的數據,都會轉發給協議棧,協議棧過來的數據,也會交由網絡設備發送出去。至于是怎么發送出去的,發到哪里去,那是設備驅動的事情,跟內核就沒關系了,所以說虛擬網絡設備的一端也是協議棧,而另一端是什么取決于虛擬網絡設備的驅動實現。

很顯然,對于tun設備而言,將接收到的數據發往應用層這個動作是在它的驅動層面實現的。代碼位于drivers/net/tun.c。

隧道協議

聊完了tun設備,我們再來看看隧道協議。在文章《當vpc遇到K8s overlay》里,二哥借助劉超在《趣談網絡協議》中所舉的從廣州自駕海南游的一個例子來解釋所謂隧道協議的概念。我把那部分拷貝在這里,省得大家跳轉到那篇里面去查看。

如圖2所示,隧道協議分為三部分:乘客協議、隧道協議和承載協議。

圖 2:隧道協議示意圖

從廣州出發自駕游海南,你的車怎么通過瓊州海峽呢?得用輪渡,其實這就是隧道協議。

在廣州這邊開車是有“協議”的,例如靠右行駛、紅燈停、綠燈行,這個就相當于“被封裝”的乘客協議。海南那面,開車也是同樣的“乘客”協議。

那我的車如何從廣州運到海南呢?這就需要你先遵循開車協議,將車開上輪渡,所有車都關在船艙里面,按照既定的規則排列好,這就是隧道協議。在大海上,你的車是關在船艙里面的,就像在隧道里面一樣,這個時候內部的乘客協議,也即駕駛協議沒啥用處,只需要船遵從外層的承載協議,到達海南就可以了。

在海上坐船航行,也有它的協議,例如要看燈塔、要按航道航行等。這就是外層的承載協議。

到達之后,外部承載協議的任務就結束了,打開船艙,將車開出來,就相當于取下承載協議和隧道協議的頭。接下來,在海南該怎么開車,就怎么開車,還是內部的乘客協議起作用。

去程詳解

好了,如果老鐵堅持看到這里,那么與本文相關的基礎知識你都有了。我們來看看它們是如何應用在VPN當中的。

老規矩,先上一張大圖。圖中左邊是客戶端,運行有OpenVPN client,右邊是服務端,運行有OpenVPN server。

一般情況下,OpenVPN server由企業IT負責運維,在這張圖中,它充當了gateway的作用,一方面它面向OpenVPN client,接收從client過來的請求,另一方面它將請求轉發至企業內部的網絡或者外部服務。這里的外部服務通常是客戶端無法直接訪問的,比如google.com。

圖 3:瀏覽器通過VPN訪問企業內部服務場景

①:假設二哥需要通過瀏覽器訪問https://srv.company.com,它是運行在公司內部的一個服務,IP地址是10.119.210.110。我們知道這樣的請求首先需要DNS的介入。如果你打開本地DNS的配置文件,會發現OpenVPN client已經預先在里面插入了不少A record,當然這些記錄里面與domian相關的IP地址都是私有IP地址。這也就表示瀏覽器其實是在向10.119.210.110發起請求,當然瀏覽器才不關心這些。

②:除了剛才提到的A record,OpenVPN client還會在本機路由表中插入若干條路由信息,路由表項大致如下表所示。我們知道當請求經過協議棧的時候,路由表會決定該請求應該從哪個接口離開,又該去往何處,下一跳在哪里。

# routeDestination     Gateway         Genmask         Flags Metric Ref     Use   Iface10.119.0.0      10.80.25.4      255.255.0.0     UG    0      0        0     tun0default         192.168.0.1     0.0.0.0         U     0      0        0     eth0

③:好了,到這里我們可以猜到這個請求被路由表決定該送往本機設備tun0?；貞浨懊鎡un設備部分所聊部分,當它收到這個包后,會毫不猶豫地直接發往運行于本機的應用程序OpenVPN client。

④:拋去細節不表,vpn client拿到請求數據包后,它干的事情就是將數據加密和封裝。和IPsec VPN不同,OpenVPN利用OpenSSL進行數據加密。如果你不打算看細節的話,可以瀏覽《特洛伊木馬-圖解VXLAN容器網絡通信方案》里所談的VXLAN封裝過程。雖然細節不同,但流程上可做借鑒。

⑤:vpn client接下來需要將加密和封裝好的數據送往vpn server。這一次它是用UDP協議,訪問的是服務端9112端口。

⑥:通過這一番操作,瀏覽器的請求現在以加密的方式在internet上傳輸。理論上如無秘鑰,別人幾乎沒有可能解開這些加密的數據。

⑦⑧:按照常規的數據接收流程,vpn server會正常收到數據。當它用對稱秘鑰解密并拆封數據后,找到原始請求是要訪問10.119.210.110。

⑨:此時它又扮演了反向代理的角色,向內部服務10.119.210.110發起請求。

好了,到此我們詳細看完了客戶端通過VPN向企業內部服務發起請求時所涉及到的具體過程。

回程概述

當vpn server從10.119.210.110拿到了數據后,它按IPsec VPN協議繼續將其加密和封裝并發回給vpn client。

很自然地,vpn client會收到這份數據。那么當它解密、拆封后需要做什么呢?

或許你猜到了,它通過已經打開的/dev/net/tun設備,往tun虛擬網卡寫入解密拆封后的數據?？蛇€記得上一步vpn client是通過讀取tun設備從而得到瀏覽器發出的請求?這里,它通過向tun設備寫入數據來讓瀏覽器得到它想要的回復。

前面提到對于內核和協議棧而言,既然tun設備就是一個網卡,那么當它接收到數據后,就需要完全按照網卡接收數據的流程來處理。至于這分數據是從哪里來的,內核和協議?？刹魂P心。虛擬網卡的詳細接收流程,二哥在文章《看圖寫話:聊聊veth數據流》用一張大圖做過詳細解釋,這里就不贅述了。

我們大致可以想象得出從tun0接收到數據,再次穿過IP層(以及路由表)和傳輸層,并最終達到瀏覽器的場景。

寫完這篇,二哥不禁再次感慨網絡模型分層設計模式的強大之處。分層意味著解耦和可擴展,每一層只需盡好自己的職責并和鄰層打好交道即可,絲毫不需要關心其它層的細節。而分層模式也使得底層可以用更多的方式來為上層提供服務,只要語義不變即可。從瀏覽器發出請求到它接收到服務端的回復,中間其實經歷了這么多事情,而瀏覽器對此一無所知,應用層果然都非常好被欺騙。

下篇預覽

你們看到這篇的題目就肯定猜到了:除了VPN篇,還有其它與tun設備相關的話題。是的,tun在基于flannel實現的K8s Overlay網絡模型中也起到了至關重要的作用。咱們下篇約。

以上就是本文的全部內容。碼字不易,畫圖更難。喜歡本文的話請幫忙轉發或點擊“在看”。您的舉手之勞是對二哥莫大的鼓勵。謝謝!