小米路由器VPN客户端与NAS联动设置

那是一个再普通不过的周三夜晚。我正盯着电脑屏幕上的加密货币行情图，比特币在6.8万美元附近反复横跳，姨太（ETH）的Gas费高得离谱，而我的挖矿池后台显示，六台显卡矿机的算力曲线突然断崖式下跌——从380MH/s直接归零。

“操，又断网了。”我拍了一下桌子，咖啡杯里的液体晃荡着洒在键盘上。这不是第一次了。自从把矿机从家里搬到朋友闲置的郊区仓库，远程控制就成了最大的噩梦。仓库用的是最普通的移动宽带，公网IP？不存在的。端口转发？运营商直接封死了所有非标端口。更麻烦的是，我需要同时管理三台NAS：一台存着挖矿脚本和钱包备份，一台挂着P2P种子下载区块链数据，还有一台专门跑着监控矿机温度和功耗的Home Assistant虚拟机。

我试过各种方案：DDNS、ZeroTier、Frp内网穿透……要么不稳定，要么延迟高得离谱。直到一个在币圈混了五年的老矿工告诉我：“你缺的不是技术，是一台能跑OpenWrt的小米路由器。”

为什么偏偏是小米路由器？

你可能觉得我在给小米打广告，但事实是：在“路由器刷机”这个圈子里，小米的AX系列（尤其是AX3600和AX6000）因为高通IPQ8074芯片和充足的Flash/RAM，成了OpenWrt固件的完美宿主。更重要的是，小米路由器的原厂系统本身就有VPN客户端功能——虽然被阉割得厉害，但配合第三方固件，这就是一台能跑WireGuard、OpenVPN、甚至SoftEther的迷你服务器。

而我的需求很明确：让仓库里的矿机和NAS，通过VPN隧道，像在同一个局域网里一样被我远程管理。所有流量必须加密，因为矿池的API密钥和钱包私钥都在NAS上，裸奔在公网等于把资产送给黑客。同时，延迟要低——挖矿的难度调整是按秒计算的，一次断连就可能损失0.01个ETH。

第一步：给小米路由器“开刀”

我手里这台是小米AX3600，买来的时候还是原厂固件。刷机过程不复杂，但需要一点耐心。先开启SSH（网上有现成的工具，用小米的stok参数登录），然后刷入Breed引导器，最后写入OpenWrt固件。这里有个坑：一定要选带“闭源WiFi驱动”的版本，否则5GHz信号会变成废物。

刷完之后，路由器的界面从小米的“米家”风格变成了OpenWrt的LuCI后台。说实话，第一眼看到那个蓝白配色的界面，我有点恍惚——这玩意真的能解决我的矿机断联问题吗？

核心配置：WireGuard隧道搭建

我选了WireGuard作为VPN协议，原因很简单：它比OpenVPN快3倍以上，内核级的加密效率，而且代码量只有OpenVPN的1%。对于矿机这种需要低延迟的场景，WireGuard几乎是唯一解。

服务器端配置（我的家庭路由器）

先在我家里的主路由（也是刷了OpenWrt的小米AX6000）上开启WireGuard服务。配置过程如下：

1. 在LuCI后台的“VPN”菜单下找到WireGuard
2. 添加一个新接口，设置私钥（用wg genkey生成）
3. 监听端口随便选个高位，比如51820
4. 配置对端：仓库路由器的公钥、预共享密钥、允许的IP段（比如10.0.0.0/24）

这里有个关键点：要开启路由转发。在OpenWrt的“网络”-“防火墙”里，需要确保WireGuard接口的流量能转发到LAN口。否则VPN连上了，但NAS的IP还是无法访问。

客户端配置（仓库路由器）

仓库那台小米路由器同样刷了OpenWrt，但配置稍有不同。因为仓库没有公网IP，所以客户端模式需要主动连接我家的公网IP。我把家里的公网IP写死在配置里（还好是静态IP，如果是动态IP还得配DDNS）。

配置完成后，我在两台路由器的WireGuard接口上分别ping对端的IP——10.0.0.1和10.0.0.2。延迟在3ms以内，比预想的好得多。这意味着仓库的矿机NAS，现在就像插在我家交换机上一样。

NAS联动：SMB、NFS与矿池API

VPN隧道建好了，但真正的挑战才开始。我的三台NAS分别部署在不同的子网里：一台群晖DS220+（存钱包和脚本），一台自组的Unraid（跑P2P和虚拟机），还有一台树莓派4B（挂载Home Assistant）。它们原本的IP段是192.168.31.x（仓库局域网），现在要通过VPN隧道被我家里的设备访问。

路由表与静态路由

