网络与机房条件
怎样让推理网段对机房外零出站，GPU 机房的场地要核对什么
要让模型留在自己的机房里，推理网段必须对机房外零出站。这是一条能测的规则：出站默认拒绝，写在主机和容器转发两处，每次变更后各测一次失败的对外连接，并留下记录。客户允许模型更新走白名单代理时，那是另一档，叫半离线，要单列承诺。
网段划分
图里蓝色的推理网段，是出站规则要守住的对象。
| 网段 | 放什么 | 可以访问 | 不可以 |
|---|---|---|---|
| 用户网段 | 企业内网用户 | 应用网段 | 推理网段、管理网段 |
| 应用网段 | 经营系统、检索服务 | 推理网段的模型网关端口 | 机房外 |
| 推理网段 | 模型网关、推理引擎、向量库 | 内网镜像仓库、时间源、域名解析 | 机房外 |
| 管理网段 | 监控、运维入口、带外管理口 | 各网段的管理与指标端口 | 业务数据面 |
访问规则逐条列成表，表里没有的一律不通。向量库放在推理网段，应用网段只对检索服务开一个端口。向量能被反推出部分原文，OWASP 把嵌入反推列为向量与嵌入的风险之一（OWASP LLM08），所以向量库的敏感级别按原文库定。
受控入口
受控入口落在管理网段。入口的取舍见私有部署概览。这里只写它们落在哪个网段、要留什么证据：
| 入口 | 所在网段 | 留下的证据 |
|---|---|---|
| 现场 | 机房内终端接管理网段 | 门禁登记、操作记录 |
| 介质闸口或单向网闸 | 更新包经审核后单向进入内网仓库，日志与指标留在机房内 | 入闸记录：文件哈希、签名核对结果 |
| 堡垒机加录屏 | 堡垒机放管理网段，只允许它到各管理与指标端口的连接 | 开通审批、会话录屏、关闭时间 |
一台档的最低要求
一台服务器上没法分出各个网段，但下面这些事仍要做：
| 事项 | 做法 | 依据 |
|---|---|---|
| 带外管理口 | 带外管理口（BMC）不接业务网段，默认凭据换掉 | CISA 与 NSA 的通告把凭据、固件更新和网络分段列为 BMC 最常被忽视的三处（CISA） |
| 监听范围 | 服务只监听内网地址，只留模型网关的端口对外 | vLLM 安全指南建议阻断除 API 服务端口外的所有入站连接（vLLM 安全指南） |
| 出站默认拒绝 | 主机与容器两处，见下节 | — |
| 访问规则成表 | 谁能连谁、哪个端口，写成表，未列出的不通 | — |
一柜的两台推理机若各自装下完整模型、互为备份，机间不需要互通。若一个模型跨两台机并行，vLLM 的指南写明机间流量默认不加密、必须放在隔离网段；需要密码学保护时要在外部另加，例如 mTLS 边车或 IPsec。这时机间网段单独规划，不与管理网段共用。
出站规则
主机上的进程和容器里的进程，出站走的不是同一条路，所以出站默认拒绝要写两处：
| 流量来源 | 经过的钩子 | 规则写在哪里 |
|---|---|---|
| 主机进程（系统更新、时间同步、监控代理） | OUTPUT | 主机防火墙的出站链 |
| 容器里的进程 | FORWARD | Docker 的 DOCKER-USER 链 |
| 外部访问容器发布的端口 | nat 表转发，不经 INPUT | DOCKER-USER 链，不是 ufw 的规则 |
Docker 的文档写明：发布端口的包在 nat 表里被转走，到不了 ufw 使用的 INPUT 与 OUTPUT 链（Docker 数据包过滤）；DOCKER-USER 是留给用户规则的占位链，先于 Docker 自己的转发规则处理，追加到 FORWARD 链的规则则在 Docker 的规则之后，管不到它转发的包（Docker iptables 文档）。同一页提醒，严格的 DROP 规则会挡住回包，应在前面加一条允许 RELATED、ESTABLISHED 的规则。
下面的配置演示这两处怎么写。容器网络在 compose 里用 ipam 固定子网，规则才有稳定的匹配对象。示意，未在目标主机执行；网段取自文档保留地址，按机房规划替换。
默认策略是 drop，允许的只有内网网段、已建立连接的回包和容器自身子网；两处都在丢弃前记日志，前缀都是 egress-denied，落在内核日志里。同一网桥内的容器互访，在装了 br_netfilter 的主机上也可能经过 FORWARD，没有允许自身子网的那一条，模型网关、引擎与向量库之间会被挡住；这是通行说法，Docker 的两页文档都没写，要在目标机上用同一网络的两个容器互相 ping 验证。跨网络的容器互访同样经过 DOCKER-USER，其他容器子网要加进允许的范围。Docker 文档在 nftables 后端处标注了 experimental，上面的 DOCKER-USER 写法针对 iptables 后端；容器网络若启用 IPv6，规则要另写一份。主机侧的 policy drop 配上只含 IPv4 的集合，会同时丢掉全部 IPv6 流量（含邻居发现），主机用 DHCP 续租时也会被挡，用到的主机要另行允许。
验证出站规则
规则写完只是配置，证明靠一次失败的对外连接：
| 测什么 | 怎么测 | 通过 | 留下什么 |
|---|---|---|---|
| 主机出站 | 在推理主机上，向机房外地址发起一次连接 | 超时或被拒，主机一侧出现 egress-denied 日志 | 命令、时间、结果、执行人 |
| 容器出站 | 在推理容器里发起同样一次连接 | 超时或被拒，内核日志出现 egress-denied 前缀的记录；连得通，说明 DOCKER-USER 规则没有生效 | 同上 |
| 重启之后 | 重启主机与容器引擎，各复测一次 | 规则仍在，两次仍被拒 | 同上 |
| IPv6 | 容器网络启用了 IPv6 时，向机房外的 IPv6 地址再测一次 | 被拒 | 同上 |
两处规则都是运行时状态，重启即失。持久化的方式由运维选定，纳入上表的重启复测；Docker 的两页文档都没写规则是否随重启保留。
记录进验收记录，每次变更网络或升级容器引擎之后重做。
网络基础服务
离线环境里，下面几项没有现成的外部服务，要在内网提供：
| 服务 | 为什么要有 |
|---|---|
| 时间源 | 日志里的时间才能互相比对 |
| 域名解析 | 内网服务名才能解析到主机 |
| 内网镜像仓库 | 镜像与权重经审核后进仓库；Trivy 的漏洞库以 OCI 镜像发布，可托管在自有仓库（Trivy 离线） |
| 内网证书与反向代理 | 模型网关前的反向代理终结 TLS 并鉴权，引擎自带的密钥覆盖有限，见私有部署的组成 |
场地条件
场地条件的难点在功率密度。场地项目在设备清单定稿之前核对，结果反馈给估算显卡数量。空间、接地、门禁、到货路径与一般机房相同。GPU 机房的特别之处在下面几项：
| 项 | 核对什么 | GPU 机房的特别之处 |
|---|---|---|
| 供电 | 整机电源铭牌总功率 × 台数，对照回路容量；同一台机的多个电源接不同回路 | 整机与整柜的功率参考见私有部署概览的三档表；参考值来自境外资料，回路容量要按本地电压与相数重算 |
| 制冷 | 机房制冷是否覆盖整机发热；整机进风与出风方向和机柜摆放是否匹配 | 核对所购整机标称的进风范围，三档表按一款风冷整机写作 5–35°C |
| 机柜 | 机位、深度与重量 | 4U 的 GPU 整机比普通服务器深，机柜深度与线缆弯曲空间要对照规格书核对 |
| 承重 | 整机或整柜重量与楼板、机柜承重 | 通用数值未收录，用所购整机规格书与楼板设计复核 |
| 到货路径 | 沿途的门、电梯、走廊与转弯能否通过外箱 | 整机外箱大，暂存位置要提前定 |
限制与不适用
- 机房外只有一个受控入口，排障要等人到场或等审批。
- 允许模型更新走白名单代理的半离线客户，是另一档，要单列承诺。
- 上文的配置样例是示意，没有在目标主机执行。
- DOCKER-USER 的写法针对 iptables 后端；Docker 文档把 nftables 后端标为实验性。
其他做法
| 做法 | 它解决什么 | 为什么不用 |
|---|---|---|
| 常开的远程隧道 | 运维最省事 | 隧道本身是一条出站连接，零出站再也无法用测试证明，见私有部署概览 |
| 只在主机防火墙写出站规则 | 配置最简 | 容器流量走转发路径，主机出站链管不到；私有部署概览已把容器转发路径列入约束 |
验收时可以问的问题
- 受控入口选的是哪一种？请把它写进合同与验收记录。
- 请现场查访问规则表：向量库在哪个网段，除检索服务外没有别的直连。
- 请说明容器引擎用的是 iptables 后端还是 nftables 后端；引擎升级后，请复测 DOCKER-USER 里的规则仍在。
- 一个模型跨机并行时，请出示机间网段的规划表，核对它不与管理网段共用。
- 带外管理口的默认凭据与固件更新由谁负责、多久复核，请在合同中写明。