目录

成本为零!用 Veeam 实现物理 Air Gap,让昂贵的避风港方案黯然失色

成本为零!用 Veeam 实现物理 Air Gap,让昂贵的避风港方案黯然失色

首先要感谢我的同事张远,这个方案的设计思路其实源于他几年前在内部分享的通过 Palo Alto 设备自动控制网络防火墙的想法。本文只是用零成本的 OpenWRT 复现了他的优秀设计。

还记得 2019 年那篇关于勒索病毒攻击的文章吗?

当时我就强调过数据隔离的重要性。勒索病毒越来越智能,它们不再只是加密生产数据,还会破坏备份服务器、删除备份 catalog,甚至连专用存储设备都不放过。

很多管理员都遇到过这样的对话:

“老板,我们中招了,数据全被锁了!”

“备份了没?”

“备了,但备份服务器也被感染了,catalog 没了,再安全的存储也恢复不了…”

这种情况下,就算花几百万买的"避风港"设备,如果还连着网,理论上还是有机会被攻击的,不说攻击是否得手,被黑客惦记着的几率还是不小的。

为什么要真正的 Air Gap

勒索病毒的进化威胁

2017 年我刚写勒索病毒文章时,它们还比较简单,只会加密生产数据。但现在情况完全不同了。

现代勒索病毒具备多重攻击能力:

  • 破坏备份服务器
  • 删除备份 catalog 数据库
  • 禁用备份软件服务
  • 甚至攻击专用备份存储设备

也就是说,就算你做了备份,如果备份服务器和存储设备还在网上,就有被攻击的风险。

传统方案的局限

很多厂商的"隔离"方案本质上还是逻辑隔离,依赖复杂的软件规则和配置。但软件总有漏洞,配置可能出错,而且网络连接本身就是一个攻击面。

真正的 Air Gap 应该是:备份完成后,数据在网络层面彻底消失

物理上还在,逻辑上消失了。连 VBR 服务器自己都找不到备份存储。这才是真正的物理隔离。

今天,我带大家来看看结合现代的一些技术,Veeam 如何实现这样的真正物理隔离。

Veeam Air Gap 关键技术

网络控制的核心逻辑:时间维度的访问控制

实现 Air Gap 的核心思路其实很简单:时间维度的网络访问控制

  • 备份时:网络可达
  • 备份后:网络不可达
  • 恢复时:重新可达

这不需要什么高深技术,只需要两个组件:

  1. 一台支持 API 的网络设备(本文以零成本的 OpenWRT 路由器为例)
  2. 一个自动化脚本(本文例子中是用 Powershell,当然也可以是 shell 脚本)

关键设计:脚本启动时机的精准控制

这是整个方案最关键的技术点,设计原则如下:

  • 开启时机:必须在跨墙数据传输作业之外启动(独立作业)
    • 因为网络必须在数据传输开始前就打通。
    • 数据传输作业紧跟着开墙策略,利用 Veeam 作业计划任务重的 After this Job 特性。
    • 不能依赖传输作业本身,因为作业启动前会检查存储可用性,发现不可用,作业就失败了。
  • 关闭时机:可以在数据传输作业之内关闭(后处理脚本)
    • 因为关闭操作是数据传输完成后的清理工作。
    • 后续没有影响任务成功失败的因素,可以安全在任务内关闭。

防火墙(Openwrt) + 控制脚本(Powershell)技术架构

架构描述

我的本次实验,有两个子网,分别是生产子网 10.10.1.0/24,隔离室子网 10.10.2.0/24。这两个子网正常情况下路由不可达,在 OpenWRT 中控制了这两个子网的路由表。

https://s2.loli.net/2025/11/17/8257pC9NLSGlrYD.png

OpenWRT 路由器负责控制两个网段之间的访问:

  • 默认情况下,10.10.1.0/24 和 10.10.2.0/24 网段完全断开
  • 脚本控制两个网络的路由规则
  • 通过 Luci RPC API 实现自动化控制

准备条件,

  • OpenWRT 我选用 24.10 版本,vSphere 上安装软路由的方法比较多,我就不在这里说明了,唯一需要提的是,要执行远程命令,需要为 OpenWRT 安装上 luci-mod-rpc 组件,安装命令为:

    opkg install luci-mod-rpc
  • 两个脚本,一个 open_the_door.ps1 添加路由表,另外一个 close_the_door.ps1 删除路由表。我的实验脚本已经上传到我的 Github 仓库中,有需要试玩可以参考我的方法,自取脚本试验。

  • 仓库地址:https://github.com/Coku2015/Veeam_Scripts/tree/main/Vee_blog_airgap

两种业务场景实现

场景一:隔离区作为一级备份存储,备份数据直接进入隔离状态

这种方式适用于对安全有极致追求的用户,数据直接备份到隔离区域,需要两个 Veeam 作业配合,其中一个为假的伪作业。这个操作其实选择还是比较多的,可以用 VMware 虚拟机的备份来做,也可以用物理机的备份作业来做,核心思想是,用一个动态的对象容器作为备份对象,欺骗备份作业,导致备份作业无实际备份对象可以处理。这样一来,备份作业就变成了一个单纯的脚本启动引擎。我们用这个引擎去激活路由表添加的脚本,开启网络的访问。而真正的备份作业则是使用 After this Job,跟着这个伪作业进行串联,实现无缝开墙传数据。

