关闭路由器防火墙导致断网后用Cloudflare Tunnel 自救

一次误操作，在华硕（ASUS）路由器后台关掉了 防火墙，结果整个家庭网络在几秒钟内彻底瘫痪：设备连不上外网，路由器后台也进不去，人还在外地。这篇文章记录了当时的排查过程，以及最后靠一条早已建立的 Cloudflare Tunnel 连接，绕开常规入口把路由器救回来的完整思路。

问题是怎么发生的

当时是在做本地服务器和网络架构的调整，随手在华硕路由器后台把系统的防火墙关掉了。这个操作看起来很小，实际引发的连锁反应远超预期：

NAT 和 DNS 解析同时失效：局域网内的服务器无法再向外发起新连接，域名解析不了，docker pull、curl 全部超时。
常规的管理通道也被堵死：路由器的外网 DDNS 瞬间失效。防火墙一关，路由器就拒绝了所有新的入站请求，不管是从外网用 DDNS 加端口访问，还是尝试建立新的内网连接，全都走不通。

华硕自己的防火墙功能说明里其实写得很清楚：路由器的防火墙不只是过滤外部攻击，它还承担着局域网设备之间封包管理的一部分工作，关掉之后受影响的不只是安全性这一件事。

当时人在外网，家里所有联网的智能设备，包括摄像头，全部在同一时间离线。原本以为这次必须物理跑一趟去拔插电源才能解决，但意外发现了一件事：路由器进不去了，摄像头也全断了，但通过 Cloudflare Tunnel 连接的自宅服务器 CasaOS 页面居然还能正常打开，网页端的 Terminal 也照常能执行命令。

这一点”还活着”的迹象，成了后面顺藤摸瓜救回路由器的关键突破口。

为什么 Cloudflare Tunnel 还能用

在所有常规入站连接都失效的情况下，唯一还保持畅通的，是部署在局域网服务器 m 上的 Cloudflare Tunnel（cloudflared 进程）。原因在于两种连接方式的方向不一样：

方式	连接方向	防火墙关闭后的表现
DDNS	从外向内（外网主动连入路由器）	路由器拒绝新入站请求，直接失效
Cloudflare Tunnel	从内向外（服务器主动连出去）	连接在防火墙关闭前已经建立，继续保持

关键在于，防火墙关闭之前，cloudflared 早就和 Cloudflare 的边缘节点建立并维持着一条持久的 TCP 长连接，这条旧连接还挂在路由器的内存连接表里，没有被清理掉。外网请求可以继续顺着这条已经存在的通道进入服务器内部，这也是它没有被防火墙关闭事件波及的根本原因。

尝试过哪些方法，踩了哪些坑

为了重新拿回路由器的控制权，在服务器上做了几轮不同方向的尝试。

方案一：用 Docker 跑一个临时转发容器

想法是跑一个 alpine/socat 容器，把服务器 8080 端口的流量转发到路由器的内网管理地址（192.168.1.1）。但服务器的 DNS 已经瘫痪，无法连外网，Docker 直接报 i/o timeout，镜像都拉不下来，这条路走不通。

方案二：靠服务器本地已有的 SSH 做端口转发

既然拉不了新镜像，就完全依赖服务器上已经装好的 SSH。

先尝试用 root 用户建隧道：

ssh -N -f -L 0.0.0.0:8080:192.168.1.1:80 [email protected]

Linux 默认的安全机制不允许 root 用户本地直接 SSH 登录，提示 Permission denied。

换成普通用户 user，端口也改成没被占用的 9090：

ssh -N -f -L 0.0.0.0:9090:192.168.1.1:80 [email protected]

隧道建成功了，但外网通过 http://[IP]:9090 还是打不开。原因是华硕路由器很可能强制要求 HTTPS 访问，而且默认的内网管理端口早就被改过了。

于是转向端口探测，看路由器到底在哪个端口开着门：

for port in 80 443 8543; do nc -zv -w 2 192.168.1.1 $port; done

这里的 8543 是随手编的占位端口，实际操作时请替换成自己路由器真正改过的自定义管理端口。

扫描结果显示，80 端口是 Connection refused，443 和 8543 都返回 succeeded!。这说明路由器只接受加密的 HTTPS 协议，且管理服务本身还在正常运行，只是入口被藏起来了。

最后的解法：直接改 Cloudflare Tunnel 的映射

既然外网流量已经能通过现有的 Tunnel 连接顺利进入服务器内部，最直接的做法其实是跳过服务器内部所有复杂的 SSH 转发，直接改 Cloudflare Tunnel 的映射规则。

第一步：新增一条 Public Hostname 规则

Subdomain：router
Domain：yourdomain.com
Type：HTTPS（必须选这个，才能匹配路由器本身的加密协议）
URL：192.168.1.1:8543（指向路由器实际开放的 HTTPS 端口，8543 依旧是占位数字，实操时请替换为自己的管理端口）

第二步：关闭 TLS 校验

华硕路由器内网默认用的是自签名证书，Cloudflare 出于安全考虑会默认拦截这类连接。需要在 Additional application settings 的 TLS 选项里，把 No TLS Verify 打开。

第三步：验证

配置保存后，浏览器直接访问：

https://router.yourdomain.com

流量经过 Cloudflare Tunnel 的 443 端口进入服务器，再由客户端本地解密后以加密协议送进路由器的 8543 端口。路由器登录页面顺利打开，登录后进入「高级设置」→「防火墙」，把「启用防火墙」重新勾选为「是」并保存。

保存生效的那一刻，局域网的 DNS 解析和 NAT 引擎恢复正常，整个网络也就修好了。

整个排查过程的时间线

误关防火墙 — NAT、DNS、DDNS 同时失效，全屋设备离线

发现 CasaOS 仍可访问 — Cloudflare Tunnel 的旧连接还挂在路由器连接表里

Docker 转发尝试失败 — 无法拉取镜像

SSH 端口转发受挫 — root 权限被拒，普通端口无法访问 HTTPS 管理页

端口扫描定位真实管理端口 — 确认路由器只接受 HTTPS

改 Tunnel 映射直连路由器 — 重新勾选防火墙，网络恢复

几点体会

第一，内网穿透工具在极端断网场景下的容灾价值，比想象中要高。基于”由内向外”长连接机制的 Cloudflare Tunnel，在 DNS 失效、主路由防火墙异常的情况下依然能存活，是这次远程自救唯一能用上的通道。

第二，DDNS 和 Tunnel 各有各的适用场景，但从这次经历看，Tunnel 的抗风险能力明显更强：DDNS 依赖暴露端口，一旦防火墙策略变化就容易失效；Tunnel 不需要暴露任何入站端口，也不受公网 IP 变化的影响，证书还能由 Cloudflare 统一托管。如果只能留一条远程管理的后路，Tunnel 是更稳妥的选择。

第三，如果穿透的目标设备跑在 HTTPS 且用的是自签名证书，一定要记得打开 No TLS Verify，否则流量会在 Cloudflare 边缘节点这一关就被拦下来，怎么配置都进不去。

最后一点更偏经验之谈：远程调试网络设备的时候，尽量避免直接关掉主路由的总防火墙。如果确实需要放行某些流量，用「网络服务过滤」或端口转发针对具体 IP 和端口做精细放行，会安全得多，也不至于把自己反锁在门外。