只有虚拟机服务器的资源的上云实现联机

阿拉德流云

一篇如何用单机版资源上云实现联机的通用攻略。
本攻略适用于有可用的AI agent并有一定动手能力的玩家。
单机版本资源一般服务器一般是以虚拟机的形式发布，所以要想上云联机就要解决核心的两点：
vmware到云服务器平台迁移
客户端或服务端写死的局域网ip 192.168.200.131
具体来说解决这两点最重要的工具： 一个 AI agent，可以是claude code（推荐），也可以是codex或者openclaw之类任选。AI后端模型能力越强越好。
因为楼主在美国，所以这里我以 claude code + 谷歌云 + 85璀璨资源为例花了一下午成功迁移上云可以联机，并保留本地之前已经有的数据库
下面回复AI总结的流程文档
用 AI 把 DNF 私服搬上云 —— 从单机虚拟机到多人联机的完整攻略
本帖记录了我用 Claude Code (AI 编程助手) 辅助，把本地 VMware 上跑的 DNF 私服搬到 Google Cloud 的全过程。
搬完之后朋友不用装虚拟机，只需要运行一个 Python 脚本就能联机。
全程大概花了一个晚上，绝大部分操作都是 AI 帮我做的。
为什么要上云？
- 本地虚拟机只能自己玩，朋友想联机得各自装虚拟机，麻烦
- 云服务器大家都能连，延迟也还行（选离玩家近的机房）
- Google Cloud 新用户有 $300 免费额度，够用好几个月
需要准备什么？
- 一个能正常运行的 DNF 私服虚拟机（VMware）
- Google Cloud 账号（或其他云平台）
- Python 3（玩家电脑上要装）
- AI 编程助手（我用的 Claude Code，也可以用 Cursor、GitHub Copilot 等）
- Windows 上装一个 Loopback 虚拟网卡
整体思路
原来: 本地 VMware 虚拟机 → 只能自己玩
现在: 云服务器 (GCP) 玩家电脑
┌─────────────┐ ┌──────────────┐
│ DNF 服务端 │←── 隧道 ───→│ 隧道客户端脚本 │
│ (从VM迁移过来) │ (单个端口) │ ↑ │
└─────────────┘ │ DNF 客户端 │
└──────────────┘
核心就三步：
1. 把虚拟机磁盘搬到云上
2. 修好各种兼容性问题让它能启动
3. 写一个隧道程序让玩家能连上来

DNF

第一步：导出虚拟机镜像
VMware 虚拟机的磁盘是 VMDK 格式，云平台要 raw 格式。
我跟 AI 说： "帮我把这个 VMware 虚拟机迁移到 GCP"
AI 给出了转换流程：
VMDK → (qemu-img) → raw → (tar打包) → 上传到云存储 → 创建云端镜像
具体命令 AI 都帮我生成了，我只需要等它跑完。转换 + 上传大概花了 1-2 小时（看网速）。
踩坑提醒：
- 如果虚拟机有快照，要先合并
- tar 打包时 GCP 要求用 oldgnu 格式，不然创建镜像会失败
- 上传 4GB 的压缩包到 GCS 要看你的上传带宽
第二步：让虚拟机在云上能启动
这是最折腾的一步。VMware 用的虚拟硬件和云平台不一样，直接启动大概率卡住。
我跟 AI 说： "虚拟机在 GCP 上启动不了，卡在 Booting from Hard Disk"
AI 分析出了几个需要修复的问题：
| 问题 | 原因 | AI 的修复方案 |
| 启动卡住 | GRUB 引导方式不兼容 | 改 grub.cfg (linuxefi → linux16) |
| 没有网络 | 网卡名变了 (ens33 → eth0) | 改内核参数 + 网卡配置文件 |
| 磁盘驱动缺失 | 缺少 virtio 驱动 | 重建 initramfs |
修复方式是创建一个临时的"帮手VM"，把坏掉的磁盘挂上去离线修复，改完再换回去。这些操作全程 AI 帮我通过 SSH 执行。
踩坑提醒：
- GCP 用 SeaBIOS，不支持 UEFI 启动项
- 要加 console=ttyS0 到内核参数，不然串口控制台看不到输出，出了问题都不知道卡哪了
- CentOS 7 的 OpenSSH 太老 (6.6.1)，只认 ECDSA 密钥，ed25519 和新版 RSA 都不行
第三步：配置网络
DNF 服务端硬编码绑定在 192.168.200.131，云服务器的内网 IP 肯定不是这个。
我跟 AI 说： "游戏服务绑定在 192.168.200.131，但云服务器 IP 不一样"
AI 的方案：在网卡上加一个 IP 别名 + iptables 做 DNAT 转发，写成开机自启动脚本。
第四步：写隧道程序（重点！）
这是整个方案最巧妙的地方。正常做法是在云服务器防火墙上开放所有游戏端口（十几个），但这样：
- 不安全
- 不好调试
- 端口多了防火墙规则也复杂
我跟 AI 说： "我觉得更好的方式是只开一个端口用于通信，写一个程序解析数据然后转发给内部服务"
AI 直接帮我写了一套隧道系统：
服务端 (tunnel_server.py) —— 跑在云服务器上：
- 监听单个端口 (10800)
- 接收客户端的隧道数据
- 根据协议头解析出目标端口
- 转发到内部的游戏服务
客户端 (tunnel_client.py) —— 跑在玩家电脑上：
- 在本地 192.168.200.131 上监听所有游戏端口
- 游戏客户端连接到本地 IP 时，通过隧道转发到云服务器
- 退出时自动清理
自定义了一个简单的二进制协议：
[类型 1B][端口 2B][连接ID 4B][数据长度 2B][数据...]
支持 TCP 连接/数据/关闭 和 UDP 数据转发，所有游戏流量都走一条 TCP 连接。
后来我又让 AI 加了 HMAC-SHA256 认证，防止别人扫到端口乱连。
防火墙只需要开 2 个端口： SSH(22) + 隧道(10800)
第四步：玩家怎么连？
1. 装 Python 3
2. 装一个 Windows Loopback 虚拟网卡（设备管理器 → 添加过时硬件 → Microsoft Loopback Adapter），重命名为 "Loopback"
3. 以管理员身份运行：
python tunnel_client.py <服务器IP>
4. 正常打开游戏客户端就能玩了
5. 不玩了 Ctrl+C 退出，脚本会自动清理
AI 帮了哪些忙？
说实话，整个过程中 90% 的技术工作都是 AI 做的：
自动做的：
- 生成所有 shell 命令和脚本
- 通过 SSH 远程执行命令（配网络、改配置、装软件）
- 写隧道程序（服务端 + 客户端，200+ 行 Python）
- 排查各种启动失败、网络不通的问题
- 处理 Python 2/3 兼容性（服务器上只有 Python 2.7）
- 管理 GCP 资源（创建/删除 VM、磁盘、快照、防火墙规则）
我做的：
- 提需求和思路
- 在 VMware 里准备好虚拟机
- 安装 Loopback 网卡
- 启动游戏服务（./run）
- 测试游戏是否正常
基本上我只需要描述我想要什么，AI 就能帮我实现。遇到问题也是 AI 自己分析日志然后修复。
总结下来如果你想复现这套流程，把这个帖子的内容给你的AI agent看，然后准备好资源让AI干就完事了
本文转自：https://tieba.baidu.com/p/10544247937?fr=frs