基于OpenWRT實現路由多口接入同一網絡及相關應用

DOI：10.19850/j.cnki.2096-4706.2021.09.015

摘? 要：Multi-WAN是一種合并多條WAN鏈路為一條邏輯鏈路，并由多個終端共享的路由技術，它是在以較低成本滿足高質量網絡需求的情境下應運而生的。但由于路由器工作原理的限制，該技術與多個DHCP客戶端WAN接口連接到同一局域網的配置不兼容。有鑒于此，嘗試在不改變內核工作方式的前提下基于OpenWRT系統尋找一種方案，以在多個DHCP協議WAN正常工作的基礎上實現負載均衡和故障轉移。

關鍵詞：路由器;負載均衡;Multi-WAN;故障轉移;DHCP;局域網;OpenWRT

中圖分類號：TP393? ? ? 文獻標識碼：A 文章編號：2096-4706（2021）09-0053-05

Implementation of Routing Multiple Ports to Access the Same Network and?Related Applications Based on OpenWRT

WU Yuqi

（Jincheng College of Sichuan University，Chengdu? 611731，China）

Abstract：Multi-WAN is a routing technology that combines multiple WAN links into one logical link and is shared by multiple terminals. It comes into being in the situation of meeting high-quality network demand at a lower cost. However，due to the limitation of the working principle of the router，this technology is incompatible with the configuration of multiple DHCP client WAN interfaces connected to the same LAN. In view of this，under the premise of no changing the working way of the kernel，this paper attempts to find a solution based on the OpenWRT system，so as to realize load balancing and failover on the basis of the normal operation of multiple DHCP protocol WAN.

Keywords：router;load balancing;Multi-WAN;failover;DHCP;LAN;OpenWRT

0? 引? 言

相較于傳統路由器多個內部終端共享一個網絡出口的工作方式，Multi-WAN路由器提供“多對多”，即多個內部終端共享多個網絡出口的工作方式。與傳統路由技術相比，Multi-WAN技術并不是一種標準的網絡技術，而是一種由需求催生出來的實現策略，在其基礎上可實現提高網絡可靠性、增大網絡總帶寬等優(yōu)勢特性。目前對于該技術的用例不算多，且大多都是使用PPPOE撥號接入不同網絡，而在特殊的情形下則會遇到一些問題，其一就在于路由器普遍不支持多個接口都作為DHCP客戶端連接到同一網絡的配置，更不用談實現負載均衡或故障轉移。須指出協議本身并不是關鍵，而是多WAN口接入同一網絡的行為不被支持。如使用dhclient來提供DHCP客戶端協議支持的系統就會出現協議通訊行為異常。得益于開源系統的可操作性，本文將以OpenWRT開源路由系統就該問題進行探究。

1? 概念解釋及技術原理概述

1.1? Iptables

Iptables是一個命令行工具，用來操控Linux系統的網絡防火墻，即數據包處理模塊netfilter。以一個數據包為單位，可以對其進行接受（Accept）、拒絕（Reject）、丟棄（Drop）、源地址/目標地址轉換（SNAT、DNAT）等操作。為了對滿足不同條件的不同數據包進行不同操作這一目的，需要根據指定的匹配條件來嘗試匹配每個被指派了該規(guī)則的數據包，若成功匹配則對其進行規(guī)則所要求的操作。這種匹配條件對應某種操作的形式被稱為規(guī)則。按照功能對各種規(guī)則進行分類，一類規(guī)則被劃分為一個表，不同類的規(guī)則被分在不同表中，表是規(guī)則的集合。Iptables中有filter、nat等表，本文不會涉及表的原理，故僅提及。一個數據包通過不同來源，甚至設備本身產生而進入到內核中后，都會經過多個不同的處理關卡，而在不同的關卡只能對其匹配特定的表中的規(guī)則。每個關卡都能指定具有先后順序的多個規(guī)則，所以很形象地，將這樣的關卡稱為“鏈”。圖1中的Prerouting、Forward等就是上文所提到的“鏈”?！版湣钡墓ぷ骶褪窃跀祿幚砹鞒讨?，在特定的位置來嘗試對數據包匹配給定的一系列規(guī)則并執(zhí)行對應操作。

