光盘摆渡机：物理隔离下的自动化数据交换与校验

简介：这是一份面向政府机关、涉密单位信息化建设人员与网络安全方案设计者的技术报告文档，围绕内外网物理隔离场景下的光盘摆渡机解决方案展开。报告从国家关于涉密计算机信息系统必须实行物理隔离的法规要求出发，剖析了人工刻盘效率低下、网闸光闸逻辑隔离不完全等现实矛盾，进而提出以机械手自动搬运光盘实现数据安全交换的系统思路，涵盖系统架构、传输方向定制、工业级可靠性设计，并附省级投资项目在线审批监管平台的实际部署案例与拓扑说明，可供方案选型、立项论证与投标参考。资源包内含1个doc文档，压缩包约3.19MB，目录与章节结构完整，便于按背景、系统简介、特点、实施案例等模块检索查阅。目前已有141人学习下载，适合需要撰写同类隔离交换方案或了解摆渡机技术路线的读者参考借鉴。

1. 光盘摆渡机到底在补哪个断点：物理隔离与数据交换的矛盾

把一个 3GB 的数据库导出文件从生产网搬到办公网，最土的办法是让人抱着 U 盘走过去。而在高安全等级的隔离环境里，这往往是唯一被允许的路径。光盘摆渡机做的事情，就是把这个动作交给机械手：外网服务器把数据刻到光盘上，机械手把盘从外网刻录机里取出来，移到内网驱动器，内网服务器读完盘，再把盘丢进废盘斗。整套系统里，内外网服务器之间没有一根网线，也没有网闸、光闸那种逻辑通道，唯一的"连接"是一张会移动的光盘。

它要解决的矛盾很具体：物理隔离保证了安全，但业务上内外网又必须交换数据——审批数据回传、统计报表上报、基础库同步，一天几十个批次并不稀奇。人工刻盘能保住物理断点，却架不住效率低、操作不可控；网闸靠专用硬件做协议剥离，效率上去了，但两侧仍然各接一根网线，属于逻辑隔离。摆渡机把"物理断开"和"自动化"这两件互相打架的事凑到了一起，代价是带宽被机械动作卡死在每秒十几兆的量级。

适合读这份东西的人大致三类：做网间数据交换中间件的开发，负责隔离区日常运维的工程师，以及要给这类项目做方案设计和验收的集成人员。下面按物理链路、文档参数提取、调度校验、跑稳技巧的顺序拆。

2. 拆开物理链路：机械手、内外网服务器与光盘介质怎么配合

2.1 三段式拓扑与两侧服务器的分工

摆渡系统在结构上永远是三段：外网服务器、摆渡机构、内网服务器。外网服务器是写入方，负责把业务数据打包成待刻录目录或 ISO、驱动刻录机、记录任务状态；摆渡机构是纯机电部分，包含盘库、机械手、至少一台刻录机和一台只读驱动器、废盘斗；内网服务器是读取方，负责挂载光盘、校验清单、把数据落到内网库，并生成回执。

两侧服务器都是独立主机，电源、网络、机柜都可以分开。真正的隔离点不在软件配置里，而在机械手的那段行程中——盘在空中移动的那几秒，就是整套系统的安全边界。

2.2 机械手抓盘参数与"非接触"的工程含义

机械手的选型直接决定吞吐和可靠性。工程上需要盯住几个参数：单次抓取-放置周期（通常 8～20 秒，取决于行程和盘库层数）、定位重复精度（一般要求优于 0.5mm，否则放不进驱动器托盘）、盘库位数（决定无人值守能撑多久）、以及整机无故障动作次数。厂商常标称主要配件可达 250 万次量级，这个数字要折算：按 15 秒一次循环算，250 万次约等于连续跑 430 天不停机，实际运维里更该关注的是吸盘胶垫和传动皮带这类耗材的更换周期。

