基于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技术并不是一种标准的网络技术，而是一种由需求催生出来的实现策略，在其基础上可实现提高网络可靠性、增大网络总带宽等优势特性。目前对于该技术的用例不算多，且大多都是使用PPPOE拨号接入不同网络，而在特殊的情形下则会遇到一些问题，其一就在于路由器普遍不支持多个接口都作为DHCP客户端连接到同一网络的配置，更不用谈实现负载均衡或故障转移。须指出协议本身并不是关键，而是多WAN口接入同一网络的行为不被支持。如使用dhclient来提供DHCP客户端协议支持的系统就会出现协议通讯行为异常。得益于开源系统的可操作性，本文将以OpenWRT开源路由系统就该问题进行探究。

1  概念解释及技术原理概述

1.1  Iptables

Iptables是一个命令行工具，用来操控Linux系统的网络防火墙，即数据包处理模块netfilter。以一个数据包为单位，可以对其进行接受（Accept）、拒绝（Reject）、丢弃（Drop）、源地址/目标地址转换（SNAT、DNAT）等操作。为了对满足不同条件的不同数据包进行不同操作这一目的，需要根据指定的匹配条件来尝试匹配每个被指派了该规则的数据包，若成功匹配则对其进行规则所要求的操作。这种匹配条件对应某种操作的形式被称为规则。按照功能对各种规则进行分类，一类规则被划分为一个表，不同类的规则被分在不同表中，表是规则的集合。Iptables中有filter、nat等表，本文不会涉及表的原理，故仅提及。一个数据包通过不同来源，甚至设备本身产生而进入到内核中后，都会经过多个不同的处理关卡，而在不同的关卡只能对其匹配特定的表中的规则。每个关卡都能指定具有先后顺序的多个规则，所以很形象地，将这样的关卡称为“链”。图1中的Prerouting、Forward等就是上文所提到的“链”。“链”的工作就是在数据包处理流程中，在特定的位置来尝试对数据包匹配给定的一系列规则并执行对应操作。

1.2  MWAN

MWAN是OpenWRT项目中提供的一个软件包，支持对高达250个网络接口的负载均衡以及故障转移等。MWAN的工作以每个网络接口为基本单位，它为每个接口创建路由表、Iptables规则。MWAN对数据包的工作分为两个基本部分，即数据包标记以及路由策略选择。MWAN首先有自己的一套程序来对传入的数据包进行标记（鉴于可能被传入已经被标记过的数据包等各种情形，要保证正确处理数据包），该过程依赖于Iptablesmwan3_hook。Iptables仅负责按照配置标记数据包，剩下的路由选择部分由策略路由Iprules完成。比如两个权重被配置为1：1的WAN接口，MWAN调用iptables mode random probability模块，使得有一半的数据包被打上0x100/0xff00标记，另一半数据包被打上0x200/0xff00标记。这些数据包在进行路由选择时便会被均匀地分配给指定的WAN出口。MWAN另具备基于循环ping测试的链路连通性测试，并在一个WAN口下线时将其排除出可分配WAN口列表，以实现故障转移。此外，MWAN还可以设置基于传输协议（TCP/UDP）、数据包源IP、目的IP、源端口、目的端口等的特定路由规则。MWAN策略均衡的一个典型应用是在应用了HTTPS协议的网页访问中，不同的源IP显然不符合HTTPS协议要求而使得网页不能被正确访问，故可以对TCP协议的443端口开启粘滞模式，即对于一个HTTPS协议的网页访问请求，在接下来的一定时间内，都分配同一个WAN出口。

2  存在的问题

2.1  问题概述

小型网吧网络可以成为Multi-WAN技术的典型用例。我们既不希望花费过多资金来向ISP申请更高的带宽，也不希望通过高成本来保证网络的稳定性。而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防火墙区域以使之具有普遍的数据包拦截和转发规则，并赋予两个WAN口不同的跃点数以确保负载均衡可正常工作。接口配置完成后，先将两个接口禁用，待接入同一局域网后，再启用两个网络。此时由于是首次协商地址，两个WAN接口遵循DHCP工作流程扫描DHCP服务器并发送Discover、收到Offer、发送Request、收到Ack，会正确取得IP地址并可以正常访问网络。但在一段时间后，会有一个WAN口无法正常与网关通信。

3  原因分析

