故障排查与失联救援 (Server Rescue Mission)¶

[!DANGER] 适用场景：服务器 SSH 连不上、Ping 不通、疑似死机或防火墙配置错误。 适用环境：Oracle Cloud Infrastructure (OCI)。

Phase 1: 无创诊断 (External Check)¶

在动刀之前，先确认不是低级错误。

检查 Oracle 安全组 (Security List)
- 去 Oracle Cloud Console -> Networking -> VCN -> Security List。
- 入站规则 (Ingress)：确认 22 端口是开放的 (Source: 0.0.0.0/0, Dest Port: 22)。
- 出站规则 (Egress)：确认是全开的 (Allow All)。
检查公网 IP
- 确认 IP 没有变动（虽然 Oracle 的 Public IP 通常是不变的，除非你删过 VNIC）。
重启大法 (Reboot)
- Console -> Instances -> [Instance Name] -> Reboot (Force Reboot)。
- 等待 2-3 分钟，尝试 ping 和 ssh。

Phase 2: 内网渗透 (Internal Rescue)¶

如果公网连不上，试试内网。前提是你同账号 (同 VCN) 下还有另一台活着的机器（救援机）。

获取内网 IP
- 在 Oracle Console 查看失联机的 Private IP (例如 10.0.0.218)。
跳板登录
- 登录救援机 (ssh user@healthy-node)。
- 在救援机尝试连接失联机：
```
ssh ubuntu@10.0.0.218
# 或者
ssh root@10.0.0.218
```
- 如果通了：说明是公网防火墙 (UFW/iptables) 封只有了公网 IP，但内网 (10.0.0.0/16) 是通的。
- 修复：sudo ufw disable 然后排查规则。

Phase 3: 串口调试 (Console Rescue)¶

这是唯一的“物理”连接方式，不走网络。

启动 Cloud Shell
- Oracle Console -> Instances -> [Instance Name] -> Console connection -> Launch Cloud Shell connection。
观察输出
- 如果是标准镜像 (Ubuntu/Oracle Linux)，你应该能看到登录提示符。
- 如果是 DD 的系统 (如 Debian)：
  - ❌ 黑屏/无响应：大概率是因为 DD 镜像没有配置串口重定向 (console=ttyS0)。此路不通，直接跳到 Phase 4。
  - ✅ 有输出：尝试输入用户名密码登录。如果忘记密码，重启并在 GRUB 菜单按 e 进单用户模式改密码（需要手速）。

Phase 4: 外科手术 (Storage Rescue) ⚡️必杀技¶

把失联机的硬盘拆下来，挂到救援机上修。此方案治百病。

Step 1: 拆卸 (Detach)¶

停止失联机: Console -> Stop。
分离引导卷:
- Resources -> Boot volume。
- 点击 Boot volume 的名字进入详情页。
- Detach from instance (确认)。

Step 2: 挂载 (Attach)¶

挂载到救援机:
- 在 Boot volume 详情页 -> Attach to instance。
- 选择你的“救援机” (Healthy Node)。
- 类型选择 Paravirtualized (半虚拟化，最简单，不需要输命令)。
- 点击 Attach。

Step 3: 手术 (Operation)¶

登录救援机：

lsblk
# 你应该能看到一个新的盘，通常是 /dev/sdb
# sdb1 (EFI), sdb2 (Root) 等

# 挂载根分区 (假设是 sdb2，具体用 fdisk -l 看)
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdb2 /mnt/rescue

# === 方案 A: 修复配置 (Fix) ===
# 例如：关闭防火墙
# sudo rm /mnt/rescue/etc/iptables/rules.v4

# 例如：修改 SSH 配置
# sudo nano /mnt/rescue/etc/ssh/sshd_config

# 例如：重置密码 (chroot 大法)
# sudo chroot /mnt/rescue passwd root

# === 方案 B: 重新 DD (Re-Install) ===
# ⚠️ 高危操作：直接把新系统写入这个盘
# 前提：你有一个好的 raw 镜像文件 (debian.img)
# sudo dd if=/path/to/debian.img of=/dev/sdb bs=10M status=progress

Step 4: 缝合 (Restore)¶

救援机: sudo umount /mnt/rescue。
Oracle Console:
- Boot volume -> Detach from 救援机。
- 等待分离完成。
- 回到 失联机 (Details页面) -> Resources -> Boot volume -> Attach boot volume。
- 重要: 必须确保它是 Boot Volume (不仅是 Attach，而是要在实例停止状态下作为启动盘挂载，通常 Oracle 界面里是 "Attach boot volume" 按钮，或者在 Boot Volume 列表里操作)。如果你把原来的 Boot Volume 删了，可以在 Instance -> Edit -> Change Boot Volume (如果支持) 或者直接 Terminate Instance (保留 Boot Volume) 然后用这个 Volume 新建一台机器。
- 最稳妥做法：
  1. Detach from 救援机。
  2. 去 Boot Volumes 列表找到这个卷。
  3. 点击 "Create Instance" (用这个卷作为启动盘创建新实例)。
  4. 这样你就得到了一台“复活”的机器，IP 可能会变，但数据都在。
- 如果只想挂回原机器：确保原机器处于 Stop 状态，在 Boot Volume 处 Attach，并设为启动盘 (通常 Oracle 限制只能有一个 Boot Volume，Detach 旧的 Attach 新的即可，或者直接 Terminate 原机器用卷重建)。

附录：常用 DD 镜像源¶

如果你决定在 Phase 4 重新 DD：

# 1. 救援机上下载镜像 (推荐 Debian 12)
wget -O debian.img https://... (你的镜像地址)

# 2. 写入失联盘 (/dev/sdb)
dd if=debian.img of=/dev/sdb bs=10M status=progress

Phase 5: 疑难杂症案例库 (Case Studies)¶

Case 1: Traefik 无法连接后端 Swarm 服务 (502/504)¶

现象： * Traefik 正常启动，Service 也能解析到 IP。 * curl 后端服务报 Time out 或 TLS 握手失败 (i/o timeout)。 * ufw disable 后依然无效 (因为 iptables 残留)。

根因： ufw-docker 默认策略会在 DOCKER-USER 链中 DROP 所有发往 Docker 网段 (10.x, 172.x) 的流量。这会误杀 Swarm Overlay 网络内部通讯。

解法： 1. 彻底清除残余规则：

sudo iptables -F DOCKER-USER
sudo iptables -A DOCKER-USER -j RETURN

2. 配置永久白名单：编辑 /etc/ufw/after.rules，在 COMMIT 前添加：

# 允许 Swarm 内部 Overlay 互通
-I DOCKER-USER -s 10.0.0.0/8 -j ACCEPT
# 允许 Traefik 对外暴露端口
-I DOCKER-USER -p tcp -m tcp --dport 80 -j ACCEPT
-I DOCKER-USER -p tcp -m tcp --dport 443 -j ACCEPT

3. 重载：sudo ufw reload