# From iKuai to RouterOS, and Back to Surge VM Gateway

> I moved my home router off iKuai and onto RouterOS CHR running inside PVE — partly because iKuai 4.0's UI is a rough UniFi knock-off, and more worryingly because packet captures have shown it quietly phoning home in the background; and partly because I wanted the router itself to be just another VM. This post covers the RouterOS setup (dual-WAN PPPoE with PCC, a caching DNS resolver, free IP Cloud DDNS, port forwarding with hairpin and NAT loopback), the trick that finally solved a long-standing annoyance — one DDNS name that reaches the public IP from outside but gets looped back to the right internal host by port when I'm home, since a single domain sitting in front of many different internal IPs can't be split by DNS alone — and the conclusion I kept coming back to: the real domestic/overseas traffic splitting belongs on the Surge VM Gateway, not the router. The router does the plumbing; Surge does the brains. Plus a small door-buzzer automation running on the same PVE box.

Author: Vincent Yang
Published: 2026-08-10
Tags: iKuai, RouterOS, Surge, PVE, Network
Source: https://missuo.me/posts/ikuai-to-routeros-back-to-surge

---

> 家里的主路由用爱快（iKuai）用了挺久。最近我把它换成了跑在 PVE 里的 RouterOS——一半是嫌爱快的界面高仿 UniFi 又不精致、还被抓包爆出后台偷偷往外传数据；一半是想把路由器也虚拟化进 PVE，和别的服务一起管。折腾下来最值得记的，是「兜了一圈、分流还是回归 Surge VM Gateway」这个结论，以及顺手把家里各种零碎都收进同一台 PVE 的一点心得。这篇一起记下来。

## 为什么离开爱快

先说结论：不是爱快不能用，而是我越用越不喜欢、也越用越不放心。

一是**观感**。爱快 4.0 那套界面明显是照着 UniFi 抄的，但又抄得没 UniFi 那么精致，用起来总有种「高仿」的别扭——形似神不似，细节一比就露怯。

