mirror of
https://github.com/8butubb/8butubb.github.io.git
synced 2026-10-10 07:06:39 +08:00
236 lines
12 KiB
Markdown
236 lines
12 KiB
Markdown
---
|
||
title: 给飞牛 NAS 加装 4G 模块当备用网：拔掉网线也不掉线
|
||
tags: [nas, 4g, 网络, 飞牛os]
|
||
date: 2026-10-05T00:00:00Z
|
||
summary: "单条网线的 NAS 一断线就彻底失联：中继连不上、机器人掉线、远程全废。这篇记录我给飞牛 NAS 插上 USB 4G 模块做备用链路，一路踩过 OVS 藏断线、僵尸默认路由、网口编号漂移、模块编号变化这些坑，最后实现「拔线自动切 4G、插回自动切回」的全过程。"
|
||
---
|
||
|
||
## 起因：单线 NAS 的焦虑
|
||
|
||
家里的 NAS 只有一条网线。平时岁月静好，但只要出现下面任意一种情况：
|
||
|
||
- 网线被谁碰掉（比如我插拔 USB 设备时顺手带下来）
|
||
- 光猫/路由器抽风重启
|
||
- 宽带施工挖断
|
||
|
||
NAS 上的东西就**全部对外失联**：远程访问进不来、自建的机器人掉线、同步全部卡住，而人在外面只能干瞪眼。
|
||
|
||
想上第二条宽带吧，又贵又没必要。所以很自然就想到了：**插一块 4G 模块当备用链路**，平时待命，主线断了自动顶上去。
|
||
|
||
## 硬件：一块 USB 4G 模块 + 一张流量卡
|
||
|
||
硬件很朴素：一块 USB 接口的 4G 模块（Quectel EC25 方案的成品，USB ID `2c7c:0125`），加一张运营商的流量卡。
|
||
|
||
插上飞牛（fnOS，Debian 12）之后，Linux 这边其实**什么都没配就能认**：
|
||
|
||
```bash
|
||
lsusb | grep -i quectel # Bus 007 Device 003: ID 2c7c:0125 Quectel EC25 LTE modem
|
||
mmcli -L # /org/freedesktop/ModemManager1/Modem/0 QUECTEL Mobile Broadband Module
|
||
ip -br link | grep wwan # wwan0 UP
|
||
ip route show default
|
||
# default via 192.168.20.1 dev enp4s0-ovs proto static metric 100 ← 有线（主）
|
||
# default via 10.200.35.20 dev wwan0 metric 5000 ← 4G（备）
|
||
```
|
||
|
||
几个要点：
|
||
|
||
- 网卡驱动是 `qmi_wwan`，出来一个 `wwan0`；
|
||
- 拨号是 **ModemManager 的 initial EPS bearer** 自动做的，**NetworkManager 完全不接管它**（这点后面很关键）；
|
||
- 运营商给的是内网地址（CGNAT）+ 一段 IPv6；
|
||
- 默认路由的 `metric` 决定优先级：**数字小的优先**。所以有线 100、4G 5000 —— 有线在的时候，4G 就是一条安静的备胎。
|
||
|
||
## 飞牛的第一盆冷水：界面里根本没有 4G
|
||
|
||
打开飞牛「网络设置」，**找不到这块 4G 网卡**。
|
||
|
||
一开始以为是配置问题，后来翻了 `/usr/trim/bin/network_service` 二进制、它的日志、以及前端页面资源，发现里面连 `wwan`/`modem` 这类字样都没有 —— 结论很干脆：**飞牛的网络设置目前不支持 WWAN 类型的接口**。
|
||
|
||
所以 4G 这条链路只能靠命令行管（`mmcli` / `ip` / `nmcli`）。界面指望不上，但也不影响用。
|
||
|
||
## 大坑：拔掉网线，NAS 反而彻底失联
|
||
|
||
最反直觉的地方来了。
|
||
|
||
信心满满地拔掉网线，结果**整台 NAS 直接像死了一样**：远程中继连不上、飞书机器人静默、连域名都解析不出来。
|
||
|
||
但诡异的是：
|
||
|
||
```bash
|
||
curl -4 -s --interface wwan0 https://ifconfig.me/ip # ✅ 走 4G 单独测，通！
|
||
ip route show default # ✅ 4G 那条 metric 5000 明明在路由表里
|
||
```
|
||
|
||
**4G 是好的，路由也在，但流量就是不从它走。** 这就是典型的需要抓现场的问题 —— 等你回我消息的时候，故障现场早就过去了。
|
||
|
||
### 第一步：用「触发式采样器」抓现场
|
||
|
||
间歇性故障最忌讳猜。做法是写个采样器，**等状态跳变**（比如物理网口 `carrier` 从 1 变 0），跳变后立刻连采十几轮，把每一轮的路由表、DNS、每个接口单独发请求的出口 IP、中继域名可达性全记下来。
|
||
|
||
采样结果非常干净：
|
||
|
||
- 有线接口 `enp4s0` 的 `carrier=0`（物理上确实断了）；
|
||
- 但桥接口 `enp4s0-ovs` 的 `carrier` **恒为 1**；
|
||
- 断网窗口里，ping/HTTPS/DNS 全是超时（`000`），而 `curl --interface wwan0` 单独走 4G 是通的。
|
||
|
||
### 第二步：根因 —— OVS 把断线藏了起来
|
||
|
||
我的网口套在 OVS 里。**OVS 会把物理断线藏起来**：
|
||
|
||
- 物理口 `enp4s0`：`carrier=0`（断了）
|
||
- OVS 内部口 `enp4s0-ovs`：`carrier` 永远是 1
|
||
|
||
于是 **NetworkManager 根本不知道线断了**，那条 `proto static metric 100` 的默认路由**不会撤销**。结果就是：所有流量继续往一个已经不可达的网关灌（黑洞），而 4G 的 `metric 5000` 老实排在后头，**永远轮不到**。
|
||
|
||
所以这不是 4G 的问题，是**僵尸默认路由**的问题。
|
||
|
||
## 解法：2 秒轮询的默认路由看门狗
|
||
|
||
思路很直接：**盯物理口的 carrier**，断了就把 4G 那条默认路由的 metric 从 5000 提到 50（压过有线的 100），线回来再撤掉。
|
||
|
||
```bash
|
||
PHYS=enp4s0 # 物理口（读 carrier 用）
|
||
LTE_DEV=wwan0 # 4G 网卡
|
||
LTE_PRIO_METRIC=50 # 临时优先权
|
||
|
||
carrier() { cat /sys/class/net/$PHYS/carrier 2>/dev/null || echo "?"; }
|
||
lte_gw() { ip route show default | awk -v d="$LTE_DEV" '$1=="default" && $5==d {print $3; exit}'; }
|
||
|
||
# 注意：判断 metric 必须用数字比较，别用字符串匹配（见下面的坑）
|
||
route_metric_is() { # $1=网关 $2=网卡 $3=metric
|
||
ip route show default | awk -v g="$1" -v d="$2" -v want="$3" '
|
||
$1=="default" && $3==g && $5==d { for (i=1;i<=NF;i++) if ($i=="metric" && $(i+1)+0==want+0) found=1 }
|
||
END { exit(found?0:1) }'
|
||
}
|
||
|
||
check_once() {
|
||
c=$(carrier); lg=$(lte_gw)
|
||
case "$c" in
|
||
0) # 有线断了 → 给 4G 提权
|
||
if [ -n "$lg" ] && ! route_metric_is "$lg" "$LTE_DEV" "$LTE_PRIO_METRIC"; then
|
||
ip route replace default via "$lg" dev "$LTE_DEV" metric "$LTE_PRIO_METRIC"
|
||
fi ;;
|
||
1) # 有线恢复 → 撤掉临时路由
|
||
if [ -n "$lg" ] && route_metric_is "$lg" "$LTE_DEV" "$LTE_PRIO_METRIC"; then
|
||
ip route del default via "$lg" dev "$LTE_DEV" metric "$LTE_PRIO_METRIC"
|
||
fi ;;
|
||
esac
|
||
}
|
||
```
|
||
|
||
### 这里有两个必须踩过才知道的坑
|
||
|
||
**坑 1：不要动 NetworkManager 管的那条路由。**
|
||
|
||
我最早的做法是去改**有线**那条默认路由的 metric（100 → 10000），结果 **30 秒内就被 NM 改回 100**，看门狗白干 ✗。
|
||
|
||
正确姿势是改**没人管的那条**：4G 的默认路由是 **ModemManager** 建的，NM 不碰它，所以把它从 `metric 5000` 提到 `metric 50`，稳稳压过有线的 100 ✓。
|
||
|
||
> 通用经验：**改配置前先问「这条配置属于哪个管理器？我改它会不会被覆盖？」** 会覆盖，就换一个等价但归你的杠杆。
|
||
|
||
**坑 2：判断 metric 别用 `grep` 做前缀匹配。**
|
||
|
||
我第二版用了 `grep "metric 50"` 来判断"临时优先路由还在不在"，看着挺对，实际灾难：
|
||
|
||
```
|
||
default via 10.200.35.20 dev wwan0 metric 5000
|
||
^^^^ 里面就含 "metric 50"
|
||
```
|
||
|
||
于是有线恢复之后，脚本以为临时路由还在，**每 2 秒重复删一次、刷满日志** ✗。改用 `awk` 把 metric 取出来做**数字比较**之后，世界清净了。
|
||
|
||
## 部署：非 root 也能长期维护的「转发脚本 + 自更新」
|
||
|
||
这台 NAS 上我跑服务的账号没有 root，每次改脚本都要找人 `sudo` 重装，很烦。所以又套了一层：
|
||
|
||
1. `/usr/local/sbin/wan_carrier_fix.sh` 只放一个 **3 行的 stub**，干一件事：exec 到工作目录里的真身；
|
||
2. 真身脚本放在普通用户可写的工作目录里，主循环每 2 秒顺手比一下**自己的 mtime**，发现被改了就地 `exec "$SELF"` 重新加载。
|
||
|
||
```bash
|
||
# /usr/local/sbin/wan_carrier_fix.sh —— 只装一次，以后再也不碰
|
||
#!/bin/bash
|
||
exec /path/to/real/wan_carrier_fix.sh "$@"
|
||
```
|
||
|
||
```ini
|
||
# /etc/systemd/system/wan-carrier-fix.service
|
||
[Unit]
|
||
Description=WAN carrier failover watchdog
|
||
After=network-online.target
|
||
|
||
[Service]
|
||
ExecStart=/usr/local/sbin/wan_carrier_fix.sh
|
||
Restart=always
|
||
RestartSec=3
|
||
|
||
[Install]
|
||
WantedBy=multi-user.target
|
||
```
|
||
|
||
效果：**以后改脚本只要改工作目录里那份，2 秒后自动生效**，systemd 只负责兜底崩溃重启。省下的都是找 sudo 的时间。
|
||
|
||
（小细节：自更新重载必须用**绝对路径**，因为 systemd 给的工作目录可能是 `/`。）
|
||
|
||
## 切到 4G 之后要处理的两件事
|
||
|
||
**① 出口 IP 变了，中继要重新握手。**
|
||
4G 出口 IP 和宽带完全不是一个网段。家里的 NAS 中继（fnid）是长连接，切过去之后它那边不认旧会话，**必须重启一次中继服务**（`systemctl restart trim_connect`），重启完立刻可用 ✓。
|
||
|
||
**② 裸 4G 只有出、没有进。**
|
||
4G 是运营商 CGNAT，**入站不可能**。所以对外访问要么走中继、要么走 Tailscale —— 局域网直连在断线时必然不通，这不是故障。
|
||
|
||
顺带一个同源坑：**给隧道/反代配置回源地址时别写局域网 IP**。我原来写的是 `http://192.168.20.18:8080` 这种，一旦网卡上的地址没了，回源直接断（外部看到 530）。改成 `http://127.0.0.1:8080` 之后，**跟走哪条线路、哪个地址完全无关**了 ✓。
|
||
|
||
## 别让 4G 偷偷烧流量
|
||
|
||
装完之后我看了眼计数器，吓了一跳：**开机 36 分钟，4G 上行已经 3 GB** 😅
|
||
|
||
原因：机器上 **IPv6 的默认路由只有 4G 这一条**，所以所有 IPv6 出站流量都在走 4G。而跑着 qBittorrent 的话，做种上传会疯狂吃 IPv6。
|
||
|
||
两个处理：
|
||
|
||
- **治本（软件里就能做）**：qBittorrent → 设置 → 高级 → 「网络接口」选有线口、「可选 IP 地址」选有线地址 → 它只用有线收发，线断了它自己哑掉，**绝不会吃 4G** ✓
|
||
- **兜底**：加一个静默流量看门狗，**只在"有线本来就正常"时才可能报警**（当日 4G > 1 GB，或单轮增量 > 200 MB），断线期间 4G 是唯一出口，属正常使用，一个字都不说。
|
||
|
||
## 换个 USB 口的意外收获：别写死网卡名
|
||
|
||
后来我把 4G 模块换个 USB 口插，顺手发现两个"绝对不能写死"的东西：
|
||
|
||
1. **ModemManager 里的模块编号会变**：`Modem/0` 变成了 `Modem/2`；
|
||
2. **接口名也可能变**（这次还是 `wwan0`，但没理由指望它永远不变）。
|
||
|
||
所以所有脚本都改成了**自动识别**：
|
||
|
||
```bash
|
||
# 找 4G 网卡：优先看驱动是不是 qmi_wwan，退路才找 wwan*
|
||
for d in /sys/class/net/*; do
|
||
[ -e "$d/device/driver" ] || continue
|
||
[ "$(basename "$(readlink -f "$d/device/driver")")" = "qmi_wwan" ] && basename "$d"
|
||
done
|
||
```
|
||
|
||
另外还遇到一次 ModemManager 状态错乱：`mmcli` 报 `state: failed / failed reason: sim-missing`，可数据其实是通的（模块自己续着会话）。`systemctl restart ModemManager` 让它重新识别 SIM 即可 —— **但要注意，这时 MM 已经不托管任何数据会话了，一旦掉线它不会自动重连**，所以别放着不管。
|
||
|
||
## 效果
|
||
|
||
现在这套跑下来，日常是这样的：
|
||
|
||
| 场景 | 表现 |
|
||
| --- | --- |
|
||
| 拔掉网线 | 1~2 秒内 4G 提权顶上，NAS 服务、远程访问、机器人都不断 |
|
||
| 插回网线 | 自动撤掉临时的 4G 路由，出口回到有线，4G 回到待命 |
|
||
| 只有 4G 时 | 远程访问走中继（需重启一次中继服务），局域网直连不通属正常 |
|
||
| 有线正常时 | 4G 只当备胎，流量几乎为零（qB 已绑定网卡） |
|
||
|
||
成本就是一块 4G 模块 + 一张流量卡，比第二条宽带便宜太多了。
|
||
|
||
## 小结
|
||
|
||
- **单线 NAS 的备用链路，值得折腾**；4G 模块在 Linux 上几乎是插上就能用；
|
||
- **断线切换的坑常常不在备用链路本身，而在主链路的"僵尸状态"**（本例：OVS 藏了物理断线 → 默认路由不撤 → 备用链路永远轮不到）；
|
||
- **别跟上层管理器抢它管的配置**，换个"没人管的等价杠杆"（改 4G 那条 metric，而不是有线那条）；
|
||
- **判断数值别用字符串匹配**，`metric 50` 会被 `metric 5000` 命中；
|
||
- **脚本别写死网卡名/模块编号**，用 `qmi_wwan` 驱动去认；
|
||
- 计量的链路上，**把大流量程序绑到主网卡**，再配一个"只在异常时才说话"的看门狗。
|
||
|
||
折腾的过程很烦，但结果是"真香"：现在拔网线，我甚至感觉不到。
|