如何在 Netcup VPS 与 Root Server 上安装 Docker Engine 并修复 UFW 防火墙绕过问题

在正式安装上游 Docker Engine 之前，第一步是卸载操作系统发行版自带的任何旧版容器运行时组件（如 docker.io、podman-docker、docker-compose v1 Python 脚本以及独立的旧版 containerd），并确认系统中未安装通过 snap 分发的 Docker 软件包。Ubuntu 安装向导中有时会引导用户勾选 Snap 版 Docker，但 Snap 的严格目录沙盒与 AppArmor 策略会导致容器无法挂载 /opt 或自定义数据盘路径，且 Snap 后台强制自动更新会在毫无预警的情况下重启整机容器集群。

卸载冲突旧包后，我们将创建符合 Debian/Ubuntu 现代安全规范的 /etc/apt/keyrings 目录（权限 0755，取代早已废弃的全局 apt-key add 命令），下载并注册 Docker 官方 GPG 公钥证书（docker.asc），并通过 signed-by=/etc/apt/keyrings/docker.asc 参数将信任范围严格限定在 Docker 官方软件源内。

为了确保脚本在 Ubuntu 24.04 LTS（代号 noble）与 Debian 12（代号 bookworm）上均能零差错执行，下方代码块直接读取 /etc/os-release 中的 $ID 与 $VERSION_CODENAME 环境变量动态生成 /etc/apt/sources.list.d/docker.list，并一次性安装 docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin 以及原生 Go 语言编写的 docker-compose-plugin（即 docker compose v2 命令）。

从底层虚拟化架构来看，Netcup 全系 VPS 与 Root Server 均基于 QEMU/KVM 全虚拟化技术，为客户机提供独立的 Linux 6.8+ 内核空间、完整的 cgroupv2（Control Groups v2）资源隔离层级以及原生 overlay2 联合文件系统支持。这意味着您可以利用 deploy.resources.limits 对单个容器施加精准的 CPU 份额与内存硬上限（避免某个内存泄漏的 Java 或 Node.js 容器拖垮整台服务器），同时利用 BuildKit 多阶段并发构建缓存将 CI/CD 镜像打包速度提升 3 倍以上：

# 1. 清理系统内置的旧版冲突容器软件包
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove -y $pkg 2>/dev/null || true
done

# 2. 安装前置依赖并导入 Docker 官方 GPG 签名公钥
sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
. /etc/os-release
sudo curl -fsSL "https://download.docker.com/linux/${ID}/gpg" -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# 3. 写入官方 Docker APT 软件源配置
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/${ID} ${VERSION_CODENAME} stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4. 安装 Docker Engine、CLI、containerd、Buildx 与 Compose v2 插件
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker --version && docker compose version

Docker version 27.3.1, build ce12230
Docker Compose version v2.29.7

默认安装状态下，Docker 的 json-file 日志驱动会将容器内应用向标准输出（stdout）和标准错误（stderr）打印的每一行访问日志永久追加保存在 /var/lib/docker/containers/<container-id>/ 目录下，且没有任何体积上限！在承载生产业务的 Netcup VPS 1000 G12.5 或 RS 1000 G12.5 上，一个高并发的 Nginx、Traefik 或 Node.js 容器在运行数月后，其未轮转的 JSON 日志文件往往会悄无声息地吞噬 40 GB 以上的宝贵 NVMe 空间，最终引发全盘 ENOSPC (No space left on device) 故障并导致 PostgreSQL 或 MySQL 数据库停机。

通过在 /etc/docker/daemon.json 中显式配置 "max-size": "10m"、"max-file": "3" 与 "compress": "true"，Docker 守护进程会在单个容器日志达到 10 MB 时自动触发轮转与 gzip 压缩，并仅保留最新的 3 个历史分片（单容器日志封顶 30 MB）。同时，显式指定 "storage-driver": "overlay2" 可确保容器镜像层直接利用 Linux 内核原生的目录级写时复制（Copy-on-Write）机制，充分释放 Netcup 本地 RAID10 NVMe 存储阵列的随机读写性能。

生产环境还应当开启两项关键内核级特性：一是设置 "live-restore": true，将容器生命周期管理与上层 dockerd 守护进程解耦——当 unattended-upgrades 自动升级 docker-ce 软件包并重启 dockerd 时，所有正在运行的业务容器由底层 containerd-shim 保持继续运行而不会发生中断；二是设置 "userland-proxy": false，关闭默认情况下每个端口映射都会派生一个消耗额外 RAM 与 CPU 上下文切换的 docker-proxy 用户态转发进程，完全交由 Linux 内核的高性能 netfilter 原生 Hairpin NAT 处理流量转发。