二是更要命的**隐私**。有人把爱快挂在主路由下抓包分析，发现**不管是原厂硬件还是免费版，后台都有相当可观的、不该有的对外上传行为**（参见这篇[抓包分析](https://wusiyu.me/2022-ikuai-non-cloud-background-activities/)）。这事我还是从上一篇博客的评论区才知道的——一台**蹲在全家流量咽喉位置**的路由器，在背地里往外传数据，这是我完全没法接受的。

正好又有个顺水推舟的理由：我整套家用基础设施都在 **PVE** 上（一堆 VM、随手快照、想装什么装什么），我更希望**连路由器本身也变成一台 VM**，和别的服务一起被同一台 hypervisor 管理。于是换成了 **RouterOS CHR**，冲着它这几点：

- **全虚拟化**：CHR 就是一台 VM，PVE 里直通两个网口当 WAN、桥接两个当 LAN，路由器和其他服务一视同仁。
- **干净、可脚本化、够底层**：address-list、mangle、PCC、路由表、`/ip cloud`、甚至以后想玩 BGP，全在一台设备里捏；对喜欢自己摆弄路由的人比封闭界面爽太多。更重要的是——它就是一台老老实实的路由器，**不会背着我偷偷干别的事**。
- **地址列表能直接填域名**、DNS 带缓存、DDNS 自带……很多以前要绕的东西，RouterOS 原生就有。

物理拓扑很简单：PVE 上四个 Intel I226-V，两个直通给 RouterOS 当双线 WAN，两个桥进 `vmbr0` 当 LAN；RouterOS 这台 CHR 就是内网网关 `10.10.10.1`。

## 迁移到 RouterOS：把路由器塞进 PVE

迁过来之后，这些是 RouterOS 帮我搞定、当初在爱快上要么没有、要么不顺手的东西：

- **双线 PPPoE + PCC 负载均衡**。两条宽带（2000M + 1000M），用 `per-connection-classifier` 把连接分到两条线。这里有个关键细节：`both-addresses` 分类器会把「同一台设备到同一个目标」的所有连接哈希到同一条线，**根本不叠加**；要让单机到单个目标的多连接真正分摊到两条线，得用 **`both-addresses-and-ports`**（把端口也算进哈希）。
- **失败切换 + 按目标叠加**。默认全走主线（单一出口 IP，很多测速/识别服务不至于被两个 IP 搞晕），只有去往我列进 `address-list` 的那几个境外 VPS 才双线叠加。
- **DNS 缓存**。RouterOS 的 `/ip dns` 本身就是带缓存的解析器，`allow-remote-requests=yes` 之后全家可以直接拿它当 DNS。
- **DDNS 免费免账号**。`/ip cloud set ddns-enabled=yes`，白得一个跟着公网 IP 走的域名。我家公网 IP 一天能变好几次，这个是刚需。
- **address-list 填域名**。firewall 的 address-list 支持直接写域名，RouterOS 解析后以动态条目写进去、按 TTL 刷新——VPS 换 IP 不用管。

配完这些，路由这层是舒服了。真正的乐子在后面。

## 端口转发与 NAT loopback：让一个域名内外无感

迁过来之后，在端口转发上补了两个 RouterOS 的小知识，尤其第二个解决了我折腾这套网络里困扰最久的问题：

- **网关不指向路由器的设备做端口转发，要配 hairpin**。如果被转发的内网服务器默认网关不指向路由器（我这里就有台走了别的网关），纯 DNAT 的回包会从错误的网关出去、源地址对不上被 RST，得在出 LAN 时补一条 masquerade。
- **想「在外走公网、在家走内网」、同一个域名两头无感，靠的是 NAT loopback**。我有一个 DDNS 域名解析到 WAN 公网 IP，人在外面访问没问题，但一回到家，怎么让同一个域名「在家走内网」？一开始我想当然——在内网 DNS 里给这个域名做个 static 解析、指到内网不就行了？可马上就卡住了：**这个域名背后其实是一堆不同内网 IP 的设备**——Mac Studio、好几台 VM、还有一些 IoT 小设备，IP 各不相同。**内网 static DNS 只能把域名指到一个 IP，根本没法同时覆盖这么多台**；何况 **DNS 还看不到端口**（域名只解析成一个 IP），像「同一个域名 `:A` 去这台、`:B` 去那台」这种按端口分流，DNS 层压根做不了。所以结论是：**这件事只能在 NAT 层做**——局域网设备访问「公网 IP:端口」时，路由器按端口把它 DNAT 回对应内网主机（再补一条 masquerade 让回包对称）。配好之后同一个域名在家在外一套配置、完全无感，困扰了我很久的问题算是彻底解决了。

## 为什么「分流」最终又回到了 Surge VM Gateway

RouterOS 能干的事很多，我一度也想过把「国内外分流」也塞进路由器：GEOIP、address-list、mangle 打标、按目的地分流……理论上都做得到。但真上手你会发现，**在路由器上做「好用的」域名级分流是件很累的事**：规则要自己维护、GEOIP 库要更新、很多按域名/SNI 才判得准的场景在纯 IP 层很别扭。

而这套东西，**Surge 已经做到极致了**：fake-IP + 规则集 + 域名级判定 + 各种策略组，机场订阅一挂、规则一套，国内直连、国外走代理，几乎零维护。

所以我最后的架构是一个很舒服的**分工**：

- **RouterOS 只做「体力活」**：双线 PPPoE 拨号、PCC、DHCP、DNS 缓存、DDNS、端口转发 / hairpin / NAT loopback。它是干净的三层路由和转发。
- **分流的「脑子」交回给 Surge VM Gateway**：Mac 上跑 Surge，开启网关能力、虚拟出一个网关地址（我这里是 `10.10.10.88`），然后——**关键一步——让 DHCP 把默认网关下发成这个 Surge 地址而不是路由器**。这样全家设备一拿到 IP，默认网关就是 Surge，流量天然经过 Surge 做国内外分流，路由器只在 Surge 背后老老实实转发。

```text
普通设备 → 网关 10.10.10.88 (Surge, on Mac) → 国内直连 / 国外走代理
                                    │
                                    └→ RouterOS (10.10.10.1) → 双线 PPPoE 出口
```

> 有个容易忽略的细节：**DHCP 下发的 DNS 要故意保持成公网 DNS（而不是路由器）**。正因为 DNS 在「别的网段」，客户端的查询才会被送去经过 Surge、让它做 fake-IP 劫持和分流；要是把 DNS 指回路由器，反而绕过了 Surge，分流就破了。

绕这一圈我才想明白：**「主路由用什么」和「分流用什么」是两个问题。** 我换 RouterOS，换的是那台负责链路、拨号、转发的「路由器」；而「分流」这件最需要域名级智能、又最不想维护的事，Surge VM Gateway 依然是我的最优解。把两者拆开，各干各最擅长的，整套网络反而最清爽。

## 顺手一提：同一台 PVE 上的门禁自动确认

既然路由器都进 PVE 了，索性把家里各种零碎需求也一起收进同一台机器。其中我自己最得意的一个，是**门禁自动确认**。

我在 PVE 上单独开了一台 VM，专门伺候一个 **DJI 的 4G 模块**：模块用 USB 插在 PVE 宿主机上，再在 PVE 里把它**直通**给这台 VM。VM 里跑的是 **VoHive**。

它解决的是一个特别琐碎、又特别烦的日常：以前外卖或快递员到楼下，按我的房间号，门禁系统会自动打电话到我手机，我接通、按一个「**#**」，楼下的门才开。人在忙、在开会、或者手机不在手边的时候，这通电话很容易误事。

现在这套流程被彻底自动化了：**VoHive 一旦接到门禁系统打来的电话，就自动接通并确认（等于替我按下那个「#」）**。快递外卖照样顺利送上楼，我完全不用管。折腾归折腾，但这种「省掉一件天天要做的小事」的自动化，用起来是真香。

## 小结

- **离开爱快换 RouterOS**：一半是嫌它 UI 高仿 UniFi 又不精致、还被抓包爆出过后台偷偷上传数据的隐私问题；一半是想把路由器也塞进 PVE、换 RouterOS 的干净、可脚本化和灵活路由。
- **PCC 想真叠加，用 `both-addresses-and-ports`**；`both-addresses` 会把同一对 src/dst 钉死在一条线上，不叠加。
- **顺手把家里各种零碎也收进同一台 PVE**：比如用 DJI 4G 模块 + VoHive 做门禁自动确认——快递外卖到楼下，自动接通、替我按「#」开门，一处管理、一处快照。
- **内外一套配置**要靠 **NAT loopback**；而且记住 **DNS 没法按端口分流**，端口→主机的映射只能在 NAT 层做。
- **主路由和分流是两回事**：RouterOS 干体力活，**分流的脑子最终还是回到了 Surge VM Gateway**——让 DHCP 把网关下发成 Surge，全家无感走分流，路由器安心在后面转发。