云主机OpenWrt搭建全攻略：6步完成远程组网与旁路由部署

云主机OpenWrt常见的用途就两类：把分散在不同地点的设备拉进同一张逻辑网络，或者把家里熟悉的 OpenWrt 玩法放到公网环境里，做远程访问、旁路由中转和统一管理。和本地旧路由器相比，云主机有稳定公网入口，做异地组网、远程旁路由、流量转发会顺手很多。

但它也不是装完镜像就结束。家用路由器的思路搬到云上，经常会在网卡识别、子网划分、安全组、镜像兼容这些地方卡住。很典型的一种情况是，后台能登录，隧道也能握手，看起来都正常，设备之间就是不互通。问题往往不在某一个插件，而是前面的拓扑和规则没有理顺。

云主机OpenWrt适合哪些场景

云主机OpenWrt的价值，主要在于用云上的公网资源补家庭网络和小型办公网络的短板。常见场景有这几种。

• 异地组网：家里、办公室、出差设备通过 VPN 或隧道接进同一个逻辑网络，文件共享、设备管理都会直接很多。
• 远程旁路由：不改本地主路由结构，把部分流量交给云端处理，适合做转发、访问控制或临时中转。
• 统一出口管理：多个地点的终端走同一套策略，方便控制访问范围，也方便排障。
• 内网服务暴露：配合端口映射、反向代理或隧道，把 NAS、监控、开发环境放到可控的访问入口后面，避免直接暴露出去。
• 测试和学习：云主机能模拟更接近公网的路由环境，拿来练防火墙、策略路由、VPN 配置，比只在局域网里折腾更有参考价值。

如果只是偶尔远程桌面，未必非要上 OpenWrt。但要长期做多地互联，还希望把访问路径、权限和流量策略收拢到一个节点上，云主机OpenWrt就很合适。

部署前先看清这4件事

镜像能不能跑得起来

不是所有 OpenWrt 镜像都适合直接装到云主机。要先确认云平台支持什么启动方式，比如 KVM、Xen，或者是否允许导入自定义镜像。稳妥一点，优先选 x86_64 通用镜像，并确认里面带常见云环境网卡驱动。很多人一开始省这一步，后面就会遇到实例能开机、接口却认不全的问题。

拓扑先简后繁

比较省事的结构，是把云主机当中心节点，各地设备通过 WireGuard、OpenVPN 之类的方式接入，再用静态路由或策略路由实现互访。新手别急着堆多出口、双栈、多层分流，先让一台云主机和两三个客户端稳定互通。这个“小闭环”跑通以后，再加 DNS、分流规则，故障范围会小很多。

安全组和防火墙要一起看

OpenWrt 管理后台不能直接裸露在公网，这是底线。至少要做三件事，改默认管理地址、限制管理端口来源、用强密码或密钥认证。还要记住，云平台安全组和 OpenWrt 自己的防火墙是两层规则，少放一层都可能不通，多放一层也可能把自己锁在外面。改规则前留一个控制台入口，出问题还能救回来。

资源别只看能不能开机

轻量用途 1 核 1G 一般能启动，但如果还要跑多个隧道、DNS、策略路由和日志，2 核 2G 会稳妥不少。带宽方面，远程组网更看稳定性和上下行是否均衡。低配实例常见的情况是，VPN 一跑起来单核占满，延迟和吞吐一起掉。

云主机OpenWrt 6步部署方法

第1步：选云平台和实例规格

优先选支持自定义镜像、控制台管理、安全组配置的平台。过于受限的机型看着便宜，真装起来可能连镜像都导不进去，或者网卡模式不兼容，后面反复重建比省下来的那点成本更折腾。

第2步：准备 OpenWrt 镜像

下载稳定版 x86 镜像，提前确认云平台需要什么格式，必要时做 raw 转 qcow2 之类的转换。社区编译版插件多，用起来很省事，但正式环境别只看功能列表。兼容性、升级稳定性和安全更新，往往比“预装了多少插件”更值得优先考虑。

第3步：导入并启动实例

镜像导入后，第一次开机先别急着装插件，先看网卡识别。很多镜像在本地虚拟机里正常，到了云环境接口名称和顺序会变。启动后通过控制台检查 WAN、LAN 绑定是否正确，至少先确认你能稳定进后台，不会一改网络就失联。

第4步：完成基础网络配置

