政务远程帮办部署踩坑实录——从互联网到政务外网

政务远程帮办部署踩坑实录——从互联网到政务外网

非科班野生程序员，深耕政务信息化20年。这篇博客记录政务远程帮办在真实政务网络环境下的部署过程，两个关键踩坑点的完整复盘。

背景

政务远程帮办要在政务网络环境中部署，而政务网络和互联网是物理隔离的。如何实现：

• 互联网区（老百姓在家）→ 视频信号
• 通过 a机（代理服务器）→ 网闸摆渡 → 政务外网

关键问题：WebRTC 在政务网络里怎么跑？

政务网络架构

完整链路

老百姓（互联网）→ a机（代理转发）→ 网闸摆渡 → 业务系统（政务外网） 视频通信： - 老百姓和窗口人员都在互联网区 - 通过a机转发点对点视频信号 - P2P视频通信太困难，所以用a机中转 - 信令通过a机上的域名 - TURN服务也部署在a机上 业务系统部署： - 帮办的业务系统部署在政务外网 - 通过a机转发摆渡过去 - 一是存储数据安全，二是方便与核心业务系统集成

关键节点

1. 互联网区（老百姓端）

   • 浏览器访问 WebRTC 服务
   • 与 a 机建立连接
   • 没有数据，只是代理转发

2. a机（代理服务器）

   • 外网IP → 互联网区内网IP（a号机）
   • a机代理转发视频信号
   • 不存储视频、音频等任何信息
   • 不洗数据，只转发
   • 还转发外网点对点视频信号
   • 部署信令服务器（使用域名）
   • 部署TURN服务
   • 部署信令服务器（使用域名）
   • 部署TURN服务

3. 网闸摆渡

   • 二重安全墙
   • 边界防护
   • 有抓包分析
   • 必须经过这里才能到政务外网

4. 政务外网（业务系统）

   • 部署帮办的业务系统
   • 通过a机转发摆渡过去
   • 一是为存储数据安全
   • 二是为了方便与核心业务系统集成
   • 窗口人员访问业务系统

安全性设计

1. 外网IP不断变化到互联网区内网IP 2. a机只代理转发，不做数据处理 3. 信令通过a机上的域名 4. TURN服务也部署在a机上 5. 业务系统部署在政务外网，通过a机转发摆渡过去 6. 边界防护 + 抓包分析 7. a机有安全措施保护 8. 视频信号不穿过网闸，只传递信号不传数据

为什么a机很重要？

问题：WebRTC P2P直连在政务网络里走不通

原因：

• 国内没有那么多公网IP
• 老百姓和窗口人员都是互联网区
• 两个互联网区之间有多层防火墙
• STUN直连基本不可能

解决方案：a机必须中转

• a机相当于TURN服务器
• 部署在互联网区
• 视频信号通过a机转发
• 解决NAT穿透问题
• 信令通过a机上的域名
• TURN服务也部署在a机上
• a机不存储视频、音频等任何信息，只转发不保存

为什么视频不能直接转政务外网？

最初的想法：把视频流转发到政务外网

后来认为不行：摆渡是个麻烦事

政务外网和互联网是物理隔离的，网闸摆渡有：

• 长时间等待
• 数据限流
• 潜在风险

折中方案：a机中转，视频留在互联网区

• 老百姓和窗口人员都是互联网区
• 通过a机转发点对点视频信号
• 信令通过a机上的域名
• TURN服务也部署在a机上
• 视频信号不穿过网闸
• 只传递信号，不传数据

信令域名问题

为什么信令不能用IP？

配置：信令服务器域名

为什么： 1. SSL证书要求域名 2. 政务系统域名备案 3. 证书是CA签发的，IP地址不行

实际配置：

varsocket=io('https://xxx.xxx.gov.cn',{path:'/signal/socket.io'});

• xxx.xxx.gov.cn是政务系统域名
• 经过网闸摆渡到互联网区
• 证书由CA机构签发

踩坑1：转发地址配置错误

问题描述

刚开始配置的是政务外网的内网IP

// 错误配置varpcConfig={iceServers:[{urls:['turn:192.168.1.100:3478'],// 错误！username:"******",credential:"******"}]};

现象

• 连接失败
• 无法建立P2P通道
• 一方能看到，一方看不到

原因分析

错误的理解： turn:192.168.1.100:3478 → a机是政务外网的内网IP → 政务外网内网IP直接暴露到互联网 正确的理解： a机在互联网区，有自己的IP 需要配置a机在互联网区的IP和端口

解决方案

与网络工程师沟通后改为：

// 正确配置varpcConfig={iceServers:[{urls:['turn:121.22.33.44:3478'],// a机的外网IPusername:"******",credential:"******"}]};

• 121.22.33.44是a机的外网IP
• 在互联网区
• 通过网闸摆渡到政务外网

学到的教训

1. 网络地址分类要分清楚： - 内网IP（192.168.x.x）= 局域网 - 外网IP（公网IP）= 可以被访问 2. 政务网络很复杂： - 互联网区有自己的内网IP - 政务外网有自己的内网IP - 通过网闸摆渡连接 3. a机不是政务外网的设备 - a机在互联网区 - 有自己的外网IP 4. 必须和网络工程师沟通 - 不懂网络架构 - 配错地址是正常的

踩坑2：TURN在正式环境没有启动

问题描述

开发环境正常，正式环境TURN服务不启动

• WebRTC无法建立连接
• 一方能看到，一方看不到
• 偶尔能连上，但质量很差

