# 腾讯云 Debian 12 装 KVM + Proxmox VE：不断网操作手册

> **适用场景**：腾讯云 CVM / 轻量应用服务器（公网 IP 为 NAT 映射），Debian 12。
> **本文档来源**：2026-09-14 在 `114.132.244.13` 上的真实执行记录，桥接切换**零断网**通过。
> **文档目标**：让"改远程服务器网络"这件事，从"赌运气"变成"有兜底的工程操作"。

---

## 目录

- [0. 一页速查（下次直接照做）](#0-一页速查下次直接照做)
- [1. 结论先行：桥接到底会不会断网](#1-结论先行桥接到底会不会断网)
- [2. 原理：为什么腾讯云桥接可以不断网](#2-原理为什么腾讯云桥接可以不断网)
- [3. 四个高危点（比桥接更危险的三个）](#3-四个高危点比桥接更危险的三个)
- [4. 不断网的四层保险（核心方法论）](#4-不断网的四层保险核心方法论)
- [5. 完整操作流程（六步）](#5-完整操作流程六步)
- [6. netguard 看门狗详解](#6-netguard-看门狗详解)
- [7. 高危操作检查清单](#7-高危操作检查清单)
- [8. 故障处置手册](#8-故障处置手册)
- [9. 附录](#9-附录)

---

## 0. 一页速查（下次直接照做）

### 0.1 前置检查（三件事，缺一样别动手）

| 检查项 | 怎么查 | 本轮结果 |
|---|---|---|
| **有控制台 VNC** | 腾讯云控制台 → 实例 → 登录 → VNC 登录 | ✅ 有。这是终极兜底，必须先确认 |
| **SSH 能直连** | 本机 `nc -vz <IP> 22` | ✅ 通 |
| **公网 IP ≠ 网卡 IP** | 进机器 `curl ifconfig.me` 对比 `ip -4 addr` | ✅ `114.132.244.13` vs `10.1.24.4` → 说明是 NAT |

### 0.2 六步流水（复制即可）

### 0.3 出事怎么办（三句话）

1. **SSH 断了**：先别慌，等 **5 分钟**——netguard 会自己回滚。回来看 `/var/log/netguard.log`。
2. **5 分钟后还没好**：上**腾讯云控制台 → VNC 登录**，跑 `/usr/local/sbin/netguard.sh rollback`。
3. **要全部还原**：见 [8.4 完全撤销](#84-场景-d想把机器还原成没装过) 。

---

## 1. 结论先行：桥接到底会不会断网

> **不会。至少在腾讯云上不会——只要做对一件事：让 `br0` 显式沿用原网卡的 MAC。**

本次实测数据：

| 指标 | 切换前 | 切换后 |
|---|---|---|
| 内网 IP | `10.1.24.4/22` | `10.1.24.4/22`（**没变**） |
| 出口公网 IP | `114.132.244.13` | `114.132.244.13`（**没变**） |
| MAC | `52:54:00:d7:a0:cc` | `52:54:00:d7:a0:cc`（**没变**，现在在 br0 上） |
| 切断时长 | — | **0 秒** |
| 切换耗时 | — | `ifreload` 2 秒 + 自检 9 秒 |

本机侧独立探活（每 15 秒探一次 22 端口，跑满全程）：**零 DOWN 记录**，延迟稳定 115ms。

---

## 2. 原理：为什么腾讯云桥接可以不断网

### 2.1 腾讯云的网络模型

 │
 ▼

 │

 │

 │

关键点：**公网 IP 是 NAT 映射到内网 IP 的，而 DHCP 是按 MAC 分配内网 IP 的。**

### 2.2 桥接不断网的充要条件

Linux bridge 有个特性：**创建时会继承第一个加入端口的 MAC**。

所以桥接时只要显式写死：

bridge-ports eth0
hwaddress ether 52:54:00:d7:a0:cc   # ← 这一行是命脉

效果链条：

  → 腾讯云 DHCP 看到"同一个 MAC"
  → 发回"同一个内网 IP" 10.1.24.4
  → NAT 映射的对应关系完全不变
  → 公网 IP 照旧，SSH 照旧

**从云平台视角看，这根本不叫"换网卡"，只是"同一张网卡换了个壳"。**

### 2.3 什么云会断（别被别人的经验吓到）

| 云平台 | 桥接会不会断 | 原因 |
|---|---|---|
| **腾讯云** | ❌ 不会（实测） | 不做 MAC 反欺骗过滤 |
| 阿里云 | 通常不会 | 同 NAT 模型，但部分机型有源/目标检查 |
| **AWS EC2** | ⚠️ **会断** | 有 **MAC 反欺骗** 过滤，只允许绑定的 MAC |
| **Oracle Cloud** | ⚠️ **会断** | 需要先在控制台把 VNIC 切成"混杂模式" |
| 华为云 | 视机型 | 部分做源 IP/MAC 检查 |

**结论**：网上说"桥接必断网"的，大多来自 AWS/Oracle 用户。你的经验不能直接套。

### 2.4 动手前如何自测"我这台会不会断"

进机器跑这一条，判断是否 NAT 模型：

若两者**不同**，说明是 NAT 模型，桥接沿用 MAC 即可不断网。
若公网 IP 直接配在网卡上（IP 相同），那就是另一套模型，需谨慎。

---

## 3. 四个高危点（比桥接更危险的三个）

按实际危险程度排序——**桥接只排第四**：

| # | 高危点 | 后果 | 对策 |
|---|---|---|---|
| 1 | **cloud-init 覆盖网络配置** | 重启后桥接配置被冲掉 → **开机失联** | 写 `99-disable-network-config.cfg`；新 `interfaces` **故意不 source `interfaces.d/*`**（双保险） |
| 2 | **装完 PVE 内核后重启，网卡改名** | `eth0` 变 `ens3`，配置里名字全失效 → 无网 | 用 `.link` 文件按 MAC 锁名，或 GRUB 加 `net.ifnames=0`；**本机已有该参数，风险为零** |
| 3 | **`ifupdown` → `ifupdown2` 的替换** | 包管理器替换瞬间可能动网 | 先确认可登录、装完立刻验证 SSH；`ifreload` 是 ifupdown2 才有的增量工具 |
| 4 | **应用 br0 桥接配置** | `interfaces` 写错 → 连接打断 | 沿用 MAC + detached 执行 + 看门狗 |

### 坑 1 详解：为什么 cloud-init 是"重启失联"的元凶

原 `/etc/network/interfaces.d/50-cloud-init` 是 cloud-init 生成的，它的文件头**自己就写着**：

即：**这个文件重启后会重新生成，你改它没用。** 不处理的话，重启时它会把桥接配置冲掉。

**处理方式（双保险）**：

### 坑 3 详解：Proxmox 官方源在国内几乎不可用

实测数据（同一台机器，同一时间）：

| 源 | 下载速度 | 装 1.5GB 预计耗时 |
|---|---|---|
| `download.proxmox.com`（官方） | **935 B/s** | **约 20 天** |
| `mirrors.tuna.tsinghua.edu.cn`（清华） | **1.2 MB/s** | **3 分 54 秒** ✅ |
| `mirrors.ustc.edu.cn`（中科大） | 649 kB/s | 约 40 分钟 |
| 阿里云 / 腾讯云自有镜像站 | — | **没有 PVE 源** |

**换源后快约 1300 倍。** 这是整个流程里性价比最高的一步。

---

## 4. 不断网的四层保险（核心方法论）

这是全文最重要的一节。**"不断网"不是一个技巧，是四层防御的叠加结果。**

### 第 1 层 · 事前：备份 + 切断干扰源

**做三件事**（脚本 `01-backup-harden.sh` 已封装）：

1. **全量备份**
   

     /etc/default/grub /etc/fstab  <备份目录>/

   并落一份现场快照：`ip addr` / `ip route` / `dpkg -l` / `lsblk` / `/proc/cmdline`。

2. **把原始网络参数记成变量**（看门狗回滚全靠它）
   

   写入 `/etc/netguard/config`。

3. **切断两个干扰源**：禁 cloud-init 管网络、把 `/etc/hosts` 的主机名从回环 `127.0.1.1` 改成真实内网 IP。

> **为什么备份要这么细？**
> 因为回滚时你可能是"半个脑子"的状态（网络断着、SSH 连不上、只能靠 VNC 敲命令）。
> 那时候你最需要的不是聪明，而是**一条已知正确的原配置**。

### 第 2 层 · 让"改网络"这个动作本身不怕断

三个具体做法：

**① detached 执行——SSH 断了脚本也要跑完**

`setsid` 让脚本脱离 SSH 会话的进程组，`</dev/null` 切断 stdin。
否则网络一抖 SSH 断开 → 脚本收到 SIGHUP 被杀 → **配置写到一半，机器处于最危险状态**。

**② 用 `ifreload -a`，不用 `ifdown/ifup`，更不用 `systemctl restart networking`**

| 命令 | 行为 | 是否安全 |
|---|---|---|
| `ifreload -a` | **增量**应用差异，只动需要动的接口 | ✅ 安全 |
| `ifdown eth0 && ifup eth0` | 先把接口 down 掉 | ⚠️ 必断 |
| `systemctl restart networking` | 全量重启整个网络栈 | ⚠️ 必断 |

`ifreload` 是 `ifupdown2` 才有的。这也是为什么装 PVE 时必须让 `ifupdown2` 替换掉 `ifupdown`。

**③ 脚本内置自检 + 失败立即回滚**

切换脚本不等看门狗那 5 分钟窗口，自己最多自检 75 秒，不通就立刻调回滚：

sleep 5
[ "$(/usr/local/sbin/netguard.sh check)" = "OK" ] && { OK=yes; break; }

**④ 本机侧独立探活——"裁判"与"运动员"分离**

改网络的脚本跑在目标机上，它自己说"我没断"不算数。`watch.py` 从**机器外面**每 15 秒探一次 22 端口，日志落 `netwatch.log`。这份日志就是"零断网"的客观证据，也可以事后复盘抖动时间点。

### 第 3 层 · 自动兜底：netguard 看门狗

详见 [第 6 节](#6-netguard-看门狗详解)。核心是三件事：**systemd 常驻、多目标投票判死、三级回滚且最后一级不重启**。

### 第 4 层 · 终极兜底：云控制台 VNC

**动手前必须先确认它可用。** 腾讯云 CVM 和轻量应用服务器都提供网页版 VNC 登录。

它的意义：**当所有自动化都失败时，你还有一个"物理接触"机器的手段。**
有它，你就不是"赌一把"；没有它，你才真的是。

> ⚠️ **重要认知纠正**：很多人以为"云主机没有 VNC，所以必须一次成功"。
> 在腾讯云上这个前提**不成立**——VNC 有，IPMI 才没有。

---

## 5. 完整操作流程（六步）

> 所有脚本在 `scripts/` 目录，本机用 `rc.py` 驱动。
> 目标机侧脚本会用 `rc.py sh` 自动上传到 `/tmp` 并 `bash` 执行（自动去除 `\r`）。

### 步骤 0 · 只读侦察（不改任何配置）

**重点看四项**：

| 看什么 | 为什么 |
|---|---|
| `iface_files` | 是否存在 `interfaces.d/50-cloud-init` → 判断有没有 cloud-init 覆盖风险 |
| `boot` | GRUB 是否含 `net.ifnames=0` → 决定重启后网卡名会不会变 |
| `kvm` | 是否有 `/dev/kvm`、CPU 是否有 `vmx` → 决定能不能真跑 VM |
| `link` / `mac` / `route` | 记下网卡名 / MAC / IP / 网关 —— 后面全靠它 |

### 步骤 1 · 备份 + 加固 + 部署看门狗

**通过标准**：输出末尾出现

- `armed: YES` —— 看门狗已武装，随时能兜底
- `net_ok: YES` —— 当前网络正常，这是基准线

> **这一步网络零改动。** 先让保护就位，再动网络——顺序不能反。

### 步骤 2 · 接入 PVE 源（含测速选优）

**这一步不装任何包**，只做三件事：测速选源 → 写源 → 预演。

**要看两个结果**：

1. **"会移除哪些包"** —— 应该看到 `ifupdown` 被移除（被 `ifupdown2` 取代）。这是预期行为，也是桥接能生效的前提。
2. **"选用"哪个镜像** —— 速度应 > 1 MB/s。如果是 `download.proxmox.com` 且速度几百 B/s，说明测速逻辑或网络有问题。

### 步骤 3 · 安装 PVE

后台跑，先看前 25 秒确认启动成功，然后轮询：

**通过标准**：

**注意**：这一步**不要重启**。装完 PVE 内核先不进它，把"重启"隔离成最后一个独立步骤，风险不扩散。

### 步骤 4 · 切桥接（高危）

**先开本机探活**（后台，充当裁判）：

**再 detached 执行切换**：

**通过标准**（`/root/netguard/switch.log` 末尾）：

**同时确认**：`netwatch.log` 里**没有 DOWN 行**。

### 步骤 5 · 端到端验证

**六个区块都要看**：网络 / 外部连通性 / Proxmox / 配置卫生 / 看门狗 / 磁盘。

重点核对：

- `br0` 的 MAC == 物理网卡原 MAC
- 出口公网 IP == 切换前的公网 IP
- `pveversion` 有输出，`pveproxy` 在 8006 监听
- `interfaces.d/` 里**没有** `50-cloud-init`
- `/var/log/netguard.log` 里**没有** WARN/ERROR

### 步骤 6（可选）· 重启验证 PVE 内核

**把这一步单独拿出来做，不要混在装机流程里。**

**重启后**：等 2-3 分钟再连，跑 `05-verify.sh`，并确认：

**万一失联**：netguard 会在开机 **120 秒**后自动回滚（开机窗口缩短）。还不行就上 VNC。

---

## 6. netguard 看门狗详解

### 6.1 它解决什么问题

> "如果桥接时会断网，能否设置一个定时执行脚本，如果 5 分钟网络对外不通，恢复默认 IP 地址？"

—— 这个需求的本质是一个 **dead-man switch（死人开关）**：不需要我盯着，出事它自己处理。

### 6.2 判死规则

- **每 15 秒**探测一组目标，**四选二**才算"通"（避免单点误判导致误回滚）：
  

- 连续失败 ≥ **300 秒** → 触发回滚
- 系统启动 10 分钟内 → 阈值自动缩短为 **120 秒**（因为断网最可能发生在重启那一刻）

### 6.3 三级回滚（逐级加码，且不重启）

| 级别 | 动作 | 特点 |
|---|---|---|
| **L1** | 拆掉 `br0` → 杀 `dhclient` → **物理网卡裸跑 DHCP** | 最快，不依赖 ifupdown |
| **L2** | 仍不通 → 重写极简 `/etc/network/interfaces`（lo + 物理网卡 dhcp）→ 重启 networking | 绕开所有复杂配置 |
| **L2b** | 仍不通 → **静态写回原地址** `10.1.24.4/22` + 网关 + DNS | 连 DHCP 都不信了 |
| **兜底** | 三级全失败 → **不重启**，落盘现场快照，等人工 VNC | 见下方"为什么" |

> **为什么最后一级"不重启"？**
> 因为**重启进不去比不重启更难救**。重启后如果配置还是错的，你连现场快照都拿不到，
> 而且开机自检窗口期更短。保留现场、等人上 VNC，是更安全的终点。

### 6.4 五个关键设计（每个都是踩过的坑）

1. **装成 systemd 服务，不是 `nohup` 挂在 SSH 里**
   否则 SSH 一断，看门狗跟着死——这是最经典的翻车点。
   

2. **多目标投票，不是 ping 单个 IP**
   单个 IP 挂了会误判，误判会误回滚，误回滚本身就是事故。

3. **三级回滚，且最后一级不重启**（见上）

4. **`@reboot` 自检 + `AUTOARM` 自动重新武装**
   断网最可能发生在**重启那一刻**（网卡改名/配置未生效），而不是桥接那一刻。
   所以重启后看门狗必须能自己"醒来"：
   

   cmd_arm

5. **支持精确的"武装/解除"语义**
   - `arm` —— 武装。写标记、清空历史计时。
   - `disarm` —— 解除。仅在"确认长期稳定"后才解除，日志保留。

### 6.5 常用命令

### 6.6 日志与现场

| 路径 | 内容 |
|---|---|
| `/var/log/netguard.log` | 看门狗主日志（探测、计时、回滚全过程） |
| `/root/netguard/switch.log` | 桥接切换全过程 |
| `/var/lib/netguard/forensics.log` | 各回滚阶段的 `ip`/`route` 现场快照 |
| `/var/lib/netguard/ESCALATE` | **出现即代表自动回滚全部失败，需人工 VNC 介入** |
| `/etc/netguard/config` | 阈值与目标配置（含原始 IP/网关/DNS） |

---

## 7. 高危操作检查清单

### 7.1 动手前（每一项都要打勾）

- [ ] 已确认**腾讯云控制台 VNC 可用**
- [ ] `netguard.sh status` → `armed: YES`、`net_ok: YES`
- [ ] `/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg` 已存在
- [ ] 备份目录存在且有内容（`cat /root/netguard/BACKUP_PATH`）
- [ ] `/etc/netguard/config` 里的 `ORIG_*` 变量与实际网络一致
- [ ] 本机侧探活已启动（`watch.py` 在后台跑）
- [ ] 目标机磁盘留 ≥ 10GB（PVE 全套约 1.5GB + 内核）

### 7.2 操作中

- [ ] 用 `setsid nohup ... </dev/null &` detached 执行
- [ ] 用 `ifreload -a`，**绝不用** `ifdown/ifup` / `restart networking`
- [ ] 保持一个 SSH 长连接在旁观察
- [ ] 不在同一个脚本里同时改网络和重启

### 7.3 操作后（10 分钟内）

- [ ] `netwatch.log` 无 DOWN 记录
- [ ] 出口公网 IP 未变
- [ ] `br0` MAC == 原物理网卡 MAC
- [ ] `/var/log/netguard.log` 无 WARN/ERROR
- [ ] 再跑一遍 `05-verify.sh` 全绿

---

## 8. 故障处置手册

### 8.1 场景 A：切桥接后 SSH 断了

**别慌，先等。**

**动作**：

1. 用 `watch.py` 或本地 `ping`/`nc` 等着，**等满 5 分钟**。
2. 5 分钟后仍不通 → 上 **腾讯云控制台 → VNC 登录**。
3. VNC 里执行：
   

### 8.2 场景 B：重启后失联

**这是最可能的失联场景**，因为网卡名可能变了、或配置未生效。

1. 先等 **2-3 分钟**——netguard 的开机自检窗口是 120 秒，会自动回滚并重启网络。
2. 仍不通 → **VNC 登录**，然后：
   

3. 如果发现是**网卡改名**（`eth0` 变 `ens3`），最省事的修法是让名字固定回来：
   

### 8.3 场景 C：netguard 报 ESCALATE

出现这个文件 = **三级回滚全部失败**。此时：

1. **不要再重启**（设计上就没让它重启，保住现场）。
2. `cat /var/lib/netguard/forensics.log` 看各阶段快照，定位哪一步断了。
3. 手工对照备份恢复：
   

4. 实在不行，直接在控制台**重装系统 + 挂载原磁盘**把数据捞出来。

### 8.4 场景 D：想把机器还原成"没装过"

> ⚠️ 第 3、4 步是**不可逆的破坏性操作**。执行前务必确认备份可用、VNC 可用。

---

## 9. 附录

### 9.1 本次环境快照（2026-09-14）

| 项 | 值 |
|---|---|
| 主机 | `114.132.244.13`（腾讯云 CVM，广州七区） |
| 实例 ID | `ins-3ug3yt4w` |
| 系统 | Debian 12 (bookworm) |
| 规格 | 4 核 4G，根分区 57G 可用 |
| 网卡 | `eth0`，MAC `52:54:00:d7:a0:cc` |
| 内网 IP | `10.1.24.4/22`，网关 `10.1.24.1` |
| 公网 IP | `114.132.244.13`（NAT） |
| 运行内核 | `6.1.0-50-amd64`（Debian 原内核） |
| 已装 PVE 内核 | `proxmox-kernel-6.8.12-43-pve` |
| Proxmox VE | **8.4.21**，`pveproxy` 监听 8006 |
| 嵌套虚拟化 | ❌ 无 `vmx`、无 `/dev/kvm` |

### 9.2 文件清单

**本机（`C:\Users\Administrator\Desktop\pyscan\Linux KVM\`）**

| 路径 | 说明 |
|---|---|
| `装机与不断网操作手册.md` | **本文档** |
| `README.md` | 快速索引 |
| `KVM-Proxmox装机验证报告.md` | 本次实测报告（证据与数据） |
| `netwatch.log` | 本次本机侧探活日志（零 DOWN 的证据） |
| `scripts/` | **可复用的干净脚本集**（见下） |
| `_netguard/` | 本次实际执行的目标机脚本留档 |
| `_probe/` | 本次实际执行的本机脚本留档 |

**`scripts/` 目录**

| 文件 | 运行位置 | 说明 |
|---|---|---|
| `rc.py` | 本机 | SSH 免交互执行/上传/下载（凭据走环境变量） |
| `recon.py` | 本机 | 只读侦察 |
| `watch.py` | 本机 | 独立探活（裁判） |
| `01-backup-harden.sh` | 目标机 | 备份 + 加固 + 部署并武装看门狗 |
| `02-pve-repo.sh` | 目标机 | 镜像测速选优 + 写源 + 预演 |
| `03-install-pve.sh` | 目标机 | 后台安装 PVE |
| `04-switch-bridge.sh` | 目标机 | **切桥接（高危）** |
| `05-verify.sh` | 目标机 | 端到端验证 |
| `netguard.sh` | 目标机 | 看门狗主程序 |
| `netguard.service` | 目标机 | 常驻服务定义 |
| `netguard-bridge.sh` | 目标机 | 回滚后一键重新应用桥接 |

**目标机（已部署）**

| 路径 | 说明 |
|---|---|
| `/usr/local/sbin/netguard.sh` | 看门狗主程序 |
| `/usr/local/sbin/netguard-bridge.sh` | 一键重新应用桥接 |
| `/etc/systemd/system/netguard.service` | 常驻服务 |
| `/etc/netguard/config` | 阈值与原始网络参数 |
| `/etc/netguard/AUTOARM` | 重启后自动武装标记 |
| `/root/netguard/README.md` | 目标机侧运维说明 |
| `/root/netguard/backup-<时间戳>/` | 全量备份 + 现场快照 |
| `/var/log/netguard.log` | 看门狗日志 |
| `/root/netguard/switch.log` | 桥接切换全过程 |

### 9.3 已知限制

- **无嵌套虚拟化**：本机 CPU 无 `vmx`、无 `/dev/kvm`。PVE 可正常安装、管理、配置，但**无法运行硬件加速的虚拟机**。只测装机不受影响；要真跑 VM 需换支持嵌套的机型或裸金属。
- **未卸载 Debian 原内核**：官方建议装完 PVE 后删掉 `linux-image-amd64`，此处刻意保留作退路。等重启验证 PVE 内核正常后再删不迟。
- **未执行 `apt full-upgrade`**：官方文档建议做，此处跳过以避免 500+ 无关包升级引入变量。
- **8006 / 3128 被安全组拦截**：需在控制台放通，或走 SSH 隧道：
  

- **本次安装移除了** `ifupdown`、`ntp`、`ntpsec`（被 `ifupdown2`、`chrony` 取代）。顺带消除了官方文档提到的"ntpsec 钩子导致开机网络起不来"这个已知坑。

### 9.4 本次实测时间线

| 时刻 | 阶段 | 结果 |
|---|---|---|
| 18:31 | 只读侦察 | Debian 12 / 4C4G / 57G 可用 / eth0 `10.1.24.4` / 无 `/dev/kvm` |
| 18:34 | 备份 + 加固 | 备份 88KB，`hostname -f` 正常 |
| 18:34 | 部署看门狗 | `armed: YES`，`net_ok: YES` |
| 18:40 | 加 PVE 源 + 预演 | 官方源 935 B/s → 换清华 TUNA（1.2 MB/s） |
| 18:42 | 安装 PVE | `APT_EXIT=0`，563 包，**3 分 54 秒**，零错误 |
| 18:47 | 切 br0 桥接 | `ifreload rc=0`，9 秒自检通过，**零断网** |
| 18:48 | AUTOARM + 最终验证 | 服务 active/enabled，网络与 PVE 全部正常 |

---

## 附：核心命令速记卡

---

*文档基于 2026-09-14 实测编写。下次使用前，务必重新跑一遍 `recon.py` 核对环境，不要照搬 IP、MAC、网关等硬编码值。*