司空 2 私有化FAQ
  1. 网络相关
司空 2 私有化FAQ
  • 部署相关
    • 高程数据导入报错 tif_slices"does not exist 问题
    • 解决没有NTP服务可用的问题
    • 机场媒体文件无法上传问题
    • 关于司空2平台调用RTK标定接口进行RTK标定未成功问题
    • 配置OAuth后,三方账号导入管理账户无权限为游客
    • 通过Amazon Cognito 身份平台用户登录白屏问题
    • 司空私有化平台无法修改设备绑定码问题
    • 登录司空平台报异常,且网络显示未连接问题
    • 司空平台删除模型文件后服务器对应文件还是存在问题
    • 司空私有化服务器重启后部分容器无法自动启动问题
    • 司空私有化系admin 账号提示没有权限问题
    • 部署司空报错HTTP 403解决方案
    • 司空服务异常 tas-service 日志报错 CodeMeter Licence Server not found Error 101
    • codemeter启动/导入许可证异常处理
  • 网络相关
    • 司空私有化内外网混合部署下的网络打通
    • 防火墙端口放开策略说明
  • 媒体相关
    • 设备上传媒体文件完成,但是在平台找不到对应的媒体文件
  • 地图相关
    • 离线地图部署各种问题解答
    • 在私有化安装部署中使用在线地图
    • 高程数据导入成功但是地图上不显示高程红色框问题
  • 直播相关
    • 直播黑屏黑屏问题+直播报错超时问题
  • 建模相关
    • 司空页面建模报错问题
    • 客户环境建模报错-已存在重建任务,请等待或取消进行的任务
    • 建模报错 “未找到有效的云端重建证书”
    • 上传模型文件或建模98%报异常问题解决
  • 设备相关
    • 设备上云报超时问题
    • 飞机显示离线且poilt2报错101
  • License证书
    • 部署司空2报codemeter的License相关错误解决
    • 司空私有化license v1.0升级v1.1
    • 4G私有化服务器升级到最新版本教程
  • 二次开发相关
    • 司空2私有版的组织秘钥如何获取?
    • 司空2私有版的组织密钥是不是所有用户都是一样?
    • 通过curl命令访问/openapi/v0.1/flight-task/{task_uuid}/media,点击响应中的url连接提示没有权限
    • 物模型获取API中rainfall字段枚举对应的具体雨量值
    • 如何获取司空2前端PaaS组件的demo文件
    • 消息通知SDK
      • 消息通知SDK配置websocket连接地址后,建立连接失败
      • 如何异步等待websocket连接建立
      • 如何管理多个设备的通知事件
      • 同一个SN存在多个订阅者,消息是如何分发的,是广播模式吗
      • SDK的消息频率设置没生效,设置频率是30秒,消息推送还是1秒1次
      • 飞行任务状态变更事件通知中是否支持获取无人机的SN
      • 是否支持websocket连接健康检查,判断当前连接是否正常
    • 飞行记录PaaS组件
      • window.FH2 报错为 undefined
      • 运行飞行记录组件demo.html但地图区域未加载
      • 飞行记录组件只加载了一部分界面
    • 直播操控SDK
      • 用户使用直播sdk初始化失败
      • 用户使用Nginx服务端部署SDK,无法识别/加载WASM文件
      • 用户调用SDK获取设备列表识别,错误拉取到html页面
      • 运行demo文件依赖的config.json中的字段值怎么填
    • 航线PaaS组件
      • 航点航线全局设置面板消失+模糊
      • 刷新网页后航线组件无法加载
      • 地图渲染错误:cesium render Error Cannott read properties of undefined(reading origin)
      • 地图右下角控件(底图切换)点击无反应
      • 航线Paas组件的全局*号样式会影响客户项目本身的样式
      • 航线预览时地图回中时的中心点是什么
      • PaaS组件是否支持切换英文
    • 驾驶舱PaaS组件
      • 无法进入驾驶舱,浏览器控制台报错,prjId为空
    • OpenAPI
      • 司空2私有版开启直播API能否支持返回RTMP拉流地址
      • /openapi/v0.1/flight-task/{task_uuid} GET API 报200500错误码
      • /openapi/v0.1/flight-task/{task_uuid}/media GET API 报200500错误码
      • 通过curl命令访问/openapi/v0.1/flight-task/{task_uuid}/media,点击响应中的url连接提示没有权限
      • /openapi/v0.9/media/api/v1/workspaces/{proj_uuid}/files GET API返回的create_at是不是媒体的拍摄时间
      • 航线任务的暂停、恢复和终止返航可以通过哪个API实现
      • 在无人机飞行过程中,如何切换直播镜头为红外镜头
  • DJI Inside设备
    • DJI Inside设备媒体文件上传问题
  • 私有化4G增强图传相关
    • 私有化4G增强图传排障流程图
    • 4G私有化服务器第一次登录protainer 需要密码
    • 私有化4G增强图传排障流程图 Copy
  1. 网络相关