管理口设固定地址，确认默认网关和 DNS 正常。云平台如果是单网卡模式，往往要把同一物理接口拆成不同逻辑用途，再配合防火墙分区做访问控制。这里很容易出错，因为云主机没有家用路由那种天然的 WAN/LAN 物理分离。配置前先画个简单拓扑图，谁接入、谁转发、谁只允许管理。图没画清，规则基本也会乱。

第5步：配置 VPN 或隧道

异地互联更常见的选择还是 WireGuard，配置相对直接，对轻量云主机也比较友好。密钥交换、地址规划、AllowedIPs、路由下发这些项目不要跳着做。一个实用顺序是先测点对点能不能通，再测跨网段访问，最后测 DNS 解析和业务端口。握手成功不代表业务已经能跑，很多问题都卡在路由或转发上。

第6步：加固和监控

没必要开的服务直接关掉，管理入口限制来源 IP，日志和备份要尽早配好。长期使用的话，配置文件、密钥、防火墙规则最好有版本化管理习惯。哪怕只是手动留存多个备份，也比后面扩容时靠记忆回配强得多。

一个能落地的部署案例

以一个小型工作室为例，有 1 个办公室，2 名经常在外的成员，家里还有 NAS 需要偶尔访问。办公室宽带没有固定公网 IP，家庭网络地址也经常变化，直接做传统端口映射，稳定性很差。这种情况下，云主机OpenWrt就比各地单独折腾更省心。

做法是准备一台 2 核 2G 的云主机，安装 OpenWrt 作为中心节点；办公室软路由、两名成员的笔记本客户端，通过 WireGuard 接入；家中 NAS 所在的旁路由也接进同一条隧道。云端 OpenWrt 负责分配虚拟网段、下发路由，同时用防火墙限制只有特定成员能访问 NAS 管理端口。

这样部署后，几个变化会很明显。

• 外出成员能直接访问办公室文件服务器，不需要临时找一台机器远程桌面再中转。
• 家里的 NAS 可以被访问，但管理端口没有直接暴露到公网。
• 新增设备时，只要导入配置接入隧道，不用反复去改多个地点的路由器设置。
• 出故障时，日志、路由、连接状态都集中在云端 OpenWrt，排查路径短很多。

这个方案好用，直接原因是网络中枢固定下来了，地址在这里统一，策略在这里统一，权限也在这里统一。对个人开发者、小团队、异地家庭网络，这种结构很容易复制。

常见问题和避坑提醒

能进后台，但终端互相访问不到

这种情况很常见，先别急着怀疑 OpenWrt 本身。一般就查三层，隧道是否握手成功、路由表是否正确下发、转发规则和云平台安全组是否放通。有时候 OpenWrt 里全开了，结果安全组没放行；也有时候安全组没问题，但内核转发没开或者防火墙区域没配对。

速度不理想

先看 CPU。低配云主机跑 VPN，很容易单核打满。再看 MTU，MTU 不合适时，现象往往不是完全断，而是能连、也能 ping，文件传输和网页加载却很慢。这个问题尤其容易在跨运营商或多层隧道场景里出现。

升级后规则异常

OpenWrt 大版本升级可能带来插件依赖变化、防火墙语法变化，自定义脚本多的时候尤其明显。正式环境别直接在线升级，先备份，再做测试验证。能重建的配置，尽量整理成可复用的记录，别把环境全押在一台正在运行的实例上。

只顾装插件，没做规划

这是新手最容易走偏的地方。插件多不等于方案完整。地址段怎么分、哪些设备能互访、哪些端口只给谁开放、默认流量走哪里，这些问题不提前定下来，后面插件越多，规则越乱。

适合新手的精简实施建议

1. 先把目标写清楚，是远程访问、异地组网，还是旁路由中转。目标不同，拓扑和规则差很多。
2. 先搭最小结构：1 台云主机OpenWrt加 2 个客户端，别上来就接办公室、家里、手机、NAS 一起测。
3. 先用 WireGuard 跑通互访，再补 DNS、分流和访问控制。业务一层层加，比一次堆满好排查。
4. 管理后台只允许固定 IP 访问，改防火墙规则前确认控制台还能进，避免把自己关在门外。
5. 每改一次规则就做备注和备份，尤其是地址规划、AllowedIPs、防火墙区域和静态路由，后面回滚会省很多事。

云主机OpenWrt适合把公网入口、远程接入和策略控制集中到一个可维护的节点上。前期把镜像兼容、网络拓扑和安全边界想清楚，后面扩展多地站点、DNS 服务、反向代理、策略路由都会顺很多。经验也就一句话：先跑通，再优化。起步阶段结构越简单，后续越稳。