2.1 整体架构：团队服务器、客户端与目标侧的三角关系

2.1 整体架构

本节摘要：这套平台由三个角色构成：团队服务器持有全部会话与任务状态，客户端是操作员的驾驶席位，目标侧的 Beacon 会话是被调度对象。理解"两种连接方向相反的箭头"，是看懂一切部署形态、流量方向与检测点的起点。

从一个部署问题切入

准备一次演练时，新人最常问的问题是："服务器应该放在哪？"这个问题问对了——因为架构里所有安全和检测上要紧的事情，都由"谁在哪里、连接方向朝哪"决定。要回答它，得先把三方角色各自的职责说清楚：团队服务器是整个体系的状态中枢，所有会话的注册信息、待执行任务、历史事件日志都只在它这里存有全量；客户端是无状态的驾驶席位，操作员通过它查看事件流、提交任务，掉线了重连即可，本地不留关键状态；目标侧会话是运行在授权目标主机上的调度对象，只与团队服务器（或其指定的对等节点）通信，永远不会直接连接操作员的笔记本。

图 2-1 三方架构与两类连接

图上有两条线，方向值得盯住：客户端到服务器是管理连接，目标侧会话到服务器是任务连接。两条线都朝向服务器——也就是说，这套体系在连接方向上没有"服务器主动穿透进目标"的动作，目标侧永远是自己按节律"打回来"取任务。这个设计有部署上的深意：服务器只需要在一个固定位置开放服务端口，目标环境的出网策略才是通道存活的决定因素。

这个架构塑造了哪些必然

把职责和方向放在一起，可以推出几条"必然"，它们是后面检测与治理章节的地基。必然一：全量证据只有一个家。 会话注册、任务下发、结果回传的所有事件都汇聚在团队服务器的日志里，这意味着正规演练的审计材料天然完整——第 5 章的报告规范就是围绕这份日志建的；反过来，这也让"服务器"成为需要最高等级防护的资产，它落地的那个位置，就是全部演练数据的落点。必然二：目标侧只认服务器地址。 会话配置里写的是服务器的指向信息，操作员换电脑、换城市都不影响会话存活；同样地，取证人员在目标侧看到的回连目标，指向的是基础设施（服务器或其前置），而非操作员的物理位置。必然三：出向节律是体系的脉搏。 因为任务连接由目标侧发起，无论通道怎么换壳，"周期性出向连接"这个形状都在——第 3 章的检测方法学，就是从这个形状出发的。

部署形态：位置选择的取舍

回到开头的问题"服务器放哪"。常见形态有三种，取舍点各不相同。内网直连形态把服务器放在与目标网络同处的隔离演练环境里，任务连接不跨真实边界，好处是流量可控、不触碰生产出口，代价是失去对"真实出网路径"的模拟——这更适合纯检测工程验证，不适合检验边界监控。边界前置形态在受控的演示基础设施上架设前置节点，服务器仍在内网，任务连接先到前置再转发，好处是能测试"边界设备看到什么样的出向流量"，这是紫队流程里最常见的配置。多跳形态通过多个自有的中转节点延长路径，用于模拟真实威胁的纵深基础设施，它对蓝队的价值在于练习"追链"——穿过多层前置之后还能不能把节点串起来。

三种形态在授权与治理上的要求依次升高，因为涉及的第三方网络与数据路径越来越多。选择依据不是"哪个更高级"，而是本次演练的检验目标：检验端点检测，用第一种就够了；检验边界监控与出网策略，至少要第二种。这个"目标决定形态"的决策法，第 5.2 节会再收一次口。

部署形态还有一个绕不开的管理话题：基础设施自身的运维纪律。团队服务器持有全部演练数据，它的系统加固、访问审计、备份策略都按最高敏感级对待——这听起来理所当然，实际执行中常见两类疏漏。疏漏一是图省事复用生产侧的账号与证书体系，让演练设施与生产设施产生了信任关系，隔离的意义被悄悄掏空；疏漏二是演练结束后服务器长期"冬眠"不退役，数据留存超期、系统补丁停更，从资产变成负债。第 5.3 节的台账制度会把这些疏漏收进流程，这里先立个意识：演练基础设施的生命周期管理，与它的部署位置同等重要。

蓝队对照：这个架构给防守方的三个抓手

把镜头换到蓝队侧，三方架构暴露了三个可下手的抓取点。抓取点一：目标侧会话注册后，主机上会出现一个长期存活的调度进程（或注入宿主），这是端点遥测的长期观察对象——第 4.2 节展开。抓取点二：任务连接按节律出向，且目标聚合在少量外部地址上，这在边界流量里形成"少数目的地址、重复访问模式"的组合特征——第 3.3 节展开。抓取点三：通道切换（比如从 HTTP 换到 DNS）会表现为同一主机外联行为的协议突变，跨协议的异常切换本身就是信号。这三个抓手贯穿全书，后面每讲一个机理，都可以回到这里对号入座。

三个抓手之外，还有一个面向工程管理者的提醒：架构决定观测点的优先次序。三方架构里，任务连接的目标聚合在基础设施侧，这意味着"目的地址维度的观测"比"内容维度的观测"更早可部署、更难被规避——这就是为什么预算有限的团队应该先做全量出向日志（便宜且锚定不变量），再考虑内容级设备（昂贵且只覆盖部分通道）。按架构排预算，比按产品排预算更能抵御销售话术。

常见疑问

问：会话能不能不经服务器直接互联？
可以，架构里保留了目标侧节点之间的对等通道，用于在无法直连服务器的网段里"接力"传递任务——这部分属于内网横向通道，机理与约束在 2.3 节讲。但无论路径怎么接力，任务与证据的最终汇聚点仍是团队服务器，这条不变量是审计与取证的锚。

问：为什么客户端被设计成无状态？
为了协作与安全。多人席位共享服务器上的同一份状态，接手同事的会话不需要数据迁移；而客户端本地不存关键数据，笔记本丢失或被入侵时不泄露演练证据。这套"状态集中"的设计思想，与零信任里"数据只在受控面"的思路是同源的。

问：架构里的哪些设计能看出"攻防博弈"的痕迹？
至少两处。一是目标侧永远主动外联而非被动等待——这是为了穿越 NAT 与防火墙的现实约束，同时也是蓝队"出向观测"价值的来源；二是任务队列的"人不在场"设计——它提高了存活性与隐蔽性，也让"指令与动作的时间差"成了取证可利用的结构。看懂这两处你会发现：架构里的每个便利，都在安全上标了价，攻防双方各付各的那份。