OpenWrt默认不会自动广播路由信息。我需要手动在仓库路由上添加静态路由：把家里局域网的IP段（192.168.1.0/24）指向WireGuard接口。同样，在家里路由上添加仓库局域网的静态路由。

这一步折腾了我两个小时。因为一开始我忘了配置防火墙的“IP动态伪装”，导致NAS的响应包无法正确路由回家里。症状很诡异：能ping通仓库NAS的IP，但SSH连接总是超时。后来在OpenWrt论坛上找到答案：在WireGuard接口的防火墙设置里勾选“Masquerading”，问题立刻解决。

矿池API的远程调用

我的挖矿脚本跑在仓库的群晖NAS上，通过Docker容器运行。脚本需要定时向矿池（比如鱼池F2Pool）提交算力数据，同时读取矿机的API端口（比如3000端口）。以前每次脚本崩溃，我都得开车去仓库重启，现在通过VPN隧道，我可以在家里直接SSH进NAS：

bash ssh [email protected] -p 2200

然后执行docker restart miner-container。延迟几乎感觉不到，就像操作本地电脑一样。

更关键的是钱包安全。我的ETH和BTC钱包私钥以加密文件形式存储在NAS的加密共享文件夹里。通过VPN访问时，所有流量都经过WireGuard的加密隧道，即使有人截获了仓库的WiFi信号，看到的也只是乱码。

突发状况：矿机温度报警与Home Assistant联动

上周六凌晨，我正在睡觉，手机突然狂震——Home Assistant推送了一条警报：“矿机GPU温度超过85°C，风扇转速异常。”我迷迷糊糊地打开手机，通过VPN连上仓库的Home Assistant界面，看到六号矿机的风扇转速从3000RPM掉到了800RPM。

如果是以前，我只能打电话让仓库管理员（朋友的侄子）去检查，但半夜人家肯定不接电话。现在，我直接通过Home Assistant的SSH插件，SSH进矿机主板（一个跑着Hive OS的旧笔记本），执行sensors命令查看温度，然后手动调高风扇PWM值。整个过程花了不到5分钟，矿机温度从87°C降到了72°C。

这种“远程救火”的能力，在加密货币的剧烈波动期尤为重要。比如上周ETH价格暴跌时，我需要在几分钟内关闭所有矿机以避免亏损——如果没有VPN，等我开车到仓库，币价可能已经跌了20%。

性能优化：MTU、Keepalive与QoS

WireGuard虽然快，但在实际使用中还是遇到了一些问题：

1. MTU值调优：默认的1420字节在移动宽带上会导致分片，我手动调到了1280。调整后，大文件传输（比如从NAS下载区块链数据）的速度从2MB/s提升到了8MB/s。

2. Keepalive保活：仓库的移动宽带NAT超时时间只有60秒，我设置了25秒的PersistentKeepalive，防止隧道因超时断开。

3. QoS优先级：在OpenWrt的SQM队列管理里，我把WireGuard的流量标记为“高优先级”，确保挖矿脚本的心跳包不会被P2P下载的流量挤掉。

安全加固：防火墙与密钥管理

VPN不是万能药。我见过太多矿工因为VPN配置不当，导致整个内网被攻破。我的做法是：

• 只允许特定端口：在仓库路由器的防火墙里，除了WireGuard端口（UDP 51820），其他所有入站端口全部关闭。连SSH端口都不开——因为SSH通过VPN隧道访问，不需要暴露在公网。
• 密钥轮换：每三个月更换一次WireGuard的私钥和预共享密钥。旧的密钥立刻作废。
• 双因素认证：NAS的登录界面绑定Google Authenticator，即使VPN账号泄露，没有动态码也进不去。

最终效果：算力曲线稳如老狗

现在，我的六台矿机已经稳定运行了整整两个月。算力曲线不再是锯齿状，而是一条几乎水平的直线。远程管理变得像呼吸一样自然：早上起床，用手机连上VPN，看一眼Home Assistant的仪表盘；中午在公司摸鱼时，SSH进NAS更新挖矿脚本；晚上回家，从NAS上把当天挖到的ETH转入冷钱包。

上周，我又加了两台矿机。这次配置VPN只花了15分钟——把新的路由器刷机、导入备份的WireGuard配置、修改静态路由，一气呵成。朋友问我：“你就不怕哪天小米封了OpenWrt？”我笑了笑：“封了也没关系，我还能用树莓派做旁路由，照样跑VPN。”

说到底，在加密货币的世界里，技术不是为了炫技，而是为了在不确定性中抓住一点点确定性。当全网算力在波动，当矿池在切换，当币价在暴涨暴跌——至少我的VPN隧道是稳定的，我的NAS是安全的，我的矿机是可控的。

这就够了。