基于 Raspberry Pi 4B 单臂路由
Here we’re gonna talk about a hand-made router (NAT gateway) using a Raspberry Pi 4B with at least 3 implementations. Sorry the wifi router is not included since it’s kinda easy to find the tutorials about the hostapd stuff, and the signal from onboard wifi is not quite usable anyway.
这里聊一下基于树莓派4B的有线单臂路由实现，至少三种技术实现；wifi路由就不谈了，基于hostapd的教程遍地都是，信号强度也是个问题，可用性仅限于贴脸。
如果只使用iptables的话，实现一个基于pi的路由其实只需要一句话。加上让内核开启转发，两句话打完收工。
Method #1: Several simple commands could simply turn the Pi OS to be a layer 3 device with SNAT (or MASQUERADE).
|
1 2 |
sudo iptables -t nat -I POSTROUTING -s <lan subnet> -j MASQUERADE sudo sysctl -w net.ipv4.ip_forward=1 |
开个玩笑，起码还得先给LAN口设个固定地址，比如给eth0设置 192.168.17.1/24 ，那么上边<lan subnet>就应当是 192.168.17.0/24 。
如果还需要dhcp服务器（非必须）的话，去看一下dnsmasq，熟练工的话，基于一般的Pi OS手打路由只要10分钟（含参考文档）。
PS：要问wan口谁来承担？wifi可以，给eth0加vlan也可以，看想怎么玩。
接下来就是自行编译OpenWrt的玩法，如果不想编，直接去官网下载预编译的镜像也完全ok。该镜像内置了基于Pi 4B的所有硬件驱动，也包括802.11nac的wifi支持，刷机后直接使用没有任何问题。
Method #2: Feel free to build the OpenWrt and run it on the bare metal Pi 4B, or a prebuilt image can be downloaded from OpenWrt official website then you don’t have to build that on your own.
默认设定是br-lan连接eth0，无wan口。因其为单臂路由（没有两张物理网卡），我把br-lan口连接改为 eth0.120 ，wan口设定为 eth0.12 ，当然交换机需要是802.1q VLAN switch，保存设置后正常上网就可以了。
PS：更改lan口vlan id设置的过程，最好走wifi，这样就不会在设置过程中断线。当然还有个选择就是把vlan id 1留给一个接口（无论wan还是lan），随意就好。
对单臂路由在内网进行iperf3带宽测试，MTU 1500就不改了，差不多可以跑满（下图右下）。由此可见，Pi 4B的全双工千兆网靠得住，作为单臂路由没问题，同时跑满带宽的资源消耗也不高。
如此看来，作为4C2G的配置，只跑一个OpenWrt吧，多少感觉有点大材小用。要想物尽其用，一个思路是在OpenWrt编译时加入lxc或者docker，让闲置的CPU/RAM/TF存储等，能有进一步利用的空间；此外，还有一个思路，类似x86软路由的先virtualization再openwrt，在arm64上有的搞么？
不妨一试。编译参数改一下，走起。
Method #3: Build OpenWrt with target system as qemu arm64 vm, then run it over KVM virtualization on Pi OS, which is something pretty much like the solution on X86_64 platfrom – ikuai/owrt over ProxmoxVE on Intel/AMD hardware.
编译结果，选ext4-combined镜像，在Pi OS新建kvm虚拟机。
Pi OS的网络要建俩vlan和两个网桥，用于接虚拟机的wan口和lan口。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
# root @ pi4b-net in ~ [12:06:09] $ cat /etc/network/interfaces.d/bridges auto bri-wan iface bri-wan inet dhcp bridge_ports eth0.12 bridge_stp off bridge_maxwait 10 auto bri-lan iface bri-lan inet static address 192.168.17.2 netmask 24 bridge_ports eth0.120 bridge_stp off bridge_maxwait 10 # py27 @ pi4b-net in ~ [22:04:43] $ cat /etc/network/interfaces.d/vlans auto eth0.12 iface eth0.12 inet manual vlan-raw-device eth0 auto eth0.120 iface eth0.120 inet manual vlan-raw-device eth0 |
两个网卡（NIC），第一个桥接到bri-lan，第二个到bri-wan，就可以vm开机了。
同样在外执行iperf3测试，转发下降了100Mbps，还可以；同时资源消耗也大量升高，可见多了一层虚拟化，软件层面多了很多调度，性能损失要靠资源占用来补足。
再给kvm加一台Debian 11 Buster aarch64的虚拟机，然后跑一下speedtest，算是真实场景测试。
300Mbps外网带宽直接跑满，资源也没有吃空，还是蛮可用的。
综上，如果外网带宽不超过500M的话，其实kvm虚拟化还是不错的选择，OpenWrt只给2C512M就可以工作的很好，剩下的资源还可以起别的系统来使用。反之，如果让OpenWrt独占硬件Pi 4B的话，也可以用docker/lxc综合利用剩下的硬件资源。
最后看下OpenWrt在不同方式下，首页概览显示的差异。
好玩不？喜欢哪种方案，可以留言聊。
2023-05-04 更新
多加一种实现方式：把基于armvirt编译的结果做进lxc image（当然你喜欢docker也很容易，只是笔者更喜lxc）然后用lxd跑，结果如图，单论转发性能的话，跟Pi OS直接iptables的结果很相似（死磕单核转发），某种意义上证明lxc与host OS隔离程度较低。
Method #4: Use the rootfs.tar.gz built from OpenWrt to generate a lxc image then create a lxc instance. Performance of this solution seems pretty much like the method #1. OpenWrt will only consume single core (just like iptables running directly on Pi OS), so it can deliver only around 600+ Mbps throughput, that somehow proves that the isolation between container and host OS can NOT BE COMPARABLE with KVM virtualization.
PS：有人可能要问，你对snapd恨之入骨为啥还要用。只能说临时测试还是snap install lxd更便利，测试完后如果（lxc运行）结果更佳，就会卸载snapd转而使用自己编译的原生lxd；结果如此（一般）的话，依然卸载snapd继续使用kvm即可。
关于kvm虚拟化与lxc容器相比，对于与host OS的隔离程度差异，还有个有意思的观察，有图有真相。
想测的实现方式基本全测了一遍，满意了。
文章的脚注信息由WordPress的wp-posturl插件自动生成
京公网安备 11011502004657号