用独立网关 + 路由器搭建全屋 VPN：原理与配置详解
-
用独立网关 + 路由器搭建全屋 VPN：原理与配置详解
目录一、为什么要做一个独立的 VPN 网关
把 VPN 部署在终端设备上是最常见的方式，但缺点明显：每台设备都要装客户端，手机、电视、游戏机、智能家居设备未必都支持；切换网络环境时容易忘记开启；多设备订阅成本高。
把 VPN 跑在路由器上是个进步，但又遇到新问题：消费级路由器的 CPU 性能弱，跑加密算法时算力跟不上，常见的现象是宽带 1000M、走 VPN 后只剩一两百兆；而且路由器的固件修改空间有限，调试困难。
更彻底的方案是把 VPN 抽离出来交给一台独立的 Linux 主机——可以是闲置的旧电脑、迷你主机、NUC、甚至是树莓派（视带宽要求而定）。这台机器作为整个局域网通往互联网的唯一出口，负责加密封装；后面再接一台普通路由器负责 WiFi 与局域网。
这种架构不依赖任何特定的 VPN 服务商，也不依赖特定的协议。WireGuard、OpenVPN、IKEv2/IPsec、甚至 Shadowsocks/Trojan 这些代理协议，原理都一样：在 Linux 网关上把出网流量封装加密，统一从一个出口送出。
二、整体架构与各层职责
完整的数据路径是：终端设备 → 下游路由器（管 WiFi 和 LAN）→ 上游 Linux 网关（管 VPN 加密与出口）→ VPN 服务器 → 真正的互联网。响应原路返回。
每一层只做一件事，这是整个方案最重要的设计原则。
下游路由器负责的是局域网层面：发射 WiFi 信号，分配内网 IP，处理设备之间的二层交换，运行简单的本地防火墙。它不需要知道 VPN 的存在，对它来说，"互联网"就是它 WAN 口连上的那台 Linux 机器。
上游 Linux 网关负责的是出口层面：接收下游送来的所有出网流量，决定哪些走 VPN、哪些不走，做 NAT 地址转换，运行 kill switch 防火墙规则，处理 DNS。它不关心局域网里有几台设备、谁在用 WiFi。
两者之间那根网线上传的是未加密但已经路由完毕的普通 IP 包。加密发生在上游网关的虚拟网卡里，下游路由器和那段网线都看不到加密细节。
这种分层让排错变得简单：如果 WiFi 不稳定，问题在下游路由器；如果 VPN 速度慢或掉线，问题在上游网关；如果某台设备拿不到 IP，问题在 DHCP；如果能上网但泄漏真实地址，问题在 DNS 或防火墙规则。每一层独立排查，不会牵一发动全身。
三、网段划分：为什么必须不同
网络新手最容易栽跟头的地方就是网段冲突。
一个子网（subnet）是一组可以直接通过二层（以太网/WiFi）通信的设备，它们共享相同的 IP 前缀和广播域。子网内的设备之间不需要"路由"，只需要"交换"。子网之间则必须通过路由器进行三层转发。
如果上游网关用
192.168.1.0/24，下游路由器的 LAN 也用192.168.1.0/24，会发生什么？下游路由器会困惑：它收到一个目标地址是192.168.1.50的包，这个地址在它自己的 LAN 段里也合法，在 WAN 段里也合法，应该送到哪边？路由表里会出现矛盾条目，ARP 缓存会错乱，结果是大量丢包、设备时断时续。正确做法是让两层使用完全不同的网段，最常见的搭配是：上游用
192.168.100.0/24，下游用192.168.1.0/24。或者上游用10.0.0.0/24，下游用192.168.50.0/24。具体数字不重要，重要的是两段不重叠。下游路由器的 WAN 口会从上游 DHCP 拿一个
192.168.100.x的地址（或手工配置静态），这是它"对外"的身份。它的 LAN 侧继续用192.168.1.x，那是它自己的小世界。两个世界之间通过路由器内部的路由表沟通——这才是 IP 网络设计的本意。顺便说一句，避开
192.168.0.0/24和192.168.1.0/24这两个最常见的默认段，可以减少出门在外用别人 WiFi 时与对方网段冲突的概率。四、VPN 隧道的工作原理
VPN 这个词被滥用了，本质上它就是一种加密封装机制。
设想你要寄一封信，但不想让邮局看到内容。你把这封信装进一个上锁的箱子里，箱子上写着另一个收件人地址（你的盟友）。邮局只看到箱子在你和盟友之间往来，看不到里面的信。盟友收到后开锁取信，再按原信上的地址转寄。这就是 VPN 的工作模式。
具体到数据包层面：当一个普通 IP 包（比如访问网站的 HTTPS 请求）到达上游网关时，VPN 软件不会让它直接出网，而是把整个原始包当作"载荷"，加上加密算法（不同协议用不同算法，但都基于现代密码学：对称加密、非对称密钥交换、消息认证码），再封装到一个新的 UDP 或 TCP 包里。这个新包的目标地址是 VPN 服务器的公网 IP。
ISP 看到的只是你和 VPN 服务器之间持续的加密流量，看不到里面包了什么、访问了什么网站。这就是"隧道"的含义——在公开的网络上挖出一条只有两端能解读的私密通道。
不同协议的差别主要在：加密算法的选择、握手方式的复杂度、对网络条件的容忍度、对抗深度包检测（DPI）的能力。但对路由配置来说原理完全一样：VPN 软件会在系统里创建一个虚拟网卡，把它当成"通往互联网的出口"使用。原始包通过路由表被引导到这个虚拟网卡，进去之后被加密封装，再从物理网卡发出去。
理解这一点之后，"挂 VPN"这件事就不再神秘——它只是把系统的默认路由从"物理网卡"改成"虚拟网卡"，加上一些必要的策略路由，让 VPN 自己的握手流量例外走物理网卡。
五、MTU：被忽视的关键参数
MTU（Maximum Transmission Unit）是一个数据包在不被分割的情况下能在物理链路上传输的最大字节数。以太网的标准 MTU 是 1500 字节。
VPN 封装会带来一个数学问题。任何 VPN 协议都要在原始包前面加上自己的头部信息：外层 IP 头（20 字节）、UDP 或 TCP 头（8 或 20 字节）、协议自身的认证与加密元数据。WireGuard 大约要加 60-80 字节，OpenVPN 视配置不同要加 40-100 字节，IPsec 大约 50-80 字节。
如果内网设备仍然按 1500 字节构造数据包，加上封装后就超过了物理链路的 1500 上限，必须被分片（fragmentation）传输——拆成两个小包发送，对端收到后再重组。
分片本身是 IP 协议允许的，但有几个实际问题：分片增加 CPU 开销和延迟；很多防火墙和中间设备会丢弃分片包；最致命的是 PMTUD（路径 MTU 发现）依赖 ICMP 消息，而很多网络运营商把 ICMP 全部屏蔽，导致发送方永远收不到"包太大"的反馈，形成所谓的 PMTUD 黑洞。
症状非常诡异：能 ping 通、能打开网页文字部分（小包），但图片加载不出来、视频卡死、SSH 输入命令就断（大包）。新手遇到这种问题往往会怀疑 VPN 服务、网线、运营商，但其实只是 MTU 没设对。
解决方法是主动把下游接口的 MTU 调小，让内网设备从一开始就构造较小的包。常见经验值：WireGuard 用 1420，OpenVPN 用 1400，IPsec 用 1400-1438。这样原始包加上封装恰好不超过 1500，无需分片，全程畅通。
更激进的做法是在路由器上启用 MSS clamping（钳制 TCP 最大分段大小）。MSS 是 TCP 三次握手时双方协商的"我能接收的最大段大小"，路由器可以在握手包经过时偷偷把这个值改小，强制对方发送更小的包。这种方法对 TCP 流量非常有效，对 UDP 无效（UDP 没有协商机制），但 UDP 应用通常自己会处理 MTU 问题。
在路由器配置层面，MTU 设置通常出现在 WAN 接口的高级选项里，写入一个比 1500 小的具体数值即可。
六、DNS：加密之外的隐私漏洞
VPN 加密了数据内容，但很多人忽略了一个事实：DNS 查询是访问任何域名的前置动作，如果 DNS 没走 VPN，隐私仍然在泄漏。
当你输入一个网址，浏览器先要问 DNS 服务器："这个域名对应哪个 IP？"如果这一步用的是 ISP 默认 DNS，那么 ISP 完全知道你访问了什么网站，即便后续真实数据它看不到也没关系——访问记录已经留下了。这就是 DNS 泄漏（DNS leak）。
更细微的泄漏场景：操作系统或某些应用绕过系统 DNS 设置，直接硬编码用 Google
8.8.8.8或 Cloudflare1.1.1.1。即便这些查询经过 VPN 加密出了网（不会被 ISP 看到），但等于告诉这些大型 DNS 服务商"有人问了这些域名"。如果你重视隐私，这同样是泄漏。最稳妥的做法分三层处理。
第一层：上游 Linux 网关自己使用 VPN 服务商提供的 DNS，或者使用经 VPN 出口的可信 DNS（比如 Quad9、AdGuard、自建 DoH/DoT）。VPN 服务商通常在隧道内部提供一个私有 IP 的 DNS，只有连进隧道才能访问，外部完全无法触及。
第二层：下游路由器的 WAN DNS 也指向同一个 DNS 地址，而不是依赖 ISP 自动下发的 DNS。这一步在路由器的 WAN 配置里完成——把 DNS 模式从"自动"改为"手动"，填入指定的 DNS 服务器地址。
第三层：路由器通过 DHCP 下发给客户端的 DNS 也要是同一个，确保连入 WiFi 的每台设备都用相同的 DNS。这个设置通常在路由器的 LAN/DHCP 部分，有的固件叫"DHCP DNS"，有的需要在 dnsmasq 自定义配置里写明。如果这一层配错，客户端可能直接去问公网 DNS，前面两层就白做了。
更进一步，可以在路由器上启用 DNS 拦截（DNS interception）规则：把所有目标端口为 53 的出站流量强制重定向到路由器自己的 DNS。这样即便某个 App 硬编码了别的 DNS 地址，流量也会被透明劫持到指定 DNS。这是对抗"流氓 App"DNS 泄漏的终极手段。
七、Kill Switch：VPN 掉线时的保险
VPN 不是 100% 可靠的。服务器维护、网络抖动、密钥过期、路由变化都可能导致隧道短暂中断。如果不做防护，这段时间内系统会自动 fallback 到物理网卡直连，所有流量裸奔，真实 IP 暴露。
Kill Switch（断网开关） 的作用就是：一旦 VPN 掉线，立刻切断所有非 VPN 流量，宁可断网也不裸连。
它的实现完全依赖防火墙规则，没有什么魔法。基本逻辑是：默认禁止所有流量从物理网卡出网；只允许 VPN 自身的握手流量（去往 VPN 服务器的特定 IP 和端口）通过物理网卡——这是建立隧道必需的；允许所有流量从 VPN 虚拟网卡出网；允许从 VPN 虚拟网卡接收返回流量。
当 VPN 正常时，转发表里有指向虚拟网卡的路由，流量正常加密出去。当 VPN 断了，虚拟网卡消失或被标记为不可用，路由失效，防火墙的"默认禁止"规则生效，所有流量被丢弃。表现为内网设备"断网"——这正是想要的效果，让用户立即察觉异常并修复，而不是悄悄裸连。
更严格的版本会加上反向路径过滤和严格的入站限制：物理网卡只接收来自 VPN 服务器的回包，其他来源一律丢弃。这能防止某些罕见的攻击场景。
在 Linux 网关上，Kill Switch 通过 iptables 或 nftables 实现，是几条静态规则的组合，开机自动加载。在路由器上，类似的功能有时通过"VPN 失败时阻断 WAN"的勾选项实现，原理一样。
八、NAT 与双层 NAT 的取舍
NAT（Network Address Translation，网络地址转换）是私网通往公网的桥梁。私网地址（
192.168.x.x、10.x.x.x、172.16-31.x.x）在公网上不可路由，必须经过 NAT 转换为路由器的公网 IP 才能与外界通信。响应回来时再反向转换。这个架构里有两次 NAT。下游路由器把
192.168.1.x转成它 WAN 口的192.168.100.2，上游网关再把192.168.100.x转成 VPN 隧道内的地址（最终在 VPN 服务器上又做一次 NAT 转成公网 IP）。NAT 每多一层，"从外网主动连进内网"就多一层障碍。对纯消费场景（浏览、视频、下载、聊天）完全无感；但对需要内网穿透的场景——P2P 游戏联机、BT 做种、远程访问家里的服务器、IP 摄像头远程查看——双 NAT 会让端口转发变得繁琐：必须在两层都打洞，且打洞规则要一致。
如果有这类需求，有几种思路可选。一是桥接模式：下游路由器关闭 NAT，纯做无线接入点，所有设备直接从上游网关 DHCP 拿地址。结构简化为单层 NAT，但失去下游路由器的独立防火墙和 DHCP 控制。二是保留双 NAT 但配置端口转发链：在上游网关把某端口转发到下游路由器 WAN，再在下游路由器把同一端口转发到目标设备。三是用支持 UPnP 的协议：让 P2P 应用自动协商打洞，但这需要两层路由器都启用 UPnP，安全性略低。
家用场景一般推荐保留双 NAT 的简单架构，需要穿透的少数服务再单独配置。这是简单性与功能性的平衡。
九、局域网内部通信完全独立
一个容易被忽视但非常重要的事实：LAN 内部设备之间的通信，完全不经过 VPN，也不经过上游网关。
手机投屏到电视，数据从手机走 WiFi 到下游路由器，路由器的交换芯片直接转发到电视，全程在二层完成。路由器都不需要查路由表，更不会把这种流量送到 WAN 口。VPN 在这个过程中完全不存在。
这意味着：局域网速度永远是 WiFi 或有线的满速，不受 VPN 速度影响；AirPlay、Chromecast、DLNA、SMB 共享、HomeKit、Matter、mDNS 这些依赖二层广播或组播的协议全部正常工作；打印机、智能音箱、摄像头之间互相发现不受任何干扰；局域网游戏联机（Switch、PS5 本地、Minecraft LAN）完全可用。
VPN 只在"需要出网"时介入，对内网生态毫无干扰。这是路由层面 VPN 的优雅之处——它扮演的是"出入境海关"的角色，只检查跨境的行李，不管你在国内怎么走动。
要实现这一点，下游路由器需要保证两件事：所有 LAN 设备在同一个桥接接口（通常叫 br0 或 LAN bridge）下，这样它们二层互通；不要启用 AP isolation（AP 隔离），那个功能会强制隔离 WiFi 客户端，破坏内网互访。默认配置一般就是对的，除非特意开启了访客网络才需要注意。
十、路由器的关键配置项详解
理解了原理后，看路由器界面就清晰了。无论是 OpenWrt、FreshTomato、还是其他第三方固件，核心配置项都是这几类。
WAN 接口配置决定路由器如何"对外"。类型选 DHCP 还是静态，取决于上游是否提供 DHCP 服务。如果上游是另一台路由器或带 DHCP 的网关，DHCP 自动获取最省事；如果上游是裸 Linux 主机没装 DHCP 服务器，只能配静态 IP，手工填地址、子网掩码、网关、DNS。MTU 通常默认 1500，需要根据 VPN 协议手动调小到 1420 或 1400。DNS 模式建议设为手动，明确指定要用的 DNS 服务器，避免被 ISP 或上游覆盖。
LAN 接口配置决定内网长什么样。IP 地址是路由器在 LAN 里的身份，也是所有内网设备的网关。子网掩码通常
255.255.255.0（即 /24，最多 254 台设备）。如果家里设备特别多可以扩到 /23 或更大。这个 IP 段必须与 WAN 段不同，这是前面强调过的核心原则。桥接配置（Bridge / br0）决定哪些接口属于同一个二层网络。默认所有 LAN 网口和 WiFi 都桥接在 br0 上，所有连入设备彼此可见。如果想做 VLAN 隔离（比如访客网络与主网分开），需要建立第二个桥接，并配置 VLAN tagging。
DHCP 服务器配置决定怎么给客户端分配地址。地址池范围（IP Range）定义起止 IP，留出一部分静态保留段给固定设备（NAS、打印机等）。租期（Lease Time）决定客户端多久续约一次，家用一般 24 小时（1440 分钟）足够。下发的网关默认是路由器自己，下发的 DNS 默认也是路由器自己——但这里有个关键决定：路由器是要让客户端用自己作为 DNS 中继，还是直接下发外部 DNS 给客户端？前者灵活，可以在路由器层面统一管理 DNS；后者直接，少一层中转。多数情况推荐前者。
DNS 转发配置通常由 dnsmasq 之类的服务承担。路由器自身收到客户端的 DNS 查询，转发给上游 DNS（VPN 服务商的 DNS 或 Mullvad/Quad9 等），把结果返回客户端。可以在这里加缓存提升速度，也可以加自定义 DNS 记录（比如给内网设备起本地域名）。如果用了非标准 DNS，要注意关闭"DNS rebinding 防护"或加白名单，否则解析到私有 IP 的域名会被拦截。
防火墙配置默认应该是：禁止 WAN 主动连入 LAN（保护内网），允许 LAN 主动出 WAN（正常上网），允许已建立连接的回包。这是最基础的状态化防火墙模型。如果要做端口转发，在这里添加 NAT 规则：把 WAN 口某端口的流量转发到 LAN 内某 IP 的某端口。
无线配置与 VPN 无关，但要确保 WiFi 在桥接上、加密用 WPA2 或 WPA3、关闭 AP isolation（除非做访客网络）、信道选择避开拥堵频段。MTU 在无线层面通常不需要单独设，跟随 LAN 的 MTU 即可。
十一、操作顺序与排错思路
配置时的顺序很关键，搞反了会把自己锁在外面。
合理的顺序是：先配下游路由器的 LAN 段（改成与 WAN 不冲突的网段），保存重启；用新地址重新登录路由器（注意此时电脑也要重新拿新段的 IP）；再配 WAN 接口，选 DHCP 或静态，设好 MTU 和 DNS；配 DHCP 下发的 DNS；最后接上上游网关，测试连通性。
排错时按数据流方向逐层验证。先确认下游路由器能 ping 通上游网关（说明 WAN 配置正确）；再从路由器后台 ping 通公网某个 IP（说明上游网关在转发）；再从路由器解析某个域名（说明 DNS 工作）；再从客户端做同样的测试。每一步失败都对应特定层的问题，不用瞎猜。
最后用 VPN 服务商提供的检测页面（或 ipleak.net、dnsleaktest.com 这类第三方工具）确认：显示的公网 IP 是 VPN 服务器的 IP（不是真实 IP）；DNS 服务器是 VPN 提供的 DNS（不是 ISP 或 Google）；没有 WebRTC 泄漏（这个属于浏览器层面，与路由配置无关，但同样重要）。
十二、总结
搭建一个家用 VPN 网关的本质，是用清晰的职责分离把一件复杂的事拆成几个简单的事：上游 Linux 网关专职加密与出口；下游路由器专职 WiFi 与局域网；分层网段划清边界，避免冲突；明确的 DNS 策略防止隐私泄漏；严格的防火墙规则提供最后一道保险。
理解了这些原理，配置就不再是照抄教程，而是有意识的选择。换一个 VPN 协议、换一个路由器固件、换一种网络拓扑，思路完全可以迁移。具体的命令和按钮位置只是表象，背后的逻辑——在何处加密、在何处路由、在何处过滤、在何处分配地址——是不变的。
这种架构的好处也不限于"翻墙"或"科学上网"的语境。在企业里，它叫 site-to-site VPN；在远程办公里，它叫 zero trust gateway；在隐私保护里，它叫 privacy router。形式各异，骨架相同：一个独立的、专注的、可审计的网络出口，永远比把功能塞进每台设备里更可靠、更可控、更容易理解。
-
0 回复
歡迎留言回复交流。
Log in to reply.