司空私有化内外网混合部署下的网络打通

文档编号维护人内容版本号
2025073001RK司空私有化内外网混合部署下的网络打通V1.0
image.png

问题现象#

司空私有化内外网混合部署下无法同时在内外网使用

问题原因#

截至目前,司空私有化仅支持在单一网络使用(要么内网、要么外网)

解决思路#

方案一:通过路由器或网关进行IP劫持做转发(推荐)
方案二:通过DMZ区映射解决

解决方法一:通过路由器或网关进行IP劫持做转发#

1. 步骤1:配置司空#

以上图为例,在司空私有版ENV配置中:

2. 步骤2:配置转发规则#

在出口路由器A执行:
在出口路由器B执行:
该命令详细解释
这条 iptables 命令是一条典型的目标网络地址转换(Destination Network Address Translation, DNAT)规则。它的核心作用是在数据包进入防火墙路由决策之前,修改其目标IP地址。当外部网络的数据包尝试访问 192.168.1.2 这个(通常是内网)地址时,这条规则会将其目标地址重写为 9.9.9.1(一个公网地址),从而将数据包重定向到另一台服务器。
这在需要将内部服务发布到公网,而服务本身没有公网IP地址的场景下非常有用,例如端口转发。

2.1 原理#

iptables 是 Linux 内核中 Netfilter 框架的用户空间管理工具,用于配置防火墙规则。Netfilter 在内核中定义了五个“钩子”(Hooks),数据包在网络协议栈中流经这些钩子点时,会触发相应的规则链(Chain)。
这条命令作用于 nat 表的 PREROUTING 链,其工作原理如下:
1.
数据包到达网络接口:当一个数据包从外部网络到达运行 iptables 的 Linux 主机(通常是路由器或防火墙)的网络接口时。
2.
进入 PREROUTING 链:在内核进行任何路由决策(即判断数据包是发往本机、转发还是丢弃)之前,数据包会首先经过 nat 表的 PREROUTING 链。
3.
规则匹配:
iptables 会检查该链中的规则。
这条规则会匹配所有目标IP地址为 192.168.1.2 的数据包。
4.
执行动作(DNAT):
一旦匹配成功,iptables 就会执行 -j 参数指定的动作,即 DNAT。
DNAT 会修改数据包的目标IP地址,将其从 192.168.1.2 更改为 --to-destination 指定的 9.9.9.1。
重要:Netfilter 的连接跟踪(Connection Tracking)机制会记录下这个地址转换。
5.
重新进行路由决策:目标地址被修改后,内核会根据新的目标地址 9.9.9.1 重新进行路由决策,并将数据包转发出去。
6.
响应包的处理:当目标服务器(9.9.9.1)返回响应数据包时,该数据包会再次到达这台 Linux 主机。连接跟踪机制会识别出这是之前那个被转换过的连接的返回包。在 PREROUTING 阶段,iptables 会自动进行反向DNAT操作,将响应包的源IP地址从 9.9.9.1 修改回 192.168.1.2,然后才发回给原始的请求客户端。这样,对于客户端来说,它感觉自己一直在与 192.168.1.2 通信,整个地址转换过程是透明的。

