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

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

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

背景

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

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

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

政务网络架构

完整链路

复制代码

老百姓（互联网）→ a机（代理转发）→ 网闸摆渡 → 业务系统（政务外网）

视频通信：
- 老百姓和窗口人员都在互联网区
- 通过a机转发点对点视频信号
- P2P视频通信太困难，所以用a机中转
- 信令通过a机上的域名
- TURN服务也部署在a机上

业务系统部署：
- 帮办的业务系统部署在政务外网
- 通过a机转发摆渡过去
- 一是存储数据安全，二是方便与核心业务系统集成

关键节点

互联网区（老百姓端）
- 浏览器访问 WebRTC 服务
- 与 a 机建立连接
- 没有数据，只是代理转发
a机（代理服务器）
- 外网IP → 互联网区内网IP（a号机）
- a机代理转发视频信号
- 不存储视频、音频等任何信息
- 不洗数据，只转发
- 还转发外网点对点视频信号
- 部署信令服务器（使用域名）
- 部署TURN服务
- 部署信令服务器（使用域名）
- 部署TURN服务
网闸摆渡
- 二重安全墙
- 边界防护
- 有抓包分析
- 必须经过这里才能到政务外网
政务外网（业务系统）
- 部署帮办的业务系统
- 通过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地址不行

实际配置：

javascript 复制代码

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

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

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

问题描述

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

javascript 复制代码

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

现象

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

原因分析

复制代码

错误的理解：
turn:192.168.1.100:3478
→ a机是政务外网的内网IP
→ 政务外网内网IP直接暴露到互联网

正确的理解：
a机在互联网区，有自己的IP
需要配置a机在互联网区的IP和端口

解决方案

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

javascript 复制代码

// 正确配置
var pcConfig = {
    iceServers: [{
        urls: ['turn:121.22.33.44:3478'],  // a机的外网IP
        username: "******",
        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无法建立连接
一方能看到，一方看不到
偶尔能连上，但质量很差

定位过程

对比开发环境和正式环境

环境	配置文件	启动日志	TURN状态
开发环境	`config.turn.json`	`TURN服务已启动`	✅ 正常
正式环境	`production.turn.json`	无TURN启动信息	❌ 未启动

根本原因

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

json 复制代码

// production.turn.json（正式环境）
{
  "iceServers": [{
    "urls": "stun:121.22.33.44:3478"
  }]
}

// 错误：没有配置TURN服务器
// 开发环境有TURN服务启动，所以能连上

解决方案

修改配置文件：

json 复制代码

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

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

重新部署

bash 复制代码

# 重启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 #部署 #踩坑 #实战