所谓"非接触"指的是抓取时不触碰光盘的数据面。常见做法是负压吸盘吸住盘的中心孔区域，或者用夹爪只卡外缘 1～2mm。这个细节在验收时最容易被跳过，但盘面划伤会直接表现为读取阶段的误码率上升，而不是抓取失败——故障现象会跑到下游去，排查方向很容易带偏。

顺带算一笔吞吐账，这是方案评审时最常被追问的数字：

结论是容量越大越划算，因为机械动作的固定开销被摊薄了。但别只看这个数：如果业务是每小时一次的小批量同步，瓶颈根本不是容量，而是单次循环的固定时延。

2.3 单向还是双向，以及介质与配置怎么写

传输方向由盘库和驱动器的物理布局决定。单向场景下，外网刻录机只刻不读、内网只读不刻，两条光路物理上不交叉；双向要么做两套独立机构，要么复用机械手但严格串行，绝不允许同一张盘在两个方向上重复使用。常见做法是一盘一用，读完直接进废盘斗做物理损毁，靠介质的一次性来杜绝跨域残留。如果确实要复用可擦写介质，至少要保证刻录前整盘擦除并回读确认全零。

刻录与摆渡的调度参数集中在一个配置文件里，两侧各持一份，靠 task_id 对齐：

# 摆渡节点配置，外网侧与内网侧各一份，除 direction 外其余字段必须一致 ferry: direction: outer_to_inner # outer_to_inner / inner_to_outer media: DVD # CD / DVD / BD，两侧驱动器必须同一代 stage_dir: /data/ferry/stage # 待刻录包落地目录，与业务数据目录分开挂载 max_payload_bytes: 4500000000 # 留出清单与文件系统开销，别按标称 4.7G 卡满 burn: drives: [/dev/sr0, /dev/sr1] # 双驱交替，机械手取盘时另一路继续刻 retries: 2 # 刻录失败重试次数，超过就换盘并告警 verify_after_burn: true # 刻完立刻回读校验，别等摆到内网才发现坏盘 keep_disc: false # false = 读完进废盘斗

max_payload_bytes是最容易出事的一个参数。DVD 标称 4.7GB 是十进制，文件系统能看到的是 4.38GiB 左右，再扣掉 ISO9660/Joliet 的目录开销，4.5×10⁹ 字节已经接近上限。写满盘不会报错，只会让刻录在最后阶段失败，而失败的时候机械手往往已经把盘取走了。

3. 把 .doc 报告书变成可执行参数：格式判定与摆渡任务建模

手里这份《光盘摆渡机解决方案报告书.doc》是 Word 97-2003 的二进制格式，属于典型的旧版复合文档。里面真正有价值的东西是拓扑描述、介质类型、单向/双向选项和可靠性指标，但这些参数要变成可执行的配置和数据库字段，中间隔着一次格式转换。

3.1 先判断文件到底是什么格式

拿到.doc先别急着找解析库，第一步是看文件头。很多所谓的 doc 其实是 docx、RTF 甚至 HTML 被改了后缀，直接按二进制 doc 去解会一路报错：

# 看魔数，比后缀可靠 file ./光盘摆渡机解决方案报告书.doc xxd -l 8 ./光盘摆渡机解决方案报告书.doc # D0 CF 11 E0 A1 B1 1A E1 -> OLE2 复合文档，真·Word 97-2003 # 50 4B 03 04 -> 其实是 docx（ZIP），只是后缀叫 doc # 7B 5C 72 74 66 -> RTF 文本

这个判断决定了后面走哪条路。OLE2 格式的文本被拆在 WordDocument 流和 Table 流里，还有一段 piece table 负责拼接，自己写解析器不划算。

3.2 三条可用的抽取路线

命令行环境优先走前两条：

