DOI:10.19850/j.cnki.2096-4706.2021.09.015
摘? 要:Multi-WAN是一種合并多條WAN鏈路為一條邏輯鏈路,并由多個終端共享的路由技術(shù),它是在以較低成本滿足高質(zhì)量網(wǎng)絡(luò)需求的情境下應(yīng)運(yùn)而生的。但由于路由器工作原理的限制,該技術(shù)與多個DHCP客戶端WAN接口連接到同一局域網(wǎng)的配置不兼容。有鑒于此,嘗試在不改變內(nèi)核工作方式的前提下基于OpenWRT系統(tǒng)尋找一種方案,以在多個DHCP協(xié)議WAN正常工作的基礎(chǔ)上實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。
關(guān)鍵詞:路由器;負(fù)載均衡;Multi-WAN;故障轉(zhuǎn)移;DHCP;局域網(wǎng);OpenWRT
中圖分類號:TP393? ? ? 文獻(xiàn)標(biāo)識碼: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? 引? 言
相較于傳統(tǒng)路由器多個內(nèi)部終端共享一個網(wǎng)絡(luò)出口的工作方式,Multi-WAN路由器提供“多對多”,即多個內(nèi)部終端共享多個網(wǎng)絡(luò)出口的工作方式。與傳統(tǒng)路由技術(shù)相比,Multi-WAN技術(shù)并不是一種標(biāo)準(zhǔn)的網(wǎng)絡(luò)技術(shù),而是一種由需求催生出來的實(shí)現(xiàn)策略,在其基礎(chǔ)上可實(shí)現(xiàn)提高網(wǎng)絡(luò)可靠性、增大網(wǎng)絡(luò)總帶寬等優(yōu)勢特性。目前對于該技術(shù)的用例不算多,且大多都是使用PPPOE撥號接入不同網(wǎng)絡(luò),而在特殊的情形下則會遇到一些問題,其一就在于路由器普遍不支持多個接口都作為DHCP客戶端連接到同一網(wǎng)絡(luò)的配置,更不用談實(shí)現(xiàn)負(fù)載均衡或故障轉(zhuǎn)移。須指出協(xié)議本身并不是關(guān)鍵,而是多WAN口接入同一網(wǎng)絡(luò)的行為不被支持。如使用dhclient來提供DHCP客戶端協(xié)議支持的系統(tǒng)就會出現(xiàn)協(xié)議通訊行為異常。得益于開源系統(tǒng)的可操作性,本文將以O(shè)penWRT開源路由系統(tǒng)就該問題進(jìn)行探究。
1? 概念解釋及技術(shù)原理概述
1.1? Iptables
Iptables是一個命令行工具,用來操控Linux系統(tǒng)的網(wǎng)絡(luò)防火墻,即數(shù)據(jù)包處理模塊netfilter。以一個數(shù)據(jù)包為單位,可以對其進(jìn)行接受(Accept)、拒絕(Reject)、丟棄(Drop)、源地址/目標(biāo)地址轉(zhuǎn)換(SNAT、DNAT)等操作。為了對滿足不同條件的不同數(shù)據(jù)包進(jìn)行不同操作這一目的,需要根據(jù)指定的匹配條件來嘗試匹配每個被指派了該規(guī)則的數(shù)據(jù)包,若成功匹配則對其進(jìn)行規(guī)則所要求的操作。這種匹配條件對應(yīng)某種操作的形式被稱為規(guī)則。按照功能對各種規(guī)則進(jìn)行分類,一類規(guī)則被劃分為一個表,不同類的規(guī)則被分在不同表中,表是規(guī)則的集合。Iptables中有filter、nat等表,本文不會涉及表的原理,故僅提及。一個數(shù)據(jù)包通過不同來源,甚至設(shè)備本身產(chǎn)生而進(jìn)入到內(nèi)核中后,都會經(jīng)過多個不同的處理關(guān)卡,而在不同的關(guān)卡只能對其匹配特定的表中的規(guī)則。每個關(guān)卡都能指定具有先后順序的多個規(guī)則,所以很形象地,將這樣的關(guān)卡稱為“鏈”。圖1中的Prerouting、Forward等就是上文所提到的“鏈”?!版湣钡墓ぷ骶褪窃跀?shù)據(jù)包處理流程中,在特定的位置來嘗試對數(shù)據(jù)包匹配給定的一系列規(guī)則并執(zhí)行對應(yīng)操作。
1.2? MWAN
MWAN是OpenWRT項(xiàng)目中提供的一個軟件包,支持對高達(dá)250個網(wǎng)絡(luò)接口的負(fù)載均衡以及故障轉(zhuǎn)移等。MWAN的工作以每個網(wǎng)絡(luò)接口為基本單位,它為每個接口創(chuàng)建路由表、Iptables規(guī)則。MWAN對數(shù)據(jù)包的工作分為兩個基本部分,即數(shù)據(jù)包標(biāo)記以及路由策略選擇。MWAN首先有自己的一套程序來對傳入的數(shù)據(jù)包進(jìn)行標(biāo)記(鑒于可能被傳入已經(jīng)被標(biāo)記過的數(shù)據(jù)包等各種情形,要保證正確處理數(shù)據(jù)包),該過程依賴于Iptablesmwan3_hook。Iptables僅負(fù)責(zé)按照配置標(biāo)記數(shù)據(jù)包,剩下的路由選擇部分由策略路由Iprules完成。比如兩個權(quán)重被配置為1:1的WAN接口,MWAN調(diào)用iptables mode random probability模塊,使得有一半的數(shù)據(jù)包被打上0x100/0xff00標(biāo)記,另一半數(shù)據(jù)包被打上0x200/0xff00標(biāo)記。這些數(shù)據(jù)包在進(jìn)行路由選擇時便會被均勻地分配給指定的WAN出口。MWAN另具備基于循環(huán)ping測試的鏈路連通性測試,并在一個WAN口下線時將其排除出可分配WAN口列表,以實(shí)現(xiàn)故障轉(zhuǎn)移。此外,MWAN還可以設(shè)置基于傳輸協(xié)議(TCP/UDP)、數(shù)據(jù)包源IP、目的IP、源端口、目的端口等的特定路由規(guī)則。MWAN策略均衡的一個典型應(yīng)用是在應(yīng)用了HTTPS協(xié)議的網(wǎng)頁訪問中,不同的源IP顯然不符合HTTPS協(xié)議要求而使得網(wǎng)頁不能被正確訪問,故可以對TCP協(xié)議的443端口開啟粘滯模式,即對于一個HTTPS協(xié)議的網(wǎng)頁訪問請求,在接下來的一定時間內(nèi),都分配同一個WAN出口。
2? 存在的問題
2.1? 問題概述
小型網(wǎng)吧網(wǎng)絡(luò)可以成為Multi-WAN技術(shù)的典型用例。我們既不希望花費(fèi)過多資金來向ISP申請更高的帶寬,也不希望通過高成本來保證網(wǎng)絡(luò)的穩(wěn)定性。而Multi-WAN既可以做到合并多個運(yùn)營商的相對帶寬較小的出口,也可以提供故障轉(zhuǎn)移,保證只要不是所有鏈路都斷開,總會有邏輯上的一個可用網(wǎng)絡(luò)出口。這樣的配置一般不會遇到問題,因?yàn)橐话闱闆r下?lián)芴柺褂肞PPOE協(xié)議,并且往往是不同運(yùn)營商分配的IP地址自然在不同網(wǎng)絡(luò)下,并且即使是對于同一個運(yùn)營商,其多次分配的多個IP也不一定會在一個網(wǎng)絡(luò)內(nèi)。而若是多個WAN都被連接到同一局域網(wǎng)且被配置為DHCP客戶端,則不但Multi-WAN會失效,并且很可能會導(dǎo)致一段時間后(與DHCP服務(wù)器設(shè)定的租期有關(guān)),一條可用的網(wǎng)絡(luò)都沒有。
2.2? 問題現(xiàn)象
要復(fù)現(xiàn)問題的現(xiàn)象,首先需要配置多WAN口。一般來講路由器只有一個WAN口,但得益于OpenWRT的交換機(jī)配置功能,可以手動將一個默認(rèn)為LAN接口指定為WAN口。配置完成后,前往接口設(shè)置頁,在剛配置好的邏輯設(shè)備上添加新的接口。通常來講,如果默認(rèn)的WAN口邏輯設(shè)備名為eth0.2,則新添加的WAN口會被自動命名為eth0.3。將默認(rèn)WAN口和新添加的WAN口都設(shè)為DHCP客戶端,添加進(jìn)WAN防火墻區(qū)域以使之具有普遍的數(shù)據(jù)包攔截和轉(zhuǎn)發(fā)規(guī)則,并賦予兩個WAN口不同的躍點(diǎn)數(shù)以確保負(fù)載均衡可正常工作。接口配置完成后,先將兩個接口禁用,待接入同一局域網(wǎng)后,再啟用兩個網(wǎng)絡(luò)。此時由于是首次協(xié)商地址,兩個WAN接口遵循DHCP工作流程掃描DHCP服務(wù)器并發(fā)送Discover、收到Offer、發(fā)送Request、收到Ack,會正確取得IP地址并可以正常訪問網(wǎng)絡(luò)。但在一段時間后,會有一個WAN口無法正常與網(wǎng)關(guān)通信。
3? 原因分析
現(xiàn)象本身為正常工作的兩個WAN一段時間后就必然有一個WAN口無法通信,故初次遇到問題時難以查明原因,只基本猜測這樣的網(wǎng)絡(luò)配置導(dǎo)致了續(xù)租問題。為了驗(yàn)證猜測,嘗試將兩個路由器分別接入前述局域網(wǎng)(這兩個路由器的LAN都配置了DHCP服務(wù)端并分別在不同的網(wǎng)段),再用另一路由器分別接入以上兩個路由器并進(jìn)行負(fù)載均衡,這一嘗試得到了有效的結(jié)果,網(wǎng)絡(luò)正常工作,猜測的方向應(yīng)當(dāng)是正確的。結(jié)合多次嘗試發(fā)現(xiàn)每次異常時間基本在啟用兩個接口后30分鐘,剛好是租期1小時的一半,即第一次續(xù)租時間的現(xiàn)象,猜測異?,F(xiàn)象與DHCP協(xié)議的續(xù)租動作有關(guān)?;氐絾温酚啥郬AN的方案,使用以下Iptables命令嘗試截獲UDP68端口通信并Log到日志,發(fā)現(xiàn)沒有任何有關(guān)DHCP通信的記錄:
iptables -t filter -A INPUT -p udp --dport 68 -j LOG --log-prefix " DHCP com detected: "
兩個WAN中有一個續(xù)租成功,但日志中卻什么都沒有截獲。再次查詢相關(guān)Manual后注意到,多數(shù)Linux系統(tǒng)中DHCP客戶端使用Rawsocket,通信不被Netfilter框架處理,而這很可能就是上述測試所遇到的情況。而由于續(xù)租成功證明了存在DHCP通信,則很可能只是協(xié)議通信的內(nèi)容存在問題。至此明確了兩個方向:其一,不論使用什么方法解決問題,只能從內(nèi)核或內(nèi)核的依賴上嘗試,傳統(tǒng)的通過Netfilter框架修改數(shù)據(jù)包的方案從原理上不可行;其二,截獲通信的工具需要改變,且不能對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進(jìn)行分析,發(fā)現(xiàn)如圖2、圖3所示的現(xiàn)象(下文中將兩個WAN口分別命名為WAN1和WAN2,其中WAN1、WAN2的Metrics分別為5、10,網(wǎng)關(guān)IP為100.71.64.1)。
即WAN2口的續(xù)租Request實(shí)際上由WAN1發(fā)出,導(dǎo)致DHCP服務(wù)端和客戶端的協(xié)商過程出錯,脫離了DHCP協(xié)議預(yù)期的工作方式從而導(dǎo)致續(xù)租失敗。
再對dhcpwan2.pcap分析,可以觀察到WAN2的行為更為異常:自從首次注冊后,就再也沒有成功續(xù)租過,使得其每次到最后都是廣播Discover來嘗試重新獲得租約。
至此,故障原因已經(jīng)比較清晰。至于為何WAN2的續(xù)租Request會從WAN1口發(fā)出,這與路由內(nèi)核工作原理有關(guān):首先DHCP協(xié)議的通信不受netfilter管理,自然也不能被Iptables控制,而整個工作基礎(chǔ)建立在Iptables上hook的MWAN自然也無法管理DHCP協(xié)議。這也就意味著DHCP協(xié)商過程嚴(yán)格遵循主路由表,不會被負(fù)載均衡或策略均衡管理。因此在進(jìn)行路由選擇時,路由器會查詢路由表并選擇一條最優(yōu)線路發(fā)送數(shù)據(jù)包??紤]續(xù)租時的情況,此時路由表中有兩項(xiàng),分別表示兩個WAN口都可以連通到同一個網(wǎng)絡(luò),而路由器總選擇較小躍點(diǎn)數(shù)的WAN口發(fā)包。簡而言之,這導(dǎo)致了只要是目的為上級網(wǎng)絡(luò)且不受MWAN管理的包,都不會經(jīng)由WAN2發(fā)出。
4? 解決方法
了解問題背后的原因并結(jié)合上述的基本思路,考慮到修改路由內(nèi)核工作方式難度過大,且很可能會導(dǎo)致各種不可預(yù)料的問題,而路由表作為內(nèi)核路由選擇的依賴項(xiàng)就是一個很好的嘗試對象。在對OpenWRT系統(tǒng)的DHCP協(xié)議部分進(jìn)行了解后,注意到其行為與接口狀態(tài)有關(guān),如啟用接口、禁用接口會調(diào)用DHCP的一些方法,而DHCP會在Discover、Request、Renew等情形調(diào)用一個腳本文件并傳入執(zhí)行的動作類型和執(zhí)行該動作的接口名,而這個腳本文件是可以自定義內(nèi)容的,于是在該腳本文件上可進(jìn)行解決問題的嘗試。在OpenWRT的路由表中,可以添加對于特定主機(jī)IP的靜態(tài)路由表項(xiàng),其優(yōu)先級高于其他路由表項(xiàng)。綜上,一個可能的解決方案是在續(xù)租操作實(shí)施前在路由表中添加一個項(xiàng),表示目的IP為網(wǎng)關(guān)IP的包應(yīng)通過將要執(zhí)行續(xù)租動作的接口發(fā)送,并在續(xù)租動作結(jié)束后移除該路由表項(xiàng)。
于是在被DHCP調(diào)用的腳本文件中修改被特定行為觸發(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傳遞下來的參數(shù),分別代表DHCP協(xié)議要求的動作、執(zhí)行該動作的接口名。而"$Int1"、"$Int2"為自定義的變量,聲明于腳本開頭,用于存儲設(shè)置的兩個WAN口名稱。即若有Renew行為,則分別對于兩個WAN口調(diào)用不同的腳本來暫時修改路由表,使得在進(jìn)行續(xù)租的時候保證DHCP服務(wù)端和客戶端之間通信的秩序。其中modifyRT1.sh腳本大致執(zhí)行以下操作(modifyRT2.sh原理相同,僅改變了接口):刪除WAN1口到網(wǎng)關(guān)的路由表項(xiàng);sleep二分之一租期后添加WAN1口到網(wǎng)關(guān)的路由表項(xiàng)。這樣的順序可能令人費(fèi)解,因?yàn)檩^順應(yīng)直覺的順序應(yīng)是在Renew前添加路由表項(xiàng),在Renew后將其刪除,但這是不可行的。首先是因?yàn)镽enew動作直接由Kernel的可執(zhí)行程序?qū)崿F(xiàn),無法做到在Renew前調(diào)用腳本,即每次都只能是在Renew后執(zhí)行自定義內(nèi)容。另也不能按照上述理想順序完成對路由表的修改,如在添加路由表項(xiàng)后等待續(xù)租完成再移除路由表項(xiàng),具體原因涉及DHCP客戶端服務(wù)的守護(hù)進(jìn)程netifd以及shell腳本的工作方式,即上一次Renew后被調(diào)用的腳本在執(zhí)行完之前,下一次的Renew不會發(fā)生。此處選擇簡易的匹配接口名來調(diào)用寫定的腳本的方式僅為了便于說明,應(yīng)用中可以修改腳本使得其適用于任意多且任意名稱的接口。在完成對腳本的修改后,重啟路由,兩個WAN口網(wǎng)絡(luò)通信正常。上述僅提供一種實(shí)現(xiàn)策略,并不符合規(guī)范,需謹(jǐn)慎并結(jié)合實(shí)際地應(yīng)用。如圖4所示,修改被DHCP調(diào)用的腳本本質(zhì)上使得路由表、DHCP協(xié)議行為有了從左到右的變化。
至此,兩個或兩個以上WAN可以同時作為DHCP客戶端在同一子網(wǎng)內(nèi)正常工作。
5? 負(fù)載均衡及故障轉(zhuǎn)移
以上步驟僅僅實(shí)現(xiàn)了多DHCP協(xié)議WAN接口在同一子網(wǎng)下接口協(xié)議的正常行為,但若不進(jìn)行負(fù)載均衡,發(fā)往外部的數(shù)據(jù)包就會嚴(yán)格遵循主路由表(主路由表指相對MWAN新創(chuàng)建的路由表而言原有的路由表),即所有流量都不會通過躍點(diǎn)數(shù)較大的WAN2。此時要對兩個或多個WAN口進(jìn)行負(fù)載均衡,對/etc/config/mwan3配置文件進(jìn)行配置:
config member 'wan1'
option interface 'wan'
option metric '1'
option weight '1'
以上格式添加參與負(fù)載均衡的接口成員,成員指定了一個WAN接口、躍點(diǎn)數(shù)、權(quán)重。此處對負(fù)載均衡有明顯影響的是權(quán)重比。多個成員的權(quán)重比決定了各個接口在負(fù)載均衡中承擔(dān)的流量比重。此外,MWAN還可對成員綁定的接口進(jìn)行基于循環(huán)Ping的可用性追蹤,可選的option有track_method、interval、count等,它們共同確定了判定一個接口不具備連通性的標(biāo)準(zhǔn)。MWAN會自動將流量只負(fù)載于策略內(nèi)的在線成員接口上,這也就實(shí)現(xiàn)了故障轉(zhuǎn)移:
config policy 'balanced'
list use_member 'wan1'
list use_member 'wan2'
option last_resort 'default'
以上格式添加均衡策略。策略指定了使用哪些成員來進(jìn)行負(fù)載均衡,以及當(dāng)該策略成員都離線時的處理方式。示例添加了兩個WAN成員,并且當(dāng)兩個WAN成員都掉線時根據(jù)主路由表進(jìn)行路由選擇。此外還可以選擇丟棄或拒絕作為一個策略中成員都離線時對數(shù)據(jù)包的處理方式:
config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option use_policy 'balanced'
以上格式定義了一個默認(rèn)規(guī)則,即對于所有出口流量都均勻分配(在balanced策略所選定的成員內(nèi),再按照各個成員配置的權(quán)重進(jìn)行分配)。至此,實(shí)現(xiàn)一般的對于多WAN的負(fù)載均衡。但僅默認(rèn)規(guī)則一定是不夠的,正如前文介紹MWAN特性時所提到的,用戶需要設(shè)置針對HTTPS協(xié)議的特殊規(guī)則,使對于一個HTTPS服務(wù)器在一段時間內(nèi)的訪問被分配至同一WAN出口以確保正常訪問使用該協(xié)議的網(wǎng)頁:
config rule 'https'
option sticky '1'
option dest_port '443'
option proto 'tcp'
option use_policy 'balanced'
此外,對于潛在的如一條鏈路穩(wěn)定性要弱于另一鏈路且終端有較強(qiáng)的網(wǎng)絡(luò)穩(wěn)定性要求(如游戲、實(shí)時視頻通話等常用的UDP通訊)的情況,可以針對創(chuàng)建只使用穩(wěn)定鏈路的策略,并匹配例如所有UDP流量給該策略,以確保網(wǎng)絡(luò)穩(wěn)定性。又如一些采用HTTPS協(xié)議進(jìn)行但又不每次查驗(yàn)源IP一致性的下載場景,也可以單獨(dú)設(shè)置規(guī)則使得對類似下載場景生效負(fù)載均衡。規(guī)則具有先后順序,故為了保證所有規(guī)則如預(yù)期生效,將具有特殊性的規(guī)則放置于具有普遍性的規(guī)則之前。至此,配置的Multi-WAN負(fù)載均衡也具備了一定應(yīng)對特殊情況的能力,可以滿足基本應(yīng)用。
6? 結(jié)? 論
對于路由多WAN作DHCP客戶端接入同一網(wǎng)絡(luò)后,WAN口之間的兼容性問題,提出通過在DHCP協(xié)議工作流程中嵌入對路由表的動態(tài)修改從而達(dá)到DHCP協(xié)議的客戶端、服務(wù)端正常溝通的目的,并對于使用該方法的路由器成功進(jìn)行負(fù)載均衡和故障轉(zhuǎn)移的配置,證明了方法的可行性以及其與獨(dú)立第三方組件的兼容性??紤]到系統(tǒng)為多道程序環(huán)境,可以預(yù)見該方法還可以通過進(jìn)程同步來提高應(yīng)對極端情況的能力,以同時維持更多的WAN口正常工作。
參考文獻(xiàn)
[1] 李俊灝.基于OpenWRT的多WAN口路由器 [J].科技信息,2014(5):83+187.
[2] 董宇.多WAN口路由器在網(wǎng)絡(luò)中的應(yīng)用 [J].東方企業(yè)文化,2012(10):254.
[3] 王莉.Linux下的防火墻技術(shù)研究 [J].中國新技術(shù)新產(chǎn)品,2020(19):38-39.
[4] 劉旭光.服務(wù)器群負(fù)載均衡的實(shí)現(xiàn) [J].數(shù)字技術(shù)與應(yīng)用,2014(2):98.
[5] 曹哲康.基于OpenWRT系統(tǒng)的區(qū)域負(fù)載均衡關(guān)鍵技術(shù)研究與應(yīng)用 [D].鄭州:鄭州大學(xué),2018.
作者簡介:吳宇琦(1999—),男,漢族,四川宜賓人,本科在讀,研究方向:軟件工程。
收稿日期:2021-04-11