最后，通过 "default-address-pools" 显式规划容器网桥的 IPAM（IP 地址管理）子网分配策略至关重要。默认情况下，每当您执行一次 docker compose up 创建一个新项目网络时，Docker 都会豪横地切分走一整段 /16 大网段（172.17.0.0/16、172.18.0.0/16……），不仅迅速耗尽私有路由空间，还极易与企业内部的 WireGuard、Tailscale 或 OpenVPN 隧道网段发生路由冲突。将地址池基准设为 172.20.0.0/14 并将子网掩码粒度设为 "size": 24，即可支持多达 1,024 个互不冲突的独立 Compose 网络：

cat << 'EOF' | sudo tee /etc/docker/daemon.json
{
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  },
  "live-restore": true,
  "userland-proxy": false,
  "default-address-pools": [
    {
      "base": "172.20.0.0/14",
      "size": 24
    }
  ]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo docker info | grep -E "Storage Driver|Logging Driver|Live Restore"

 Storage Driver: overlay2
 Logging Driver: json-file
 Live Restore Enabled: true

这是自建 Linux 容器服务器上最常见的高危安全隐患：当您在 Ubuntu 上开启了 ufw 防火墙（设置默认拒绝入站 ufw default deny incoming，仅放行 22/80/443），随后在 compose.yaml 中使用 ports: - "5432:5432" 或 - "6379:6379" 启动 PostgreSQL 或 Redis 容器时，Docker 会直接修改 Linux 内核 nat 表的 PREROUTING 链与 filter 表的 FORWARD 链。而在 Linux netfilter 数据包处理流程中，PREROUTING 目的地址转换（DNAT）发生在路由决策之前，被重写目标 IP 的数据包随后直接进入 FORWARD 转发链，从而完全绕过了 UFW 所接管的本机 INPUT 过滤链！

结果就是：尽管您在宿主机终端运行 sudo ufw status 看到防火墙处于激活状态且并未放行 5432 或 6379 端口，但全世界的自动化扫描器却能直接连上您容器的数据库端口。更危险的是，如果您为了阻止这种行为而在 /etc/docker/daemon.json 中草率地设置 "iptables": false，则会直接切断所有 Docker 容器的源地址转换（SNAT / MASQUERADE），导致容器内部无法访问外部互联网或拉取 API 数据。

正确的根治方案是从套接字绑定层入手：只要某个容器端口仅供宿主机本机的 Nginx/Caddy 反向代理或本机其他容器调用，在 docker run -p 或 compose.yaml 的 ports: 数组中就必须显式指定本地回环地址前缀 127.0.0.1:（例如 "127.0.0.1:5432:5432" 或 "127.0.0.1:8080:8080"）。这样内核 DNAT 规则会严格限制仅匹配目标地址为 127.0.0.1 的本地数据包，任何来自外部 eth0 公网网卡的探测流量都会被直接丢弃。

在此基础上，结合 Netcup 独有的 SCP 宿主机边缘有状态防火墙（Hypervisor Stateful Firewall） 与 Docker 官方预留的 DOCKER-USER 过滤链，即可在 Netcup 服务器上构建起三层纵深容器网络边界防御体系，确保没有任何一个后端容器端口会意外暴露在公网之上：

• ▪ 第一层防御 —— 在 compose.yaml 中强制绑定本地回环地址（Loopback Binding）：对于任何由宿主机 Nginx/Caddy 反向代理或本机服务访问的容器端口，一律写成 127.0.0.1:8080:8080 或 127.0.0.1:6379:6379，从套接字源头阻止外部网卡访问。
• ▪ 第二层防御 —— 启用 Netcup SCP 宿主机有状态防火墙（Hypervisor Stateful Firewall）：登录 servercontrolpanel.de → Network → Firewall，仅允许入站 TCP 22、80、443 与 UDP 443，并将默认入站策略设为 DROP。由于 SCP 防火墙运行在宿主机虚拟交换机层（位于虚拟机外部），客户机内部 Docker 修改的任何 iptables 规则都绝对无法穿透 SCP 防火墙！
• ▪ 第三层防御 —— 在 /etc/ufw/after.rules 中锁定 DOCKER-USER 链：利用 Docker 专门预留给管理员的最高优先级过滤链 DOCKER-USER，显式丢弃从公网网卡（eth0/ens3）直接发往私有容器子网的非预期新建连接。

# 始终将内部应用与数据库容器端口严格绑定在 127.0.0.1 本地回环地址上：
docker run -d --name test-redis --restart unless-stopped -p 127.0.0.1:6379:6379 redis:7-alpine

# 审计 Netcup 服务器上所有处于监听状态的 TCP/UDP 套接字：
# 确保只有 sshd (22) 与您的前端反向代理 (80/443) 监听在 0.0.0.0 或 [::] 上
sudo ss -tulnp

tcp   LISTEN 0      4096       127.0.0.1:6379      0.0.0.0:*    users:(("dockerd",pid=1120,fd=14))