现象本身为正常工作的两个WAN一段时间后就必然有一个WAN口无法通信，故初次遇到问题时难以查明原因，只基本猜测这样的网络配置导致了续租问题。为了验证猜测，尝试将两个路由器分别接入前述局域网（这两个路由器的LAN都配置了DHCP服务端并分别在不同的网段），再用另一路由器分别接入以上两个路由器并进行负载均衡，这一尝试得到了有效的结果，网络正常工作，猜测的方向应当是正确的。结合多次尝试发现每次异常时间基本在启用两个接口后30分钟，刚好是租期1小时的一半，即第一次续租时间的现象，猜测异常现象与DHCP协议的续租动作有关。回到单路由多WAN的方案，使用以下Iptables命令尝试截获UDP68端口通信并Log到日志，发现没有任何有关DHCP通信的记录：

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

两个WAN中有一个续租成功，但日志中却什么都没有截获。再次查询相关Manual后注意到，多数Linux系统中DHCP客户端使用Rawsocket，通信不被Netfilter框架处理，而这很可能就是上述测试所遇到的情况。而由于续租成功证明了存在DHCP通信，则很可能只是协议通信的内容存在问题。至此明确了两个方向：其一，不论使用什么方法解决问题，只能从内核或内核的依赖上尝试，传统的通过Netfilter框架修改数据包的方案从原理上不可行;其二，截获通信的工具需要改变，且不能对Netfilter有依赖，即要尽量靠近底层。执行以下命令使用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进行分析，发现如图2、图3所示的现象（下文中将两个WAN口分别命名为WAN1和WAN2，其中WAN1、WAN2的Metrics分别为5、10，网关IP为100.71.64.1）。

即WAN2口的续租Request实际上由WAN1发出，导致DHCP服务端和客户端的协商过程出错，脱离了DHCP协议预期的工作方式从而导致续租失败。

再对dhcpwan2.pcap分析，可以观察到WAN2的行为更为异常：自从首次注册后，就再也没有成功续租过，使得其每次到最后都是广播Discover来尝试重新获得租约。

至此，故障原因已经比较清晰。至于为何WAN2的续租Request会从WAN1口发出，这与路由内核工作原理有关：首先DHCP协议的通信不受netfilter管理，自然也不能被Iptables控制，而整个工作基础建立在Iptables上hook的MWAN自然也无法管理DHCP协议。这也就意味着DHCP协商过程严格遵循主路由表，不会被负载均衡或策略均衡管理。因此在进行路由选择时，路由器会查询路由表并选择一条最优线路发送数据包。考虑续租时的情况，此时路由表中有两项，分别表示两个WAN口都可以连通到同一个网络，而路由器总选择较小跃点数的WAN口发包。简而言之，这导致了只要是目的为上级网络且不受MWAN管理的包，都不会经由WAN2发出。

4  解决方法

了解问题背后的原因并结合上述的基本思路，考虑到修改路由内核工作方式难度过大，且很可能会导致各种不可预料的问题，而路由表作为内核路由选择的依赖项就是一个很好的尝试对象。在对OpenWRT系统的DHCP协议部分进行了解后，注意到其行为与接口状态有关，如启用接口、禁用接口会调用DHCP的一些方法，而DHCP会在Discover、Request、Renew等情形调用一个脚本文件并传入执行的动作类型和执行该动作的接口名，而这个脚本文件是可以自定义内容的，于是在该脚本文件上可进行解决问题的尝试。在OpenWRT的路由表中，可以添加对于特定主机IP的静态路由表项，其优先级高于其他路由表项。綜上，一个可能的解决方案是在续租操作实施前在路由表中添加一个项，表示目的IP为网关IP的包应通过将要执行续租动作的接口发送，并在续租动作结束后移除该路由表项。