1.2? MWAN

MWAN是OpenWRT項目中提供的一個軟件包，支持對高達250個網絡接口的負載均衡以及故障轉移等。MWAN的工作以每個網絡接口為基本單位，它為每個接口創(chuàng)建路由表、Iptables規(guī)則。MWAN對數據包的工作分為兩個基本部分，即數據包標記以及路由策略選擇。MWAN首先有自己的一套程序來對傳入的數據包進行標記（鑒于可能被傳入已經被標記過的數據包等各種情形，要保證正確處理數據包），該過程依賴于Iptablesmwan3_hook。Iptables僅負責按照配置標記數據包，剩下的路由選擇部分由策略路由Iprules完成。比如兩個權重被配置為1：1的WAN接口，MWAN調用iptables mode random probability模塊，使得有一半的數據包被打上0x100/0xff00標記，另一半數據包被打上0x200/0xff00標記。這些數據包在進行路由選擇時便會被均勻地分配給指定的WAN出口。MWAN另具備基于循環(huán)ping測試的鏈路連通性測試，并在一個WAN口下線時將其排除出可分配WAN口列表，以實現故障轉移。此外，MWAN還可以設置基于傳輸協議（TCP/UDP）、數據包源IP、目的IP、源端口、目的端口等的特定路由規(guī)則。MWAN策略均衡的一個典型應用是在應用了HTTPS協議的網頁訪問中，不同的源IP顯然不符合HTTPS協議要求而使得網頁不能被正確訪問，故可以對TCP協議的443端口開啟粘滯模式，即對于一個HTTPS協議的網頁訪問請求，在接下來的一定時間內，都分配同一個WAN出口。

2? 存在的問題

2.1? 問題概述

小型網吧網絡可以成為Multi-WAN技術的典型用例。我們既不希望花費過多資金來向ISP申請更高的帶寬，也不希望通過高成本來保證網絡的穩(wěn)定性。而Multi-WAN既可以做到合并多個運營商的相對帶寬較小的出口，也可以提供故障轉移，保證只要不是所有鏈路都斷開，總會有邏輯上的一個可用網絡出口。這樣的配置一般不會遇到問題，因為一般情況下撥號使用PPPOE協議，并且往往是不同運營商分配的IP地址自然在不同網絡下，并且即使是對于同一個運營商，其多次分配的多個IP也不一定會在一個網絡內。而若是多個WAN都被連接到同一局域網且被配置為DHCP客戶端，則不但Multi-WAN會失效，并且很可能會導致一段時間后（與DHCP服務器設定的租期有關），一條可用的網絡都沒有。

2.2? 問題現象

要復現問題的現象，首先需要配置多WAN口。一般來講路由器只有一個WAN口，但得益于OpenWRT的交換機配置功能，可以手動將一個默認為LAN接口指定為WAN口。配置完成后，前往接口設置頁，在剛配置好的邏輯設備上添加新的接口。通常來講，如果默認的WAN口邏輯設備名為eth0.2，則新添加的WAN口會被自動命名為eth0.3。將默認WAN口和新添加的WAN口都設為DHCP客戶端，添加進WAN防火墻區(qū)域以使之具有普遍的數據包攔截和轉發(fā)規(guī)則，并賦予兩個WAN口不同的躍點數以確保負載均衡可正常工作。接口配置完成后，先將兩個接口禁用，待接入同一局域網后，再啟用兩個網絡。此時由于是首次協商地址，兩個WAN接口遵循DHCP工作流程掃描DHCP服務器并發(fā)送Discover、收到Offer、發(fā)送Request、收到Ack，會正確取得IP地址并可以正常訪問網絡。但在一段時間后，會有一個WAN口無法正常與網關通信。

