很多網路上的文章都為讀者介紹DR和TUN的工作方式類似，要麼就是直接講解DR模式和TUN模式的安裝配置方式，然後總結兩種模式類似。那為什麼有了DR模式後還需要TUN模式呢？為什麼ipvsadmin針對兩種模式的配置引數不一樣呢？

實際上LVS-DR模式和LVS-TUN模式的工作原理完全不一樣，工作場景完全不一樣。DR基於資料報文重寫，TUN模式基於IP隧道，後者是對資料報文的重新封裝。下面我們就來講解一下LVS-TUN模式的工作原理。

首先要介紹一個概念：IP隧道。將一個完整的IP報文封裝成另一個新的IP報文的資料部分，並通過路由器傳送到指定的地點。在這個過程中路由器並不在意被封裝的原始協議的內容。到達目的地點後，由目的地方依靠自己的計算能力和對IP隧道協議的支援，開啟封裝協議，取得原始協議。如下圖：

可以說隧道協議就是為了解決跨子網傳輸準備的，在生產環境中由於業務需要、技術需要或者安全需要，可能使用交換機進行VLAN隔離（即形成若干個虛擬的獨立的區域網），我們可能需要LVS節點在區域網A，而需要進行負載的多臺MySQL讀伺服器可能在區域網B中。這個時候，我們就要配置LVS的隧道方式。LVS-TUN模式如下圖所示（注意，目標節點要能夠解開隧道協議，好訊息是linux支援IPIP隧道協議）：

上圖中的線優點多，您只需要關注關心“有箭頭”的虛線就可以了。

1. 一旦LVS節點發現來目標為192.168.100.10 VIP的請求，就會使用IP隧道協議對這個請求報文進行封裝。而不是像LVS-DR模式重寫資料報文的MAC資訊。如果配置了多個Real Server，那麼LVS會使用設定的排程演算法確定一個Real Server（這裡為了簡單，就只畫了一個Real Server節點）；

2. 重新封裝後的IPIP隧道協議報文會重新被回發到路由器，路由器（或三層交換機）會根據設定的LVAN對映情況，找到目標伺服器，並將這個IPIP隧道報文傳送過去；

3. Real Server收到這個IP隧道報文後，會將這個報文進行解包。這裡注意一下，一般情況下IPIP隧道報文會進行分片，就如同IP報文分片一樣，只是為了講解方便，我們假定這個報文不需要分片。解壓後得到的資料報文就是原來發送給VIP的請求報文；

4. Real Server設定的迴環IP，讓Real Server認為原始的請求報文是從自己本地的某個應用程式發出的，完成原始報文的校驗後，它會對這個報文進行處理。剩下的過程就和LVS-DR相同了，這裡就不再進行復述了。

可以說LVS-TUN方式基本上具有LVS-DR的優點。在此基礎上又支援跨子網間穿透。這樣的方案能夠給我們架構師足夠的系統設計場景。