2.2 参数含义#

下面是该命令中每个参数的详细解释:
参数完整形式含义
iptablesiptables 命令本身,用于管理 Netfilter 防火墙规则。
-t nat--table nat指定要操作的表是 nat 表。iptables 有多个表,nat 表专门用于网络地址转换。
-A PREROUTING--append PREROUTING将这条规则追加(Append)到 PREROUTING 链的末尾。PREROUTING 链处理的是刚进入网络接口,还未进行路由决策的数据包。
-d 192.168.1.2--destination 192.168.1.2这是一个匹配条件,用于指定规则所匹配的数据包的目标IP地址。这里指的是所有发往 192.168.1.2 的数据包。
-j DNAT--jump DNAT指定当数据包满足前面的匹配条件时要执行的动作(Target)。DNAT 是一个特定的目标,表示执行目标网络地址转换。
--to-destination 9.9.9.1这是 DNAT 目标的附加选项,用于指定新的目标IP地址。数据包的目标地址将被重写为 9.9.9.1。

2.3 效果#

执行这条命令后,会产生以下效果:
端口转发/服务发布:所有从外部发送到该防火墙、且目标地址为 192.168.1.2 的流量,都会被透明地重定向到 IP 地址为 9.9.9.1 的另一台主机上。
隐藏内部服务:内部提供服务的主机(192.168.1.2)的真实 IP 地址对外部客户端是不可见的。客户端只知道防火墙的地址(或者它认为的服务地址)。
有状态的转换:由于 Netfilter 的连接跟踪机制,这种转换是有状态的。这意味着一旦一个连接被建立,所有后续属于该连接的数据包(包括响应包)都会被自动正确地进行地址转换,无需为返回的流量再单独设置规则。

3. 步骤3:完成#

完成配置后,可以实现内外网同时使用司空。

解决方法二:通过DMZ区映射解决#

TCP和UDP端口使用和划分请参考:https://fh2-faq.apifox.cn/6965157m0
端口请以实际为准
以下是司空默认端口:
端口服务用途[请根据需求开放相关防火墙]
80司空页面需要开通该端口支持办公访问司空服务
443司空页面(HTTPS)需要开通该端口支持办公访问司空服务
123时间同步设备连接司空,防火墙需要开通端口
1883emqx服务设备连接司空,防火墙需要开通端口
8883emqx加密服务设备连接司空,防火墙需要开通端口
20000agent-emqx服务设备连接司空,防火墙需要开通端口
20001agent-emqx加密服务设备连接司空,防火墙需要开通端口
1935rtmp端口(暂不建议修改)需要开通该端口支持办公访问司空服务,设备连接司空,防火墙需要开通端口
8000webrtc端口(暂不建议修改)需要开通该端口支持办公访问司空服务,设备连接司空,防火墙需要开通端口
8080网关dashboard页面需要开通该端口支持办公访问司空服务
30800运维页面需要开通该端口支持办公访问司空服务
30801minio控制台需要开通该端口支持办公访问司空服务
30802minio服务设备连接司空,防火墙需要开通端口
30803minio-static控制台需要开通该端口支持办公访问司空服务
30804minio-static服务需要开通该端口支持办公访问司空服务,设备连接司空,防火墙需要开通端口
30805terra后端服务司空自用,无需开通防火墙
30806直播服务需要开通该端口支持办公访问司空服务,设备连接司空,防火墙需要开通端口
30807emqx控制台需要开通该端口支持办公访问司空服务
30808agent-emqxws服务需要开通该端口支持办公访问司空服务,设备连接司空,防火墙需要开通端口
30809rabbitmq控制台需要开通该端口支持办公访问司空服务
30810portainer控制台需要开通该端口支持办公访问司空服务
30811grafana控制台需要开通该端口支持办公访问司空服务
30812司空后端服务需要开通该端口支持办公访问司空服务,设备连接司空,防火墙需要开通端口
30813map-custom服务需要开通该端口支持办公访问司空服务,设备连接司空,防火墙需要开通端口