配置步骤

在开通路由的情况下,配置完 Veeam 的 Hardened Repository,然后用 close_the_door.ps1 脚本删除路由表。

  1. 创建一个脚本启动专用备份作业,本例中以 vSphere 空 Tag 组方式创建。在对象选择界面选一个名为 open_the_door 的 Tag,其中不包含任何对象,此时对象选择完成后如下图:

https://s2.loli.net/2025/11/17/lU3xEm8iej5yZ7s.png

  1. 在 Storage 配置的 Advanced 选项卡中,我们需要配置 Job 的 Pre 或 Post script,选择 Open_the_door.ps1 脚本,此处其实这两个配哪一个都可以,问题不大。

https://s2.loli.net/2025/11/17/xf9rNQgRqwcPSUO.png

  1. 设置计划任务,这个是我们开墙做备份的起点,比如每天晚上 10 点开工。

https://s2.loli.net/2025/11/17/hyuSn5MGgP1FqtK.png

  1. 创建第二个作业,真正执行备份任务的实际作业。在这个作业的 Storage 配置中,还是 Advanced 的选项卡中,配置 Post Script,选择 close_the_door.ps1 脚本,这里必须配置为 Post Script,用来关闭防火墙。

https://s2.loli.net/2025/11/17/1NxUr8d65ulVWYz.png

  1. 设置这个作业的计划任务,指定为 After this Job,选择 Open_the_door_job 这个作业,表示紧跟着开墙作业启动任务。

https://s2.loli.net/2025/11/17/83Arb5fwExehmRZ.png

通过这样的设置,实现了数据备份开始前开墙,备份后立刻关墙的全自动操作,日常使用无需人工干预。

场景二:第二份备份数据进入隔离区的 Backup Copy 隔离方案

这种方式适用于对安全有较高要求,但是又不想失去恢复验证能力和还原便捷度的客户,通过 Backup Copy 作业将一级存储的数据复制到二级隔离存储。这个方式,对于用户来说,不需要额外的任务来辅助,只需要在主备份任务结束时,开启防火墙,然后让 Backup Copy 作业紧跟着 Backup job 去执行,一样也是 After Job 模式,执行完成之后 Backup Copy 作业执行关闭防火墙操作。

配置步骤

  1. 创建主备份作业,在 Storage 配置的 Advanced 选项卡中,配置 Post Script,选择 Open_the_door.ps1 脚本,这里建议配置 Post Script,尽量让开墙时间缩短,避免在主备份任务长时间的传输数据过程中隔离区提早进入打开状态。这个配置和场景一的第二步完全一样。

  2. 创建 Backup Copy 作业,在 Copy 模式上,这里必须选择 Periodic 模式,只有这个模式,才能给我们 Schedule 中能够设定 After this Job 的方式。

https://s2.loli.net/2025/11/17/rDA9eOZmW7CbTRn.png

  1. 在 Target 配置中的 Advanced 选项卡中,还是配置 Post Script,选择 close_the_door.ps1 脚本,这里必须配置为 Post Script,用来关闭防火墙。

https://s2.loli.net/2025/11/17/Szfmxvb9RcFyQTj.png

  1. 设置这个作业的计划任务,指定为 After First backup job。这个作业并不是在某个时间起,而是在开墙之后起。

https://s2.loli.net/2025/11/17/fdXUCwISs8OjqZR.png

通过这样的设置,实现了拷贝数据备份前开墙,数据拷贝完成后立刻关墙的全自动操作,日常使用无人干预。

Backup Copy 必须使用 Periodic 模式,不能用 Mirrorring 模式。

验证与总结

当作业运行之后,会看到所有作业都成功执行了,并且作业中,会有相关的 Post Script 执行成功的提示。让我们来看实际数据的情况。

https://s2.loli.net/2025/11/17/5VkYLdhvwsFmjEg.png

备份完成后,我们来到备份服务器的 Backup Infrastructure 下面,通常就会看到我们的 Backup Repository 是处于 Unavailable 状态,这是我们期望的状态,说明这个 repository 是无法访问的。

https://s2.loli.net/2025/11/17/lKut7x8BvS2rbAz.png

当我们去找到 Backups 中的数据时,我们选择删除操作的时候,系统会提示数据无法访问。这时候需要注意的是,这和我们联机状态下 Immutable repository 不一样,不是提示数据在 xx 之前不可删除,而是直接无法访问到数据,连接被拒绝,无法进行操作。

https://s2.loli.net/2025/11/17/bkHRLGICOsVfoc5.png

选择恢复操作时,在 Restore point 界面中,直接会显示还原点访问被拒绝。

https://s2.loli.net/2025/11/17/gnbYHKsuOxwC6Zj.png

当然,这个方案还是稍微有一点点不完美,在每 4 小时的 Host Discovery 事件中,必然会有一次这个 repository 的扫描,会出现报错,如果 Veeam R&D 能将这种 Repository 设置为 Host Discovery 的排除,会更加漂亮!

https://s2.loli.net/2025/11/17/UraVAHPnyjBN6S5.png

如上,通过这样的设置,是不是觉得安全进一步得到了保障?