换过 VPN 之后，路由器管理页面为什么不再响应

VPN 改动可能切断路由器的管理路径，也可能悄悄把它打开得更大。在信任隧道路由之前，先检查路由、入站规则和监听进程。

为测试路由器上的隧道，你改了一条路由或防火墙规则，结果十分钟前还正常的笔记本现在打不开管理页面。第一反应是怪 VPN。多数时候隧道本身没问题，坏掉的是另外三件事之一：没有回到路由器自身地址的路由，入站策略把请求丢掉了，或者你要访问的地址上根本没有 Web 服务在监听。这三种在浏览器里看起来一模一样，所以人们重启隧道一个小时，什么也没学到。

先要杀掉的误解是：隧道能通，不等于有回到内部的路径。它是一条新的网络连接，带着自己的信任问题，可能在悄悄撤掉旧管理路径的同时，打开一条没人审过的路。

隧道从来不是管理路径

转发和入站是两件不同的事。「客户端能不能通过隧道访问 NAS？」问的是经过路由器的包如何转发。「我能不能打开路由器的 SSH 端口？」问的是发往路由器本身的包如何入站。为转发流量写的放行规则对第二个问题毫无作用，这也是隧道明明把流量送得很好、却仍然拒绝你的管理会话的最常见原因。

反向的错误是相信接口名字。隧道是加密到对端的，而不是到它后面的每个服务，接口标签里的 VPN 三个字并不能说明该允许哪些来源登录。

第一层：有没有通往路由器自身地址的路由？

从客户端开始，问内核这个包会去哪里。在 Linux 上 ip route get 10.6.0.1 会打印选中的路由、出口接口和源地址。如果它报的是通往运营商默认路由，那么这个包根本不会进入隧道，路由器上再多的规则也救不了它。

隧道这一侧有自己的问法。WireGuard 把 AllowedIPs 当作密码学密钥的路由表：每一端都声明对端可以使用哪些源地址、哪些目的地会被送到该对端。如果客户端一端的条目不包含路由器的隧道地址，客户端就没有通往它的路。如果服务器为这个客户端配的条目不覆盖客户端的隧道地址，服务器在查任何防火墙规则之前就把包丢了。

在排查策略之前，先确认你期望到达的确切地址。过期的 DNS 记录或改动前缓存的邻居条目，会把你送到路由器从来没有过的地址上。

第二层：看入站策略，不是转发策略

防火墙在包进入的接口上评估规则。在 pfSense 和 OPNsense 里，接口页签和规则顺序决定发往防火墙自身服务的流量是否放行；一条让 LAN 客户端上网的规则，并不是让隧道对端打开 Web 界面的规则。用 firewall4 的 OpenWrt 里，每个区域各带入站策略，option input 'ACCEPT' 或 'REJECT'；入站策略是 REJECT 的区域，其隧道接口会拒绝管理连接，但如果允许转发，流量仍然会被转发出去。

不要为了让新路径生效就关掉防锁死规则。那条规则防的是一条坏规则把 LAN 管理地址锁在外面；它保护的是 LAN 网段，而不是你刚建好的隧道网段。给管理员来源加一条窄规则，把安全网留着。pfSense 的管理员访问文档说明了这些控制点在哪里。

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

第三层：那个地址上到底有没有东西在监听？

服务可能在运行，但由于只绑定了一个地址而仍然不可达。OpenWrt 的 uhttpd 在 /etc/config/uhttpd 里保留显式的监听条目，例如 list listen_http '0.0.0.0:80'；只绑定 LAN 地址的构建，在隧道地址上不接受任何连接，暴露监听接口设置的产品也是同样表现。上面那几条监听命令正好回答了这个问题。

然后把拒绝和沉默分开。nc -vz 10.6.0.1 443 返回连接被拒绝，说明包到了路由器、被某样东西拒绝了——要么端口没开，要么有一条明确的拒绝规则。一直挂到超时，说明包被丢了或者根本没被路由。这个区别告诉你下一步该查哪一层，而它只要五秒钟。

VPN 接口是边界，不是恢复通道

加密保护的是线上，它并不说明谁能打开管理页面。隧道通了之后，要顶住「在隧道接口上全放行」来解决可达性的冲动。给管理员一条绑定到他们自己隧道地址的规则，或者单独一条只管管理的隧道；普通人、NAS、摄像头和家里的笔记本都要离管理端口远一点。需要共享文件的对端，离路由器登录不该只差一条规则。

路由器的角色会改变答案。终结隧道的路由器可以从隧道里合法地接受管理员；只把隧道当出口用的路由器，通常就不该这么做。两种情况下，网段放行都不等于登录放行，所以账号认证和传输安全都要继续打开。

锁死之后人们常做的补救更糟：打开 WAN 管理，或者把端口转发到 Web 界面。这会把一次短暂故障变成永久暴露，登录页从此对互联网上每一台扫描器可见。被拒绝的一侧也要测，不只是允许的一侧——这样本不该有管理权限的对端才会拿到超时或拒绝，而不是登录提示。

还要用新连接测。有状态防火墙会把已有流保存在状态表里，所以你已经开着的 SSH 会话可以扛过一次阻止所有新连接的改动。锁死就是这样隐身到下一次重启、或者笔记本下一次睡眠为止的。

动策略之前，先备好回头路

第一次改动之前先写清四件事：隧道死掉时你怎么够到设备，例如串口控制台、服务商控制台或 LAN 里的机器；当前配置导出到哪里；你打算改的是哪一条规则或路由；以及你打算怎么把那个项目精确地放回去。OpenWrt 上 sysupgrade -b /tmp/backup.tar.gz 会接住配置，改动一直挂着直到 uci commit；如果你发现得及时，这就是一次便宜的撤销。pfSense 保留配置历史，AutoConfigBackup 只有在事先开启时才帮得上忙。如果路由器跑的是失败即关闭的规则集，请确认你计划的维护路径不在这条规则所阻断的流量里，并记住重启会重新套用持久规则，而不是把它们清掉。

每次只改一处边界，然后从新连接测，而不是从你开着的那个 shell 测。测试失败就先把那一处改动退回去，再去碰下一层。隧道可以一直亮着，但那盏绿灯不是你还进得去的证据。

离开前的快速检查：

  • 你能从一个不依赖刚改过的那条规则的来源够到路由器吗？
  • 隧道接口上的入站策略是否只允许管理员来源？
  • 管理服务是否绑定在隧道上确实存在的地址？
  • 你测过一个被拒绝的对端和一个新会话吗？
  • WAN 管理面还是关着的吗？

相关文章