1. 步骤1:准备服务器并配置内核级转发 (iptables)#

注:在这之前,沿用上述司空服务器配置
此步骤将您的 DMZ 服务器 (192.168.1.151) 变成一个路由器,将大部分端口的流量透明地转发到内部服务器 (192.168.1.2)。
1.1. 启用 IP 转发
在 DMZ 服务器 (192.168.1.151) 上,编辑 /etc/sysctl.conf 文件:
找到或添加下面这行,并确保它没有被注释掉(前面没有 #):
net.ipv4.ip_forward=1
保存文件后,运行以下命令使配置立即生效:
1.2. 配置 iptables NAT 规则
执行以下 iptables 命令。这些规则会将 除 Kong 所需端口(80, 443, 8001, 1337)之外 的所有 TCP/UDP 流量都转发到内部服务器。
完成此步骤后,任何发往您 DMZ 服务器(例如 2000 到 7999 端口)的 TCP/UDP 请求都会被自动、透明地转发到内部服务器 192.168.1.2。

2. 步骤2:部署 Kong 用于处理 HTTP/S 流量和修改响应#

现在,我们部署 Kong 来专门处理被 iptables 规则排除在外的 HTTP/S 流量(端口 80 和 443),并执行 IP 地址替换。
2.1. 准备 Docker Compose 文件
在 DMZ 服务器上,创建目录结构:
kong-dmz/
├── docker-compose.yml
└── kong-config/
    └── kong.yml
2.2. docker-compose.yml 文件

3. 步骤3:配置 Kong 的转发与响应修改规则#

创建 kong.yml 文件,定义如何代理 HTTP 流量并替换响应中的私有 IP 为防火墙的公网 IP (8.8.8.1)。
这个配置与之前的方案类似,但现在它的作用域被清晰地限定在 HTTP/S 流量上。

4. 步骤4:启动服务并验证#

4.1. 启动 Kong
在 kong-dmz 目录下,运行 Docker Compose:
4.2. 验证
现在,您可以从外部网络通过防火墙 8.8.8.1 测试两种流量:
验证 L4 (TCP) 转发:
假设您的内部服务器 192.168.1.2 在端口 5432 上运行着 PostgreSQL 数据库。您可以使用 telnet 或 nc 来测试连接(前提是防火墙已将 8.8.8.1:5432 转发到 192.168.1.151:5432):
如果连接成功,说明 iptables 的 L4 转发规则正常工作。
验证 L7 (HTTP) 转发与修改:
使用 curl 请求端口 80。
观察返回的响应。您应该能看到所有 192.168.1.2 的实例(无论在响应体还是 Location 头中)都已经被成功替换为 8.8.8.1。

5. 补充说明(可选)#

方案的健壮性:此混合方案兼顾了性能和功能。iptables 以线速(wire-speed)处理绝大多数 L4 流量转发,开销极低。而 Kong 则专注于其最擅长的 L7 领域,为 HTTP/S 流量提供丰富的策略控制和内容修改能力。
nftables:nftables 是 iptables 的现代替代品,语法更清晰,性能也更好。如果您的系统较新,可以考虑使用 nftables 来实现 L4 转发,其原理是相同的。
IP 地址的硬编码:请注意,此方案在多个地方硬编码了 IP 地址(8.8.8.1, 192.168.1.2 等)。在更复杂的自动化部署中,建议使用环境变量或配置管理工具(如 Ansible)来动态管理这些值。
修改于 2025-07-30 11:30:41
上一页
codemeter启动/导入许可证异常处理
下一页
防火墙端口放开策略说明
Built with