于是在被DHCP调用的脚本文件中修改被特定行为触发的代码为：

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协议要求的动作、执行该动作的接口名。而"$Int1"、"$Int2"為自定义的变量，声明于脚本开头，用于存储设置的两个WAN口名称。即若有Renew行为，则分别对于两个WAN口调用不同的脚本来暂时修改路由表，使得在进行续租的时候保证DHCP服务端和客户端之间通信的秩序。其中modifyRT1.sh脚本大致执行以下操作（modifyRT2.sh原理相同，仅改变了接口）：删除WAN1口到网关的路由表项;sleep二分之一租期后添加WAN1口到网关的路由表项。这样的顺序可能令人费解，因为较顺应直觉的顺序应是在Renew前添加路由表项，在Renew后将其删除，但这是不可行的。首先是因为Renew动作直接由Kernel的可执行程序实现，无法做到在Renew前调用脚本，即每次都只能是在Renew后执行自定义内容。另也不能按照上述理想顺序完成对路由表的修改，如在添加路由表项后等待续租完成再移除路由表项，具体原因涉及DHCP客户端服务的守护进程netifd以及shell脚本的工作方式，即上一次Renew后被调用的脚本在执行完之前，下一次的Renew不会发生。此处选择简易的匹配接口名来调用写定的脚本的方式仅为了便于说明，应用中可以修改脚本使得其适用于任意多且任意名称的接口。在完成对脚本的修改后，重启路由，两个WAN口网络通信正常。上述仅提供一种实现策略，并不符合规范，需谨慎并结合实际地应用。如图4所示，修改被DHCP调用的脚本本质上使得路由表、DHCP协议行为有了从左到右的变化。

至此，两个或两个以上WAN可以同时作为DHCP客户端在同一子网内正常工作。

5  负载均衡及故障转移

以上步骤仅仅实现了多DHCP协议WAN接口在同一子网下接口协议的正常行为，但若不进行负载均衡，发往外部的数据包就会严格遵循主路由表（主路由表指相对MWAN新创建的路由表而言原有的路由表），即所有流量都不会通过跃点数较大的WAN2。此时要对两个或多个WAN口进行负载均衡，对/etc/config/mwan3配置文件进行配置：

config member 'wan1'

option interface 'wan'

option metric '1'

option weight '1'

以上格式添加参与负载均衡的接口成员，成员指定了一个WAN接口、跃点数、权重。此处对负载均衡有明显影响的是权重比。多个成员的权重比决定了各个接口在负载均衡中承担的流量比重。此外，MWAN还可对成员绑定的接口进行基于循环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'

以上格式定义了一个默认规则，即对于所有出口流量都均匀分配（在balanced策略所选定的成员内，再按照各个成员配置的权重进行分配）。至此，实现一般的对于多WAN的负载均衡。但仅默认规则一定是不够的，正如前文介绍MWAN特性时所提到的，用户需要设置针对HTTPS协议的特殊规则，使对于一个HTTPS服务器在一段时间内的访问被分配至同一WAN出口以确保正常访问使用该协议的网页：

config rule 'https'

option sticky '1'

option dest_port '443'

option proto 'tcp'

option use_policy 'balanced'

此外，对于潜在的如一条链路稳定性要弱于另一链路且终端有较强的网络稳定性要求（如游戏、实时视频通话等常用的UDP通讯）的情况，可以针对创建只使用稳定链路的策略，并匹配例如所有UDP流量给该策略，以确保网络稳定性。又如一些采用HTTPS协议进行但又不每次查验源IP一致性的下载场景，也可以单独设置规则使得对类似下载场景生效负载均衡。规则具有先后顺序，故为了保证所有规则如预期生效，将具有特殊性的规则放置于具有普遍性的规则之前。至此，配置的Multi-WAN负载均衡也具备了一定应对特殊情况的能力，可以满足基本应用。

6  结  论

对于路由多WAN作DHCP客户端接入同一网络后，WAN口之间的兼容性问题，提出通过在DHCP协议工作流程中嵌入对路由表的动态修改从而达到DHCP协议的客户端、服务端正常沟通的目的，并对于使用该方法的路由器成功进行负载均衡和故障转移的配置，证明了方法的可行性以及其与独立第三方组件的兼容性。考虑到系统为多道程序环境，可以预见该方法还可以通过进程同步来提高应对极端情况的能力，以同时维持更多的WAN口正常工作。

参考文献

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

[2] 董宇.多WAN口路由器在网络中的应用 [J].东方企业文化，2012（10）：254.

[3] 王莉.Linux下的防火墙技术研究 [J].中国新技术新产品，2020（19）：38-39.

[4] 刘旭光.服务器群负载均衡的实现 [J].数字技术与应用，2014（2）：98.

[5] 曹哲康.基于OpenWRT系统的区域负载均衡关键技术研究与应用 [D].郑州：郑州大学，2018.

作者简介：吴宇琦（1999—），男，汉族，四川宜宾人，本科在读，研究方向：软件工程。

收稿日期：2021-04-11