基于CM4 Sensing双WAN冗余路由
把手头能玩的板子全玩了一遍，完全停不下来。基于virt-manager和virsh cli的libvirt方案虽然没有PVE的纯web使用便利，但毕竟ARMv8有完全可用的libvirt支持已经很方便了，还要啥自行车哦。
既然Pi 4B据测已经能够很好的承担虚拟化路由职责，那么基于CM4并集成了4G LTE连接能力的CM4 Sensing就完全有能力实现双路外网的负载均衡+故障切换，对吧？
那即使技术实现上的选择已经很清晰，我们还是列一下目前已知的可能途径：
- 基于一般Linux发行版使用iptables + connmark + policy-based routing直接手打路由。我曾用一台Debian 11 vm做过实验并且跑通了最基本的双wan负载均衡，想来感兴趣这种原始手工方式的玩家想必不是很多，所以也没有过多记录。且继续往下，在Linux上做这些策略的持久化、多ISP定时监控、故障切换，都有大量的脚本工作；而这方面已有大量成熟方案，我的目的仅仅是通过实验理解原理，目的达到，见好就收。感兴趣的可以通过关键词检索相应文章学习，另外B站的“金枪鱼之夜”的课堂录像（上下两集），可以帮你很好的由浅入深搞懂iptables。
- 直接按Pi 4B编译/下载OpenWrt固件。如我们之前的mwan3负载均衡测试，功能实现上不应存在潜在问题，但这里显然要开始考虑4G/5G模块的驱动编译，wan口支持wwan的相应库的选择，最终编译结果固件的长期可靠性测试，硬件如果升级（比如4G模块，比如CM4载板）必然重新编译……一圈玩下来可以说是实现产品的精力了。
- 第三个选择就要轻松的多。完全无需重新编译，把我们已经玩6的armvirt镜像直接扔Sensing里，给vm多加一个虚拟网卡eth2，打完收工。
没理解是吧，没关系，先把上一篇《基于Raspberry Pi 4B单臂路由》复习一下，接下来我们看图说话。
首先是Host也就是Pi OS的路由表，仔细观察三个ISP都通外网：
- wwan0，4G网络。它Metric值最小，所以优先级最高，整个Pi的外网由它接管。
- bri-wan1，依然是我用eth0.12做的网桥，有线网。Metric值居中，所以外网通但Pi OS目前不用它。
- wlan0，wifi连接。跟bri-wan1实际走同一出口，我拿它做本次实验的调试入口，因为它全过程不被改动。
PS1：Metric值越小，优先级越高。且Metric不是权重的概念，是赢家通吃，整个系统所有不去static routes的数据默认都走metric最小的出口（除非专门设置策略路由）。这一点如果不理解，可以自行学习。
PS2：Metric值既然能决定默认路由的先后，那么必然可设置，设置不同网卡的metric在不同的网络管理服务（或不同发行版中）中有不同设置方式。此处我使用EDA TEC厂家推荐的Network Manager（之前更习惯interfaces文件或者dhcpcd）进行设定，具体使用 nmcli 或者 nmtui 进行操作，此处略去不表。
既然目前整机外网流量都走4G连接，那么事情就简单了。Host机给libvirt vm的设定加一块网卡，不额外加网桥，直接连到libvirt初始化时创建的默认NAT网关virbr0，也就是图中第三块卡，声明 <source network='default'/> 。
这里可能读者就要问了，既然宿主机的网络被Metric最小的4G“赢家通吃”了，那你原来添加的第二块卡 —— OpenWrt eth1原本的WAN口，它外出流量不也实际从4G走掉了？还做的哪门子dual wan呢？
首先这是个好问题，说明你仔细思考了。其次呢，你没有深入辨别Bridge（网桥）和NAT（网络地址转换）的差异，如果搞明白了，就清楚这里是刚好能够通过桥接取巧的。
那么进入owrt管理界面，就如愿以偿得到三块网卡，分别设置为LAN、WAN和WANB，把相应接口和防火墙都按需设定。注意WAN给metric 10，WANB给20，否则owrt默认都是0，回头mwan玩不转了。
然后打开mwan，按相关文档，设定接口、成员、策略和规则，保存，服务也相应开启。
界面可以非常清晰的告诉你，两个WAN口都上线了，也即各自都通。
其次我们对mwan设置了三种策略，而该页底部（未截图）我们针对多数的外网访问都选择了balanced策略，也即60%流量走有线，40%走4G。
问题又来了，“如果我用4G肯定是故障切换链路，有线网络良好为啥要用4G？”
别急，看下边还有wan_wanb策略，如果设定这个策略，就是全流量走wan，失败切换到wanb。目前选择balanced是因为便于测试效果。
活儿都利索了，结果就显而易见了。
马上就做故障切换实验，先断wan（有线网）口，方式是物理断开交换机上联网线。
观察系统日志，两个ip各自失败3个ping，则判定接口失效，下线处理。
此时看状态，wan处于offline，wanb依然online，而所有的policy都变为wanb 100%，测试外网连接也可以正常通，冗余变单点，系统依然可用。
然后有线网恢复连接，观察日志，两个公网IP 8次可以ping通，恢复接口上线。期间丢失48 pings也赫然在目。
然后再模拟wanb失效，用到的方法是在宿主机上 ifconfig virbr0 down ，那么再看日志，跟wan的断开（以及恢复后重连）是一样的。
自此，基于CM4 Sensing（外加一台Netgear GS105E）的双wan高可用单臂路由虚拟化就完成了实验，有问题欢迎留言讨论。
PS1：此机如果带硬件双千兆，设置上即可脱离802.1q vlan，会更方便易用。当然有人可能会问，加个usb网卡很难吗？我只能说，即使走USB总线也是layout在载板上可靠性高，好伐？（当然如果还有PCIE带宽余量，那么不用USB会更安逸）
PS2：或许有朋友开脑洞，想加上wifi做个三路冗余，“再多做个桥接可行么？”
一般来说，802.11 wlan是不允许作为网桥“桥墩”的，具体原因超纲不提了。而显然由于Host OS多网卡Metric值问题，直接NAT到wifi是无法实现的。
“那还有办法实现么？”
有，可能还不止一个思路。总之需要多学多练哈，本文抛砖引玉的目的已经达到，如前所言，欢迎讨论。
文章的脚注信息由WordPress的wp-posturl插件自动生成
京公网安备 11011502004657号