# 路线一：直接抽纯文本，编码显式指定，避免 GBK 混进 UTF-8 管道 antiword -m UTF-8.txt ./光盘摆渡机解决方案报告书.doc > report.txt # 路线二：无头模式转 docx，保留表格与段落结构 soffice --headless --convert-to docx --outdir ./out ./光盘摆渡机解决方案报告书.doc

-m UTF-8.txt指定映射文件，不加的话中文会按本地代码页输出，后面 grep 中文关键词全是乱码。--headless让 LibreOffice 不起界面，适合放在转换脚本里批量跑，注意同一个用户目录下不要并发调用，它会有锁文件冲突。

3.3 用 python-docx 抽取参数表

转成 docx 之后，表格和段落是两个独立的集合，按需取：

from docx import Document doc = Document("./out/光盘摆渡机解决方案报告书.docx") # 段落：用于抓取方向、介质类型这类散落在正文里的描述性参数 for p in doc.paragraphs: text = p.text.strip() if any(k in text for k in ("单向", "双向", "物理隔离", "机械手")): print("[P]", text) # 表格：用于拓扑、指标这类结构化参数 for i, table in enumerate(doc.tables): print(f"--- table {i} ---") seen = set() for row in table.rows: cells = [] for c in row.cells: # 合并单元格会让同一个 tc 元素重复出现，按对象 id 去重 if id(c._tc) in seen: continue seen.add(id(c._tc)) cells.append(c.text.strip().replace("\n", " ")) print(" | ".join(cells))

不按id(c._tc)去重的话，横向合并的单元格内容会重复出现，抽出来的表格列数对不上，后面按列取参数就会错位。这一步在这个文档上尤其明显，因为它有大量跨行说明。

3.4 把参数落成摆渡任务表

抽出来的参数最终要变成调度系统能读的表。核心字段是任务标识、方向、待刻录包、整包哈希、介质类型和状态：

CREATE TABLE ferry_task ( task_id BIGSERIAL PRIMARY KEY, direction SMALLINT NOT NULL, -- 1=外到内, 2=内到外 payload TEXT NOT NULL, -- 待刻录目录或 ISO 的绝对路径 payload_bytes BIGINT NOT NULL, -- 打包后总字节，用于容量预检 sha256 CHAR(64) NOT NULL, -- manifest 清单文件的哈希 media_type VARCHAR(8) NOT NULL, -- CD / DVD / BD disc_id VARCHAR(64), -- 刻录机上报的介质序列号 status SMALLINT NOT NULL DEFAULT 0, -- 见 4.1 状态机 retry_count SMALLINT NOT NULL DEFAULT 0, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), finished_at TIMESTAMPTZ ); CREATE INDEX idx_ferry_task_status ON ferry_task (status, created_at);

payload_bytes在入库前就做容量预检，避免第 2 章提到的"刻到最后一刻才失败"。sha256存的是清单文件的哈希而不是单文件哈希，一张盘一个值，方便两侧一句话对齐。disc_id是排查坏盘的关键字段，同一张盘反复失败时可以直接拉黑。

4. 调度与校验落地：从写盘到入库的完整闭环

4.1 任务状态机

摆渡任务的难点不在单步执行，而在两侧对同一张盘的认知要一致。状态机设计成一条单向主线，任何一步失败都退回待重试而不是原地打转：

4.2 待刻录包与清单生成

打包这一步要保证同一批数据每次生成的清单完全一致，否则重试后会得到不同的哈希，两侧对账永远对不上：

import hashlib, json, pathlib def sha256_file(path, buf=1 << 20): h = hashlib.sha256() with open(path, "rb") as f: # 分块读，BD 级别的大包不能整块进内存 for chunk in iter(lambda: f.read(buf), b""): h.update(chunk) return h.hexdigest() def build_stage(src_dir, stage_dir): stage = pathlib.Path(stage_dir) stage.mkdir(parents=True, exist_ok=True) manifest = [] # sorted 保证同名文件集合两次生成的顺序一致，清单哈希才可复现 for p in sorted(pathlib.Path(src_dir).rglob("*")): if not p.is_file(): continue manifest.append({ "name": str(p.relative_to(src_dir)), "bytes": p.stat().st_size, "sha256": sha256_file(p), }) (stage / "manifest.json").write_text( json.dumps(manifest, ensure_ascii=False, indent=2), encoding="utf-8") return manifest

