路由虚拟化,意义何在?

2023-06-04 作者:

见此题目,心急的路由玩家,可能等不及要说,我要all in one啊。

“主路由还要承担NAS、HA、运行docker,甚至一些通用win/linux虚拟机的脚本工作,我已经按大佬教程在ikuai/openwrt上搞了kvm,挺香,你不搞么?”

非也,我是反向操作,先虚拟化,再跑路由,理由也很简单 –

“首先,专业方案解决专业问题,所以尽管底层都是kvm,我不喜欢用一个路由系统做virtualization host,NAS系统也同理。其次,我要极致灵活性和对特殊需求的支持能力。”

对第二点,我举个简单的例子,我希望ikuai实现以下需求 –

  • 对硬件#1物理口做成单臂路由,vlan id 3为WAN去拨号,vlan id 12为LAN,且开DHCP。
  • 然后把#2物理口加入ikuai WAN2(第二条宽带,或者4G wwan转成有线接入做冗余连接备用)。
  • 再把#3物理口加入LAN,而#3物理口vlan id 22放给二级路由的LLAN。
  • 二级路由的WAN不走物理口,直接走host内部虚拟交换机接在ikuai LAN的下边。

如果路由裸装ikuai系统,我不知道是否方便实现,花点心思或许可以吧。但如果物理机是Proxmox VE,我实际遇到的使用场景应该比如上说的还复杂些,完全不是问题,ikuai完全不需要设置任何vlan,如上需求可以都在pve host的linux vlan和bridge的层面做好,进路由看到的完全是多块virtio独立网卡。

“那么今天你要讲,怎么在pve+ikuai上实现这个需求?这种需求一般人用不上,我为何要了解?”

非也,今天想讲下我在家中遇到一个更有意义的需求,给智能电视(尤其某些第三方APP)限速,且主要针对上传速度。


 

首先,为何要限速?观察下图,黑线两侧,是限速前后状态对比。

我们可以很明确的发现,限速前上传速度是4MBytes/s左右,可以说基本把家宽的上行带宽吃完了,此外我们的RK3399被迅速推高了15℃,温度达到70℃左右,别忘记现在还只是春末夏初。

完整阅读本篇»

基于CM4 Sensing双WAN冗余路由

2023-05-12 作者:

把手头能玩的板子全玩了一遍,完全停不下来。基于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单臂路由》复习一下,接下来我们看图说话。

完整阅读本篇»

基于 Asus Tinker Board 2S 单臂路由

2023-05-07 作者:

书接上回,这次实验对象轮到了压箱底旧货,基于RK3399的华硕Tinker Board 2S

虽然原厂OS拉胯,不得不说硬件用料还是大厂风范

话说这CPU运行libvirt比较艰难,直接新建vm确定100%报错cpu初始化失败。

查阅了一些资料,发现这种大小核的cpu,libvirt支持上比较有个性,vm要么选择小核,要么选择大核,万不可“既要又要”,否则就报错摆烂。也好,A72双核 vs. A53四核,看看老话“双拳难敌四手”到底靠谱不靠。

带上vlan,蛮好一台4口路由

那么先给OpenWrt配置A72双核,注意是RK3399的后2核,莫要搞错。

完整阅读本篇»

基于RPi和LXD的ESP32开发环境

2022-11-22 作者:

对于在板子手动重启时经常把ESP32带进下载模式的问题,LAN8720所需的上/下拉电阻恐怕是最大嫌犯。于是斥巨资近CNY 10元采购了万用板、线仔包和各种直/弯母座,终于搞了MKII —— 重启可靠性问题果然迎刃而解。

过程中,基于lxd的Debian in Debian做了套新环境,顺手也试了试C语言的esp-idf编译,用起来整体感觉很顺手。

RS232 connected with an lxc in raspberry pi 4b (not in pic)

Yes, it actually performs nicely to work on ESP32 development in debian bullseye LXD in Pi OS, no mater you’re working on hardcore C lang based esp-idf or the nice & easy micropython development.

“Hmm… so you need a standard Debian in a derived Debian? “

Well, since I found out that LXD is something very helpful to isolate different needs on different Linux distributions in different containers, while it kinda works pretty much like vm (instead of docker) since it’s easy to config the resources consumption or even usb devices pass-through, and the most important – having its own block storage which can be exported into a single archive.
Then, the only thing I can’t agree with, could be the deep connection with the snapd. Instead of switching to another distribution, such as Arch, I choose to build the LXD of my own (on both Pi OS aarch64 and Ubuntu 22.04 X86_64). Thanks to the good documentation, the stuff (native lxd without the snap crxp) works like a charm.

with Xfce and xrdp, the bullseye lxc can work as an esp dev server quite well

完整阅读本篇»

HAOS集成和风天气

2022-09-27 作者:

室内搞完了,室外就别搞传感器了,直接走api拉数据。

系统默认集成的OpenWeather和AccuWeather都不太靠谱,前者填了api key后报无效,后者是数据离实际差距大+免费api次数不够用,最后还得自己搞国内的天气服务API。

注册了高德、和风两家,后者虽然没有前者的品牌,但毕竟数据种类更齐全,用来练手是不错的。

效果如下:

至于怎么安装,其实什么插件都不用装,直接File Editor插件编写 /config/configuration.yaml ,保存无误后,重启服务即可。

【注】重启服务,只需要“配置”->“系统”->“重新启动”。这个过程很快,30s搞定。不需要重启整个HAOS的vm或者物理机,那个时间要长很多。

要写什么内容呢?

完整阅读本篇»

nginx控制iptables芝麻开门

2022-02-10 作者:

During maintenance of a production server, we use to encounter a problem like this – an internet-access-blocked port, say 3306 (mysql), is about to be open for a little while due to debugging needs, which is not uncommon, right? So how to make this easily operated, mostly secure, and automatically disabled after working – I guess this’s gonna help somehow.

A Linux server with whatever the distribution including iptables (e.g. CentOS, Rocky for now as example), Nginx, fcgiwrap, a simple shell script and a commonly used web browser, let’s say chrome, will be major ingredients on the recipe.

常做运维,总会遇到某些线上服务器,为了便于调试,在符合安全要求的基础上,需要相对便利的对公网短时定向开放某些端口。

昨天想了一招,用nginx操作shell脚本,对特定公网IP开口子,叫一声“芝麻开门”,便捷又安全。举例端口3306(mysql),系统是Rocky Linux 8(原CentOS 8)。

Doors of Durin

Doors of Durin

先查一下现有的防火墙规则,需要的话可以保存一下。换句话说,搞芝麻开门之前,先确定门是隐藏的;也即已经有相应(且持久化)的iptables rule确保到被保护端口的连接是DROP/REJECT状态。

然后就是fcgiwrap的安装,此处就不写nginx安装过程了,默认安装即可。

安装后增加两个systemd服务文件,并测试fcgiwrap服务生效。

【注】那俩服务文件,在Redhat之外的发行版上,fcgiwrap安装包可能自带,请针对所用版本自行检查。

接下来为一个新的nginx server准备个根目录,存放网页和之后控制iptables的脚本。

完整阅读本篇»