定位过程

对比开发环境和正式环境

根本原因

正式环境的配置文件有问题

// production.turn.json（正式环境）{"iceServers":[{"urls":"stun:121.22.33.44:3478"}]}// 错误：没有配置TURN服务器// 开发环境有TURN服务启动，所以能连上

解决方案

修改配置文件：

// production.turn.json（修正后）{"iceServers":[{"urls":"turn:121.22.33.44:3478","username":"user","credential":"pass"}]}

• 增加了TURN服务器配置
• 指定了用户名和密码

重新部署

# 重启TURN服务systemctl restart webrtc-turn# 查看启动日志systemctl status webrtc-turn# 看到：# [INFO] TURN服务已启动，监听 3478 端口

再次测试

• WebRTC连接正常
• P2P通道建立成功
• 视频通话质量良好

部署经验总结

关键要点

1. 政务网络很复杂： - 互联网区 → a机 → 网闸摆渡 → 业务系统（政务外网） - 老百姓和窗口人员都是互联网区 - a机不存储任何视频、音频等信息 - 必须和网络工程师沟通 2. a机的作用： - 代理转发视频信号 - 不存储视频、音频等任何信息 - 不洗数据，只转发 - 部署信令服务器（使用域名） - 部署TURN服务 - 必须中转，解决NAT穿透 - 视频信号留在互联网区 3. 信令必须用域名： - SSL证书要求 - 政务域名备案 - 通过a机上的域名 4. 转发地址配置错误是常见的： - 混淆内网IP和外网IP - 必须和工程师确认 5. TURN服务必须检查： - 对比开发环境和正式环境 - 查看启动日志 - 确认配置文件正确

调试技巧

1. 对比开发环境和正式环境： - 配置文件对比 - 启动日志对比 - 网络拓扑对比 2. 查看浏览器控制台： - WebSocket连接状态 - ICE Candidate获取情况 - 错误信息详细分析 3. 检查网络配置： - 防火墙规则 - TURN服务器状态 - 代理转发配置 4. 测试工具： - Wireshark抓包分析 - 网络延迟测试 - P2P连接质量测试

政务网络特殊性

1. 物理隔离： - 互联网和政务外网隔离 - 网闸摆渡是唯一通道 2. 安全要求高： - 二重安全墙 - 边界防护 - 抓包分析 3. 配置复杂： - 多个网络区域 - 多层NAT - 代理转发 4. 依赖网络工程师： - 不懂网络架构 - 配置容易出错 - 必须沟通确认

部署成功后的效果

功能验证

1. 视频通话： - 老百姓在家接听 - 窗口人员通过互联网访问业务系统 - 一对一视频通过a机中转 2. 屏幕共享： - 老百姓展示电子材料 - 窗口人员查看 3. 录屏录音： - 全程保存 - 格式：WebM视频 + WAV音频 4. 业务系统集成： - 自动加载业务表单 - 录屏录音和业务数据同步 - 业务系统部署在政务外网 - 通过a机转发摆渡过去 5. 安全性： - 视频信号不穿过网闸，只传递信号不传数据 - a机代理转发，不存储视频、音频等任何信息 - 信令通过a机上的域名 - TURN服务部署在a机上 - 边界防护 + 抓包分析

性能表现

1. 延迟： - 视频延迟 300-500ms - 画面流畅 2. 质量： - 720p清晰度 - 音频清晰 3. 可靠性： - 连接稳定 - 不掉线 - 可重新连接

与开发环境的区别

开发环境

特点： - 简化的网络架构 - 单一TURN服务器 - 内网测试 优势： - 配置简单 - 调试方便 - 快速迭代

正式环境

特点： - 复杂的网络架构 - 多个网络区域 - a机代理转发 挑战： - 网络配置复杂 - 防火墙限制 - 依赖网络工程师 优势： - 真实业务场景 - 高安全性 - 生产级质量

最后的思考

为什么政务网络部署这么难？

1. 物理隔离： - 互联网和政务外网隔离 - 网闸摆渡是唯一通道 2. 安全要求高： - 二重安全墙 - 边界防护 - 抓包分析 3. 架构复杂： - 多个网络区域 - 多层NAT - 代理转发 4. 依赖第三方： - 网络工程师 - 网闸设备 - 安全设备

从部署中学到的

1. 理解网络架构很重要： - 不懂网络，配置容易出错 - 必须和网络工程师沟通 2. 实战经验很宝贵： - 踩过的坑就是财富 - 每次部署都是新的经验 3. 调试方法很重要： - 对比环境 - 查看日志 - 抓包分析 4. 政务系统很特殊： - 安全要求高 - 配置复杂 - 依赖网络工程师

总结

政务远程帮办的部署过程，踩了两个坑：

坑1：转发地址配置错误

• 错误：配置了政务外网的内网IP
• 正确：配置a机的外网IP
• 学会：政务网络地址分类要分清楚

坑2：TURN在正式环境没有启动

• 原因：正式环境配置文件错误
• 解决：增加TURN服务器配置
• 学会：对比开发环境和正式环境

关键要点：

• 政务网络架构复杂，必须和网络工程师沟通
• a机必须中转，解决NAT穿透
• 信令必须用域名，不能用IP
• TURN服务必须检查，不能默认启动

部署成功后：

• 视频通话正常
• 录屏录音正常
• 业务系统集成正常
• 全程留痕合规

标签：#政务信息化 #WebRTC #部署 #踩坑 #实战