buf取 1MB 是 IO 与 CPU 的折中，再大对机械硬盘没收益。ensure_ascii=False保留中文文件名，避免在盘上出现一长串\uXXXX。真正刻录时建议先打成 ISO 再写盘，而不是把散文件直接往会话里塞——ISO 是一次成型的，中途断电不会留下半个目录结构。

4.3 内网侧校验与幂等入库

内网读完盘，第一件事是拿 manifest 逐文件比对，而不是直接入库：

import pathlib def verify(stage_dir, manifest): bad = [] base = pathlib.Path(stage_dir) for item in manifest: p = base / item["name"] # 三道检查：存在、字节数、哈希，缺一不可 if (not p.exists() or p.stat().st_size != item["bytes"] or sha256_file(p) != item["sha256"]): bad.append(item["name"]) return bad

只看字节数不够。光盘读取错误经常表现为内容被替换成零字节块，长度不变但哈希变了，所以哈希比对是必须的。校验通过后入库要写成幂等的，重读同一张盘不能产生重复行：

INSERT INTO ferry_payload (task_id, name, sha256) VALUES (%s, %s, %s) ON CONFLICT (task_id, name) DO NOTHING;

4.4 常见失败点与排查顺序

排查顺序建议从两头往中间收：先确认外网侧 manifest 是不是预期的那一份，再确认内网侧读到的字节数，两头都对得上才去怀疑介质。

5. 让摆渡系统长期无人值守的几个具体技巧

5.1 用"盘位预算"倒推巡检周期

无人值守能撑多久，取决于盘库能装多少张空盘、废盘斗能装多少张废盘，以及每天的摆渡次数。做个简单的预算表比拍脑袋靠谱：

真正要盯的是"剩余可用盘位"这个指标，而不是"最近一次任务成功"。任务一直在成功、盘库快见底的时候，系统会在某一次抓取时直接失败，而失败原因写的是"取盘超时"，跟盘库没盘看起来毫无关系。把剩余盘位做成阈值告警，比事后看日志省事得多。

5.2 用三方计数做自动对账

验收阶段最有效的做法不是抽样点开文件看，而是跑一个三方计数脚本：外网侧 manifest 的文件数与总字节、内网侧实际落库的行数与总字节、业务表增量行数，三个值必须完全吻合。任何一次摆渡结束后都跑一遍，对不上就立刻把这张盘的 disc_id 标出来，比隔天业务方报"数据缺了一条"再回溯快得多。

一个容易被忽略的对账细节是时区。外网服务器用本地时间写 manifest，内网服务器用 UTC 记录 finished_at，两者相减会差出好几个小时，做增量窗口过滤时就会漏数据。统一在 manifest 里存 ISO8601 带偏移量的时间戳，比存格式化字符串安全。

5.3 双驱交替与坏盘拉黑

机械手的固定行程是吞吐上限，但刻录本身可以并行。双驱交替的做法是：A 驱在刻的时候机械手去取 B 驱刚刻好的盘，等机械手放完盘回来，A 驱正好刻完。这样机械动作时间被完全掩盖，吞吐能提升接近一倍。前提是调度器要按驱动器维度而不是任务维度排队，否则两个任务会抢同一台刻录机。

坏盘鉴别则靠一个计数器：同一disc_id或同一驱动器连续两次校验失败，就写进黑名单表，调度时直接跳过。介质是消耗品，坏盘会成批出现——同一盒盘往往同一批次生产，连续坏两张就该整盒换掉，而不是一张一张试过去。

本文还有配套的精品资源，点击获取