3? 原因分析

現象本身為正常工作的兩個WAN一段時間后就必然有一個WAN口無法通信，故初次遇到問題時難以查明原因，只基本猜測這樣的網絡配置導致了續(xù)租問題。為了驗證猜測，嘗試將兩個路由器分別接入前述局域網（這兩個路由器的LAN都配置了DHCP服務端并分別在不同的網段），再用另一路由器分別接入以上兩個路由器并進行負載均衡，這一嘗試得到了有效的結果，網絡正常工作，猜測的方向應當是正確的。結合多次嘗試發(fā)現每次異常時間基本在啟用兩個接口后30分鐘，剛好是租期1小時的一半，即第一次續(xù)租時間的現象，猜測異?，F象與DHCP協議的續(xù)租動作有關?；氐絾温酚啥郬AN的方案，使用以下Iptables命令嘗試截獲UDP68端口通信并Log到日志，發(fā)現沒有任何有關DHCP通信的記錄：

iptables -t filter -A INPUT -p udp --dport 68 -j LOG --log-prefix " DHCP com detected： "

兩個WAN中有一個續(xù)租成功，但日志中卻什么都沒有截獲。再次查詢相關Manual后注意到，多數Linux系統中DHCP客戶端使用Rawsocket，通信不被Netfilter框架處理，而這很可能就是上述測試所遇到的情況。而由于續(xù)租成功證明了存在DHCP通信，則很可能只是協議通信的內容存在問題。至此明確了兩個方向：其一，不論使用什么方法解決問題，只能從內核或內核的依賴上嘗試，傳統的通過Netfilter框架修改數據包的方案從原理上不可行;其二，截獲通信的工具需要改變，且不能對Netfilter有依賴，即要盡量靠近底層。執(zhí)行以下命令使用Tcpdump工具來分別截獲兩個WAN接口上UDP 67、68端口所有通信，得到兩個不為空的Dump文件：

tcpdump -i eth0.2 -s 0 -w /tmp/dhcpwan1.pcap 'udp and port 67 and port 68'

tcpdump -i eth0.3 -s 0 -w /tmp/dhcpwan2.pcap 'udp and port 67 and port 68'使用Wireshark工具對dhcpwan1.pcap進行分析，發(fā)現如圖2、圖3所示的現象（下文中將兩個WAN口分別命名為WAN1和WAN2，其中WAN1、WAN2的Metrics分別為5、10，網關IP為100.71.64.1）。

即WAN2口的續(xù)租Request實際上由WAN1發(fā)出，導致DHCP服務端和客戶端的協商過程出錯，脫離了DHCP協議預期的工作方式從而導致續(xù)租失敗。

再對dhcpwan2.pcap分析，可以觀察到WAN2的行為更為異常：自從首次注冊后，就再也沒有成功續(xù)租過，使得其每次到最后都是廣播Discover來嘗試重新獲得租約。

至此，故障原因已經比較清晰。至于為何WAN2的續(xù)租Request會從WAN1口發(fā)出，這與路由內核工作原理有關：首先DHCP協議的通信不受netfilter管理，自然也不能被Iptables控制，而整個工作基礎建立在Iptables上hook的MWAN自然也無法管理DHCP協議。這也就意味著DHCP協商過程嚴格遵循主路由表，不會被負載均衡或策略均衡管理。因此在進行路由選擇時，路由器會查詢路由表并選擇一條最優(yōu)線路發(fā)送數據包?？紤]續(xù)租時的情況，此時路由表中有兩項，分別表示兩個WAN口都可以連通到同一個網絡，而路由器總選擇較小躍點數的WAN口發(fā)包。簡而言之，這導致了只要是目的為上級網絡且不受MWAN管理的包，都不會經由WAN2發(fā)出。

4? 解決方法

