官网：docs.ludus.cloud
项目：gitlab.com/badsectorlabs/ludus。
90 percent of security research is getting test environments setup properly.
做过企业级复杂网络拓扑靶场的人大概都会同意：真正耗时间的并不是启动一台 Windows，而是让 DC、客户端、攻击机、路由规则和初始化状态在同一时刻正确地出现。
理解 Ludus 的一个好入口，是从 Template 到 Range 的这段变化。Template 提供一台已经准备好的机器；Range 则让域控、客户端、攻击机、路由规则和初始化状态一起出现，成为一段可以进入、实验和重新生成的网络。
Range：Ludus 的抽象单元
PVE 的直接管理对象是一台 VM，Ludus 的直接管理对象则是一套 Range。Range 把多个节点、它们之间的网络关系以及实验开始时应有的状态视为一个整体：域控和域成员的身份关系、服务所处的网段、路由与访问规则、场景需要的账号和数据，都属于同一次部署。
这使得网络不再只是 VM 的附属设置。VLAN 决定谁能首先看见谁，双网卡主机决定哪里可以发生 pivot，访问规则决定一次控制之后能否继续推进。攻击机只是其中一个角色；它可以随 Range 一起部署，也可以被单独规划为攻击平面。
真正需要被固定下来的，是整条实验路径的起点和边界。
Ludus 配置的价值在于把模板、角色、网络位置和依赖关系用yaml写成一份可以反复兑现的声明。一次部署之后，得到的不只是一组已经开机的 VM，而是一个处于指定初始状态的实验环境。实验过程中产生的变更也可以随整套环境一起被清理、恢复或重新创建。
从 PVE 到 Range
PVE 依赖硬件辅助虚拟化，因此 Ludus 通常部署在裸金属 PVE 上，以获得更稳定的性能、存储 I/O 和虚拟化兼容性；当然也可以采用嵌套虚拟化。
Ludus 采用分层架构。Proxmox Virtual Environment，也就是 PVE，是它的虚拟化基础设施层：QEMU/KVM 在这里执行 VM，PVE 提供虚拟计算、存储、网络和克隆能力。Ludus 位于这一层之上，负责将 Template clone、虚拟网络配置和后续角色初始化编排为 Range 的部署流程。
Packer 处于镜像构建阶段。它从 Windows 或 Linux ISO 创建临时 VM，执行无人值守安装与基础 Provisioning，并将完成后的 VM 固化为 PVE Template。这里的 Template 是 PVE 标记为可克隆的 VM 模板对象，而不是某个固定扩展名的镜像文件；底层磁盘可以是 qcow2、raw 或存储后端管理的块卷。后续 Range 部署从这份经过启动验证的 Golden Image clone 出所有实例，而不再重复操作系统安装。
实例 clone 完成后，Ludus 进入后置配置阶段。Ansible 按依赖关系执行角色配置：先创建域服务，再将成员机加入域，随后部署应用、工具和场景服务。QEMU Guest Agent 为 PVE 与来宾机提供管理接口，暴露 IP 和运行状态等信息，供编排流程确认 VM 已具备继续配置的条件。
这种分层将基础镜像与场景配置分离：Packer 和 Template 控制镜像一致性，Ansible 控制角色与服务状态，Ludus 负责它们与网络拓扑的编排。每次部署都从同一个 Golden Image 和同一份拓扑定义开始。
总结
Ludus 以 Range 为中心，将 PVE 的虚拟化能力、Packer 构建的 Golden Image 与 Ansible 的配置管理串成一条部署链路。网络拓扑、机器角色和初始状态因此能够从同一基线被反复生成。
对于模型渗透能力评测，这提供了可比较、可重置的实验条件。也是当前的较好实践。