了解問題背后的原因并結合上述的基本思路，考慮到修改路由內核工作方式難度過大，且很可能會導致各種不可預料的問題，而路由表作為內核路由選擇的依賴項就是一個很好的嘗試對象。在對OpenWRT系統的DHCP協議部分進行了解后，注意到其行為與接口狀態(tài)有關，如啟用接口、禁用接口會調用DHCP的一些方法，而DHCP會在Discover、Request、Renew等情形調用一個腳本文件并傳入執(zhí)行的動作類型和執(zhí)行該動作的接口名，而這個腳本文件是可以自定義內容的，于是在該腳本文件上可進行解決問題的嘗試。在OpenWRT的路由表中，可以添加對于特定主機IP的靜態(tài)路由表項，其優(yōu)先級高于其他路由表項。綜上，一個可能的解決方案是在續(xù)租操作實施前在路由表中添加一個項，表示目的IP為網關IP的包應通過將要執(zhí)行續(xù)租動作的接口發(fā)送，并在續(xù)租動作結束后移除該路由表項。

于是在被DHCP調用的腳本文件中修改被特定行為觸發(fā)的代碼為：

case "$1" in

deconfig）

deconfig_interface

;;

renew|bound）

setup_interface

if [ "$INTERFACE" = "$Int1" ]; then

sh /usr/bin/modifyRT1.sh

fi

if [ "$INTERFACE" = "$Int2" ]; then

sh /usr/bin/modifyRT2.sh

fi

;;

esac

其中"$1"、"$INTERFACE"為父shell傳遞下來的參數，分別代表DHCP協議要求的動作、執(zhí)行該動作的接口名。而"$Int1"、"$Int2"為自定義的變量，聲明于腳本開頭，用于存儲設置的兩個WAN口名稱。即若有Renew行為，則分別對于兩個WAN口調用不同的腳本來暫時修改路由表，使得在進行續(xù)租的時候保證DHCP服務端和客戶端之間通信的秩序。其中modifyRT1.sh腳本大致執(zhí)行以下操作（modifyRT2.sh原理相同，僅改變了接口）：刪除WAN1口到網關的路由表項;sleep二分之一租期后添加WAN1口到網關的路由表項。這樣的順序可能令人費解，因為較順應直覺的順序應是在Renew前添加路由表項，在Renew后將其刪除，但這是不可行的。首先是因為Renew動作直接由Kernel的可執(zhí)行程序實現，無法做到在Renew前調用腳本，即每次都只能是在Renew后執(zhí)行自定義內容。另也不能按照上述理想順序完成對路由表的修改，如在添加路由表項后等待續(xù)租完成再移除路由表項，具體原因涉及DHCP客戶端服務的守護進程netifd以及shell腳本的工作方式，即上一次Renew后被調用的腳本在執(zhí)行完之前，下一次的Renew不會發(fā)生。此處選擇簡易的匹配接口名來調用寫定的腳本的方式僅為了便于說明，應用中可以修改腳本使得其適用于任意多且任意名稱的接口。在完成對腳本的修改后，重啟路由，兩個WAN口網絡通信正常。上述僅提供一種實現策略，并不符合規(guī)范，需謹慎并結合實際地應用。如圖4所示，修改被DHCP調用的腳本本質上使得路由表、DHCP協議行為有了從左到右的變化。

至此，兩個或兩個以上WAN可以同時作為DHCP客戶端在同一子網內正常工作。

5? 負載均衡及故障轉移

以上步驟僅僅實現了多DHCP協議WAN接口在同一子網下接口協議的正常行為，但若不進行負載均衡，發(fā)往外部的數據包就會嚴格遵循主路由表（主路由表指相對MWAN新創(chuàng)建的路由表而言原有的路由表），即所有流量都不會通過躍點數較大的WAN2。此時要對兩個或多個WAN口進行負載均衡，對/etc/config/mwan3配置文件進行配置：

config member 'wan1'

option interface 'wan'

option metric '1'

option weight '1'

以上格式添加參與負載均衡的接口成員，成員指定了一個WAN接口、躍點數、權重。此處對負載均衡有明顯影響的是權重比。多個成員的權重比決定了各個接口在負載均衡中承擔的流量比重。此外，MWAN還可對成員綁定的接口進行基于循環(huán)Ping的可用性追蹤，可選的option有track_method、interval、count等，它們共同確定了判定一個接口不具備連通性的標準。MWAN會自動將流量只負載于策略內的在線成員接口上，這也就實現了故障轉移：

config policy 'balanced'

list use_member 'wan1'

list use_member 'wan2'

option last_resort 'default'

以上格式添加均衡策略。策略指定了使用哪些成員來進行負載均衡，以及當該策略成員都離線時的處理方式。示例添加了兩個WAN成員，并且當兩個WAN成員都掉線時根據主路由表進行路由選擇。此外還可以選擇丟棄或拒絕作為一個策略中成員都離線時對數據包的處理方式：

config rule 'default_rule'

option dest_ip '0.0.0.0/0'

option use_policy 'balanced'

以上格式定義了一個默認規(guī)則，即對于所有出口流量都均勻分配（在balanced策略所選定的成員內，再按照各個成員配置的權重進行分配）。至此，實現一般的對于多WAN的負載均衡。但僅默認規(guī)則一定是不夠的，正如前文介紹MWAN特性時所提到的，用戶需要設置針對HTTPS協議的特殊規(guī)則，使對于一個HTTPS服務器在一段時間內的訪問被分配至同一WAN出口以確保正常訪問使用該協議的網頁：

config rule 'https'

option sticky '1'

option dest_port '443'

option proto 'tcp'

option use_policy 'balanced'

此外，對于潛在的如一條鏈路穩(wěn)定性要弱于另一鏈路且終端有較強的網絡穩(wěn)定性要求（如游戲、實時視頻通話等常用的UDP通訊）的情況，可以針對創(chuàng)建只使用穩(wěn)定鏈路的策略，并匹配例如所有UDP流量給該策略，以確保網絡穩(wěn)定性。又如一些采用HTTPS協議進行但又不每次查驗源IP一致性的下載場景，也可以單獨設置規(guī)則使得對類似下載場景生效負載均衡。規(guī)則具有先后順序，故為了保證所有規(guī)則如預期生效，將具有特殊性的規(guī)則放置于具有普遍性的規(guī)則之前。至此，配置的Multi-WAN負載均衡也具備了一定應對特殊情況的能力，可以滿足基本應用。

6? 結? 論

對于路由多WAN作DHCP客戶端接入同一網絡后，WAN口之間的兼容性問題，提出通過在DHCP協議工作流程中嵌入對路由表的動態(tài)修改從而達到DHCP協議的客戶端、服務端正常溝通的目的，并對于使用該方法的路由器成功進行負載均衡和故障轉移的配置，證明了方法的可行性以及其與獨立第三方組件的兼容性?？紤]到系統為多道程序環(huán)境，可以預見該方法還可以通過進程同步來提高應對極端情況的能力，以同時維持更多的WAN口正常工作。

參考文獻

[1] 李俊灝.基于OpenWRT的多WAN口路由器 [J].科技信息，2014（5）：83+187.

[2] 董宇.多WAN口路由器在網絡中的應用 [J].東方企業(yè)文化，2012（10）：254.

[3] 王莉.Linux下的防火墻技術研究 [J].中國新技術新產品，2020（19）：38-39.

[4] 劉旭光.服務器群負載均衡的實現 [J].數字技術與應用，2014（2）：98.

[5] 曹哲康.基于OpenWRT系統的區(qū)域負載均衡關鍵技術研究與應用 [D].鄭州：鄭州大學，2018.

作者簡介：吳宇琦（1999—），男，漢族，四川宜賓人，本科在讀，研究方向：軟件工程。

收稿日期：2021-04-11