企业加密专网 + 1:1 地址别名映射：让跨厂区 OpenHarmony / KaihongOS 设备像在同一局域网内互通

cspeid

70人浏览 · 2026-11-12 11:16:01

cspeid · 2026-11-12 11:16:01 发布

企业加密专网 + 1:1 地址别名映射：让跨厂区 OpenHarmony / KaihongOS 设备像在同一局域网内互通

异地两个厂区的工业终端，互相访问时就像插在同一台交换机上：不改 IP、不改网关、不加路由、不改应用地址，也不安装任何网络客户端；更不必评估 OpenHarmony / KaihongOS 系统是否提供专网客户端能力。两个方向的体验完全一致。

技术上由两部分配合：企业自建加密专网负责让两个 NAT 后的厂区互相可达，**双端对称的 1:1 地址别名映射（本机持有 /32 地址代答 ARP + DNAT / SNAT）**负责把同网段冲突与地址差异抹平。全部改动收敛在两端各一台 Linux 网关上，端侧零改造。

本文的重点是后者——地址映射与回包路径的工程实现，以及现场踩过的坑。

适用范围与合规声明

场景限定：本文讨论的是企业在国内自有 / 经授权的两个厂区局域网之间的内部互联，所有节点、云资源与流量均在国内，用于工业设备远程运维与业务访问。文中「加密专网」指企业自建、自行管理、仅供内部设备互联的专用网络通道。
不涉及国际联网：本方案仅用于企业内部设备互联，不用于访问互联网、不用于访问境外网络、不涉及任何跨境数据通道，也不改变法定网络管理要求，不构成《计算机信息网络国际联网管理暂行规定》第六条所指的「自行建立或者使用其他信道进行国际联网」。确有国际联网需求的单位，应通过国家批准的合法正规渠道办理。
不涉及第三方工具或服务：文中不涉及任何第三方接入工具或商业网络服务的提供、推荐与分发，也不提供客户端下载与服务端分发；云主机为企业实名购买、按规备案的国内云资源，仅作内部流量汇聚。
本文不是专网搭建教程：第三章仅说明「已建成并获授权的企业内部专网」这一前提条件，不展开其申请、部署、密钥分发与客户端配置；全文的技术方案与命令均集中在局域网侧的地址映射与转发，且需在企业网络与信息安全主管部门审批后，由本单位网络管理员在自有设备上实施。
地址脱敏：文中 192.168.1.0/24、10.10.0.0/24 为示例私网网段，云上汇聚节点统一写作示例域名 hub.example.com；真实公网地址、账号、邮箱、密钥、口令、设备 MAC 一律未收录。

问题与目标
总体架构：双端对称的三层通道
前提：企业加密专网（非本文主题）
接入生命周期管理（可跳过）
核心：双端对称 1:1 地址别名映射
验证与验收
排障方法论：一条命令二分，逐段定位
现场实施笔记
踩过的坑清单
适用边界与已知限制
实施清单（每步标注执行环境）
结语
附录 A 参考资料
附录 B 创作说明与版权声明
附录 C 发布配置建议

一、问题与目标

1.1 目标

A 厂区有一批 KaihongOS / OpenHarmony 控制器，B 厂区有同类型终端和一台 Ubuntu 业务服务器。目标是让两地所有普通设备像在同一个局域网里一样双向直接互访，设备侧不做任何 IP、网络配置改动，也不必评估系统是否具备网络客户端能力。

这是工业现场很常见的诉求：设备出厂时业务地址就固定好了，现场批量部署完成后，任何需要逐台登录修改的动作都意味着停机、重新适配甚至重新烧录。

1.2 四个互相打架的约束

#	约束	直接后果
1	两个厂区都在 NAT 后，没有固定公网地址（B 厂区甚至走 5G 链路）	谁都无法接受入站连接，必须借企业在国内云上的汇聚节点做中转，由两侧网关主动出站建立连接
2	两侧厂区局域网都是 `192.168.1.0/24`	网段重叠，常规「加一条到对端网段的静态路由」直接失效：本机会判定对端地址就在自己的直连网段里
3	端侧应用的对端地址固定为局域网地址，且不可修改（示例 `192.168.1.101`）	不能改成专网地址，否则要重新适配 / 重新烧录一批设备；这个差异只能在网络侧吸收
4	端侧是 KaihongOS / OpenHarmony 工控设备	不装客户端、不改 IP / 网关 / 路由；也无需评估设备是否具备专网客户端能力（系统签名、预置 HAP、`VpnExtensionAbility` 一概不涉及）

最容易踩的思维陷阱是：以为「专网打通了」就等于「应用能连上」。约束 2 + 3 决定了这件事根本不是路由问题——

端侧访问 192.168.1.101
  → 用 255.255.255.0 做掩码运算，判定「同网段」
  → 直接发 ARP 广播问「谁是 .101」
  → 不查路由表、不找默认网关、更不会进入任何专用通道
  → 本厂区局域网里没人应答 → 连接失败

包在二层就停住了。此时无论专网链路多健康、路由条目写得多全，都跟它没关系。

1.3 方案选型

路径	做法	结论
A	改应用地址 / 重新烧录端侧镜像	否决：现场设备批量已部署，改动成本与风险最高
B	在端侧安装通用网络客户端	不解决核心矛盾：同网段 ARP 不进 TUN；且标准系统需系统签名与预置 HAP，轻量系统（LiteOS + lwIP）完全不可行
C	厂区 Windows / WSL 做中转	实测失败：mirrored 模式共享 Windows 网络栈，WSL 没有独立 MAC，收不到也发不出局域网 ARP；`proxy_arp`、`ip neigh proxy`、免费 ARP 全部无处生效
D	两侧各一台独立 Linux 网关（物理机或桥接 VM）	✅ 采用：两侧都有独立二层身份，各自代答本侧 ARP、各自维护地址映射，形成对称的双向通道

顺带一个结论：让 OpenHarmony 设备自己当接入点也走不通。其 SELinux 策略里只有 netsysnative 系统服务能执行 iptables，HAP 无此能力；VpnExtensionAbility 提供的是进程内 TUN fd，只把本设备流量导入 TUN，没有「替整个 LAN 做转发」的语义。端侧保持纯终端角色，转发交给 Linux 网关，是这类场景比较稳妥的分工。

二、总体架构：双端对称的三层通道

两台网关做的是同一件事、镜像对称：各自在本侧 LAN 代答「代表地址」的 ARP，把本侧设备发出的包做目的地址转换后送进专网，也把专网里进来的包转换回本侧真实设备。B 厂区那台 Ubuntu 业务服务器天然就是合适的网关人选——它已在企业专网内（wg0 = 10.10.0.2）、eth0 有独立 MAC、有 root 能改网络栈，不需要新增硬件。

角色	局域网地址	专网地址	职责
企业云上汇聚节点	示例域名 `hub.example.com`	`10.10.0.1/24`	监听内部 UDP 端口，按 AllowedIPs 在两台网关之间转发
A 厂区网关	`enp5s0 = 192.168.1.111` + 若干 `/32` 代表地址	`wg0 = 10.10.0.4`	代答 A 侧 ARP、维护映射表、双向地址转换
B 厂区网关（B 厂区 Ubuntu）	`eth0 = 192.168.1.101` + 若干 `/32` 代表地址	`wg0 = 10.10.0.2`	代答 B 侧 ARP、维护映射表、双向地址转换；同时承载业务服务
A 厂区 KaihongOS 控制器	`192.168.1.108`	无	纯终端，零配置
B 厂区 KaihongOS 设备	`192.168.1.108`	无	纯终端，零配置

注意最后两行：两侧设备的真实 IP 可以完全相同（都是 .108）。这正是网段重叠现场最棘手的地方，也是必须引入「代表地址」的原因。

层	解决的问题	关键技术
Layer 1 可达性	两个厂区都在 NAT 后、互相找不到	企业云上汇聚节点 + 两台网关主动出站
Layer 2 生命周期	设备多了怎么管、怎么隔离、怎么回收	内部管理平台：审批 / 分组隔离 / 代表地址分配 / 到期回收
Layer 3 地址适配	网段重叠、地址不可改、端侧不能装客户端	本机持有 /32 地址代答 ARP + 双向 1:1 DNAT / SNAT

2.1 地址规划：一张 1:1 代表地址表（方案的骨架）

两侧 LAN 都是 192.168.1.0/24，所以任何一侧都不能直接使用对端的真实地址：包会在本侧被判定为同网段、直接 ARP，永远进不了专网。做法是给每台需要互通的设备分配两个「代表地址」：

本侧代表地址：在本侧 LAN 内选一个未被占用的 /32，由本侧网关持有并代答 ARP，供本侧设备访问；
专网代表地址：10.10.0.x/32，在汇聚节点的 AllowedIPs 里指给对应网关，用来在专网里唯一标识这台设备。

真实设备	所在侧	对端侧的代表地址	专网代表地址	汇聚节点上归属的网关 peer
B 厂区 Ubuntu 服务 `192.168.1.101`	B 厂区	A 侧 `192.168.1.101`（A 侧网关持有）	`10.10.0.2`（网关自身 wg0）	B 厂区网关 `10.10.0.2`
B 厂区 KaihongOS 设备 `192.168.1.108`	B 厂区	A 侧 `192.168.1.102`	`10.10.0.208/32`	B 厂区网关 `10.10.0.2`
A 厂区 KaihongOS 控制器 `192.168.1.108`	A 厂区	B 侧 `192.168.1.201`	`10.10.0.108/32`	A 厂区网关 `10.10.0.4`

于是：

A 厂区设备访问 192.168.1.102 → 实际到 B 厂区那台 KaihongOS 设备；
B 厂区设备访问 192.168.1.201 → 实际到 A 厂区那台 KaihongOS 控制器；
专网里始终用 10.10.0.108 / 10.10.0.208 这类唯一地址标识目标，不靠端口推断，也不怕两侧真实 IP 撞车。

三条实施约束：① 代表地址在本侧 LAN 内必须先 arping -D 探测；② 只加 /32，绝不能把整个 /24 引到网关，那会抢占本侧全部 ARP；③ 专网代表地址的 /32 必须写进汇聚节点上对应网关 peer 的 AllowedIPs，否则汇聚节点不知道该把包发给谁。

三、前提：企业加密专网（非本文主题）

本章只交代前提，不展开搭建。 企业内部专网的申请、密钥生成分发、客户端准入应由单位网络与信息安全主管部门统一管理；本文的技术内容与命令都从「专网已建成并获授权」之后开始。

3.1 为什么汇聚节点放在企业云上

两个厂区都没有固定公网地址，谁都无法接受入站连接。企业在国内云上的主机有固定地址，于是让它做唯一的监听者；两台网关都主动出站连过去，NAT 映射由各自的出站流量自然建立。5G 链路地址会变，靠 PersistentKeepalive = 25 维持映射。

防火墙两层，缺一不可，顺序不能反：

云厂商安全组 / 网络 ACL（控制台网页或官方 CLI）：按企业安全策略，仅放行两台网关的已知源地址到内部 UDP 端口；脚本管不到这一层。
云主机系统防火墙（ufw allow 51820/udp 一类）：由部署脚本按既有规范处理。

安全组不建议使用全开放源地址，按最小权限只放行两台网关的出口 IP；移动链路若地址不固定，应由单位网络管理员评估后按规范收紧。

3.2 AllowedIPs 不是路由提示，而是加密密钥路由

WireGuard 没有「服务端下发路由」的概念。AllowedIPs 同时承担两个角色：

出方向：目的 IP 落在哪个 peer 的 AllowedIPs 里，包就发给哪个 peer；
入方向：源 IP 不在该 peer 的 AllowedIPs 里，包直接丢弃。

因此它既是路由表，也是访问控制列表。对称方案里这一点尤其关键：

# 企业云上汇聚节点（示意，仅说明前提）
[Peer]  A 厂区网关公钥    AllowedIPs = 10.10.0.4/32, 10.10.0.108/32
[Peer]  B 厂区网关公钥    AllowedIPs = 10.10.0.2/32, 10.10.0.208/32

每增加一台被代理的端侧设备，就要给对应网关 peer 追加一个 /32 代表地址，否则汇聚节点收到 10.10.0.208 的包会直接丢弃。这也是为什么第四章的内部管理平台需要「网关组」资源类型来统一管理这张表。

出站方向同理：网关做了 SNAT 后，源地址变成自己的 wg0 IP（10.10.0.4 / 10.10.0.2），天然落在 AllowedIPs 内；如果去掉 SNAT 改走纯路由，就必须把端侧真实网段也写进 AllowedIPs，而两侧网段重叠会立刻冲突——这也是本方案坚持在网关上做地址转换的原因之一。

3.3 一个会造成「静默全线中断」的坑

wg syncconf 会重置接口级属性。 当传入配置里没有 [Interface] 段时：

listen_port 被置 0 → 内核重新分配随机端口，而客户端 Endpoint 固定写 IP:51820 → 全员失联；
接口私钥被清空 → 汇聚节点无法解密任何握手包，永远不回包。

共同特征是：客户端界面仍显示「已连接」，但数据完全不通。我们在这上面丢过 21 小时，详见第八章的现场笔记。

规则：下发 peer 一律用 wg set 逐个增删，不用 wg syncconf。 每次下发后校验监听端口；再加一层每 60 秒巡检（私钥 / 端口 / 接口存在 / peer 数），异常自动修复并告警。汇聚节点上的 AllowedIPs 变更也必须走内部平台，否则下次 wg set 下发会被覆盖。

四、接入生命周期管理（可跳过）

当被代理的设备从几台变成几十台、且要按项目 / 授权期管理时，手写 [Peer] 段和代表地址表就不够了。我们在汇聚节点同机部署了一个内部管理后台（FastAPI，因为要直接下发 peer、读握手与流量）。它是内部运维工具，不是对外产品：

自助注册 → 提交工单（项目名 + 各系统设备数 + 授权时长）
  → 管理员审批（一级审核，同时激活账号）
  → 原子完成：建组 → 分配 IP → 生成密钥 → wg set 下发 → 打包配置
  → 到期前 24h 双通道邮件提醒 → 到期自动 wg set remove 断开

① 分组隔离做了两层，只做一层等于没做

层	机制	强制性
客户端	下发 conf 的 `AllowedIPs = hub/32 + 本组代表地址段`，组外地址根本不进专网	软（依赖配置正确）
服务端	汇聚节点独立 `WG_GROUP` 链，组内 ACCEPT、跨组 DROP	硬兜底

FORWARD 链最前：-i wg0 -j WG_GROUP
WG_GROUP 链：
  -s <组A> -d <组A> -j ACCEPT
  -s <组A> -d <组B> -j DROP
  -j ACCEPT                      # 兜底：保留经汇聚节点访问其它内部网段

跳转规则必须用 -I FORWARD 1 插到链首。汇聚节点的 PostUp 在链尾追加了 -A FORWARD -i wg0 -j ACCEPT，隔离规则若追加在它后面会永远先命中，形同虚设。对称方案里，代表地址也要按组规划，隔离规则按代表地址段写，而不是按网关的 wg0 IP 写。

② IP 分配要「单调递进」，不要「回填低位空位」

出过一次事故：组内扩容第三台设备时分配到已被占用的 .2，两台 Ubuntu 用同一份 conf（同一私钥 + 同一 IP）同时上线，把第一台的 IP 抢了。根因是两处：分配函数从低位扫描「第一个空位」，而设备吊销后低位会空出来；配置包只给整组生成一份 .conf，现场拿同一份文件装第二台，没改 Address。

修复：used_ips() = 数据库已分配 ∪ 现网 wg show 实际接口 ∪ 汇聚节点自身 IP；next_free_ip() 改为单调递进；build_download_zip() 改为每台有效设备一份 device-序号-类型-IP.conf，外加 设备清单.txt，README 写明「严禁复用同一份 conf」。

一条通用经验：配置下发系统里，「一台设备一份凭据」不是便利性优化，是正确性前提。 对称方案里还多一条：代表地址与专网代表地址的分配也要进同一张表，避免两台设备映射到同一个 /32。

③ 「网关组 / 共享接入」资源类型

一台网关代理一片 LAN，会让平台看到的「一台 peer」实际是一批终端，设备数限制、流量 Top、到期粒度都会失真。第二章的代表地址表正好提供了解法：每台被代理设备一个专网代表地址 /32，平台按这个地址统计流量、算授权时长、做到期回收，口径就恢复准确了。前提是平台能识别「网关组」并维护「网关 ↔ 代表地址 ↔ 端侧设备」的映射关系。

④ 在线判定与时间

latest-handshake 只在重新协商密钥时刷新，keepalive 不刷新它，只按握手判活会误判；改成「连接维度：握手在 180s 内或近 10 分钟有流量」与「使用维度：活跃 / 空闲 / 离线」两维分离。所有时间字段统一存 UTC naive，展示层统一转本地时区。

五、核心：双端对称 1:1 地址别名映射

5.1 设计目标

A 厂区 KaihongOS：访问 192.168.1.102      → B 厂区那台 KaihongOS 设备
B 厂区 KaihongOS：访问 192.168.1.201      → A 厂区那台 KaihongOS 控制器
两侧设备：都不装客户端、不改 IP、不加路由、不评估系统客户端能力
专网内：用 10.10.0.108 / 10.10.0.208 唯一标识目标，双向同一套逻辑

5.2 报文全路径（以「A → B」为例，反向完全对称）

图中节点：A 侧设备 192.168.1.108（KaihongOS / OpenHarmony，不运行任何专网组件）、A 侧网关 192.168.1.111（Ubuntu，wg0 10.10.0.4）、汇聚节点（Ubuntu，wg0 10.10.0.1）、B 侧网关 192.168.1.101（Ubuntu，wg0 10.10.0.2）、B 侧设备 192.168.1.108（KaihongOS / OpenHarmony）。两侧设备真实 IP 相同也不影响，因为专网里用的是唯一代表地址。

整条链路上，两侧设备各只做了一次 ARP 和一次普通 TCP 连接；回包由 conntrack 逐跳反向还原，不需要任何额外规则。

5.3 为什么「只有 proxy ARP」不够（现场最反直觉的一点）

第一次部署时，抓包确认网关能收到端侧发出的 who-has 192.168.1.101 广播，但内核就是不代答：端侧 ARP 表为空、wg0 零包、DNAT 计数为 0。proxy_arp=1 和 ip neigh add proxy 都已生效，仍然无效。

原因：目标地址落在网关入接口自己的直连网段 192.168.1.0/24 内，Linux 不会为「入接口直连网段内的地址」做 proxy ARP 代答。proxy ARP 的语义是「我替别的网段里的主机应答」，不是「我应答同网段邻居」。

修复很朴素：让网关真的持有这些代表地址——在 LAN_IF 上加 /32 别名。内核对本地地址无条件应答 ARP，问题消失。同时不必担心包被本机终结：PREROUTING 的 DNAT 发生在路由决策之前，目的地址已改成专网代表地址，内核会把它转发进 wg0。

一句话：代答 ARP 靠的是「本机持有 /32 别名」，不是 proxy_arp；proxy_arp 只是双保险。两侧网关都一样。

5.4 两侧网关的规则（可直接执行，均需 root；实施前请取得本单位网络管理员审批）

执行环境：A 侧网关（enp5s0 / wg0 = 10.10.0.4）

# ① 持有 A 侧代表地址（代表 B 侧设备，供 A 侧设备访问）
ip addr add 192.168.1.101/32 dev enp5s0
ip addr add 192.168.1.102/32 dev enp5s0
ip neigh add proxy 192.168.1.101 dev enp5s0   # 双保险
ip neigh add proxy 192.168.1.102 dev enp5s0
sysctl -w net.ipv4.conf.enp5s0.proxy_arp=1

# ② 出站：本侧设备访问代表地址 → 目的转换为对端专网代表地址
iptables -t nat -A PREROUTING -i enp5s0 -s 192.168.1.0/24 \
  -d 192.168.1.101 -j DNAT --to-destination 10.10.0.2
iptables -t nat -A PREROUTING -i enp5s0 -s 192.168.1.0/24 \
  -d 192.168.1.102 -j DNAT --to-destination 10.10.0.208

# ③ 入站：专网里进来的、目的为本侧专网代表地址 → 目的转换回本侧真实设备
iptables -t nat -A PREROUTING -i wg0 -d 10.10.0.108 \
  -j DNAT --to-destination 192.168.1.108

# ④ 双向 SNAT（两个方向都不能少，原因见 5.5）
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o enp5s0 -s 10.10.0.0/24 -j MASQUERADE

# ⑤ 双向 FORWARD 放行 + TCP MSS 钳制
iptables -I FORWARD 1 -i enp5s0 -o wg0 -j ACCEPT
iptables -I FORWARD 1 -i wg0 -o enp5s0 -j ACCEPT
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu
sysctl -w net.ipv4.ip_forward=1

执行环境：B 侧网关（B 厂区 Ubuntu，eth0 / wg0 = 10.10.0.2）

# ① 持有 B 侧代表地址（代表 A 侧设备，供 B 侧设备访问）
ip addr add 192.168.1.201/32 dev eth0
sysctl -w net.ipv4.conf.eth0.proxy_arp=1

# ② 出站：B 侧设备访问代表地址 → 目的转换为对端专网代表地址
iptables -t nat -A PREROUTING -i eth0 -s 192.168.1.0/24 \
  -d 192.168.1.201 -j DNAT --to-destination 10.10.0.108

# ③ 入站：专网里进来的、目的为本侧专网代表地址 → 目的转换回 B 侧真实设备
iptables -t nat -A PREROUTING -i wg0 -d 10.10.0.208 \
  -j DNAT --to-destination 192.168.1.108

# ④ 双向 SNAT
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 10.10.0.0/24 -j MASQUERADE

# ⑤ 双向 FORWARD 放行 + TCP MSS 钳制
iptables -I FORWARD 1 -i eth0 -o wg0 -j ACCEPT
iptables -I FORWARD 1 -i wg0 -o eth0 -j ACCEPT
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu
sysctl -w net.ipv4.ip_forward=1

规则是纯地址级 1:1 映射，不含 -p tcp --dport，TCP / UDP / ICMP 走同一条路径，不需要为每个端口写一条规则。每增加一台设备，只需：加一个 /32 代表地址 + 加两条 DNAT + 在汇聚节点的 AllowedIPs 里追加一个 /32。

执行环境：企业云上汇聚节点——把 10.10.0.108/32 追加给 A 侧网关 peer、10.10.0.208/32 追加给 B 侧网关 peer（用 wg set wg0 peer <公钥> allowed-ips ...，或走内部平台统一下发）。

5.5 三个容易漏掉的关键点

① 入站方向也必须做 SNAT。

只做出站 SNAT 时，「B 侧主动访问 A 侧设备」的包经 A 侧网关 DNAT 到 192.168.1.108 后，源地址仍是 10.10.0.2 / 10.10.0.208。A 侧设备回包会按默认网关发给本厂区路由器，而不是发回网关 → 连接超时。加 -o <LAN_IF> -s 10.10.0.0/24 -j MASQUERADE 后，源改成本侧网关的 LAN IP，回包必然回到网关，再由 conntrack 还原。这一步是「端侧零配置」的代价，也是对称方案与单向方案最大的差别。

② FORWARD 必须双向放行 NEW。

单向方案里回程只放行 ESTABLISHED,RELATED 就够；对称方案中两个方向都会有主动发起的连接（都是 NEW），所以 LAN → wg0 和 wg0 → LAN 两条 ACCEPT 都要有，否则一半方向静默不通。

③ 专网里必须用唯一代表地址，不能只靠网关 wg0 IP。

若所有流量都 DNAT 到网关的 wg0 IP（10.10.0.4 / 10.10.0.2），对端网关无从判断该解映射到哪台设备——原始代表地址在第一次 DNAT 时已经丢失。给每台设备一个 /32 专网代表地址，包在专网里始终带着唯一目的地址，转发不需要靠端口推断；顺带让平台的流量、设备数、到期与审计口径全部恢复准确（见第四章 ③）。

5.6 为什么必须是物理机或桥接虚拟机

网关必须收得到本侧 ARP 广播、发得出 ARP 应答，即要有独立 MAC 与独立二层身份。WSL2 默认 networkingMode=mirrored 时 Ubuntu 与宿主 Windows 共享网络栈和网卡：外部 ARP 广播由 Windows TCP/IP 栈独占处理，WSL 的 eth0 既收不到请求，也无法向局域网发送应答。实测免费 ARP、ip neigh proxy、proxy_arp 三种补救全部无效。

两侧都用独立安装的 Ubuntu 物理机，或桥接网卡的虚拟机（混杂模式建议「允许虚拟机」）。有独立机器就直接上物理机，少一层虚拟化、少一个宿主依赖，也是工业现场比较常见的做法。

5.7 两个部署期的环境坑

Docker 把 FORWARD 默认策略改成 DROP。 现场网关装了 Docker，-P FORWARD DROP 且链首被 DOCKER-USER / DOCKER-ISOLATION 跳转占据，-A FORWARD 追加的 ACCEPT 会被干扰 → 一律 -I FORWARD 1 插链首（-C / -D 按规则内容匹配，不受位置影响，幂等性不受损）。两侧都要检查。

wg-quick@wg0 显示 enabled 却是 inactive（现场手工起的专网接口）。systemd oneshot 若写 Requires=wg-quick@wg0.service 会起不来 → 去掉强依赖，改 ExecStartPre 轮询等待 wg0 出现。

rp_filter 设为 0 或 2。 严格反向路径过滤会丢掉从 wg0 进来、源为对端专网段的包；对称方案两个方向都有入站流量，两侧都要查。

5.8 持久化（两侧都要做）

iptables 规则、ip neigh proxy、proxy_arp、别名地址全是运行时状态，重启即丢。比起 iptables-persistent（有交互式保存对话框、挑 nft / legacy 后端），更稳的是写一个 oneshot 服务，开机重放幂等脚本：

[Unit]
Description=LAN gateway address mapping rules
After=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/bin/bash -c 'until ip link show wg0 >/dev/null 2>&1; do sleep 1; done'
TimeoutStartSec=90
Environment="LAN_IF=enp5s0"
Environment="LAN_CIDR=192.168.1.0/24"
Environment="WG_IF=wg0"
Environment="ALIAS_IP=192.168.1.101"
Environment="TARGET_IP=10.10.0.2"
ExecStart=/bin/bash /usr/local/lib/wg-gateway/setup-lan-gateway.sh
ExecStart=/bin/bash /usr/local/lib/wg-gateway/setup-lan-alias.sh

[Install]
WantedBy=multi-user.target

两侧各一份，环境变量按本侧地址改。脚本均幂等：apply 前用 -C 检查规则、alias_ip_owned() 检查别名、proxy_exists() 检查邻居代理；--status 只读查看，--undo 完整回滚。

5.9 端侧零配置清单（两侧设备）

端侧设备什么都不用做：不改 IP、不装或配置网络客户端、不加路由、不改网关、不改应用地址，也完全不必关心 KaihongOS / OpenHarmony 系统本身是否提供专网客户端能力——它只当对端是近端局域网里的一台普通设备。只需要满足：

与本侧网关在同一个二层广播域（能收到 ARP 应答）；
本侧 LAN 内没有别的设备占用代表地址（部署前 arping -D 探测）；
之前若尝试连接失败、ARP 缓存里留了失败记录，清一次 ARP 缓存或重启网络。

若设备允许加路由，还可加 /32 主机路由 192.168.1.102/32 via 192.168.1.111，靠最长前缀匹配把包引到网关，不依赖 ARP 代答，稳定性更好。

5.10 业务服务监听前提

DNAT 之后，包到达对端网关的 wg0 时目的 IP 已经是专网代表地址。若业务直接跑在网关上，服务必须监听：

0.0.0.0:<端口>      或      <网关 wg0 地址>:<端口>

如果只 bind 在物理网卡 192.168.1.101:<端口>（或 127.0.0.1），内核不会把这个包交付给它。Docker 映射同理：-p 192.168.1.101:15022:15022 要改成 -p 15022:15022。两侧的业务服务都要查，反向访问时同样适用。

六、验证与验收

6.1 基础链路实测（A → B 侧服务器方向，已现场验证）

验证项	命令 / 位置	结果
端侧 ICMP	A 侧 `ping 192.168.1.101`	3/3 通，TTL=62，平均 229 ms
ARP 学习	A 侧 `arp -a`	`.101 → A 侧网关网卡 MAC`，动态学习
TCP 转发	A 侧连 `192.168.1.101:22`	收到对端 `SSH-2.0-OpenSSH_8.9p1` banner
二层抓包	网关 `tcpdump -ni enp5s0`	ARP Reply + ICMP/TCP 双向完整
专网抓包	网关 `tcpdump -ni wg0`	`10.10.0.4 ↔ 10.10.0.2`，SYN MSS 1380（TCPMSS 钳制生效）
NAT 状态	网关 `conntrack -L`	同时可见 DNAT 与 MASQUERADE 两条转换，计数 > 0
持久化	`systemctl is-active wg-lan-gateway`	enabled + active；restart 后规则自动恢复

6.2 双向全域互通的验收清单

#	验收项	判据
1	A → B 侧服务器	`ping 192.168.1.101`、业务端口 TCP 可连（已实测，见 6.1）
2	A → B 侧 KaihongOS 设备	A 侧访问 `192.168.1.102`，网关 wg0 抓包应见 `10.10.0.4 → 10.10.0.208`
3	B → A 侧 KaihongOS 控制器	B 侧访问 `192.168.1.201`，A 侧网关 wg0 应见 `10.10.0.2 → 10.10.0.108`
4	反向回包路径	两侧设备 `ip neigh` 里对端表现为本侧网关的 LAN MAC；不依赖端侧静态路由
5	双向 NAT 计数	两侧 `conntrack -L` 都能同时看到出站与入站的 DNAT / MASQUERADE
6	非 TCP 协议	双向 `ping` 通（验证规则确实不限端口、不限协议）
7	汇聚节点路由	`wg show wg0 allowed-ips` 中两个网关 peer 都含各自的代表地址 `/32`
8	服务监听	两侧 `ss -tulnp` 确认业务端口监听 `0.0.0.0`
9	重启恢复	两侧各自 `systemctl restart wg-lan-gateway` 后别名与规则自动恢复

验证状态说明：6.1 为已现场实测的基线数据；6.2 中第 2、3 项所依赖的双端对称映射（代表地址表、入站 SNAT、汇聚节点 AllowedIPs 追加）规则已在本文完整给出，现场联调结果待补充。本文不把未实测的环节写成既成事实。

七、排障方法论：一条命令二分，逐段定位

现场曾反馈「控制器连 192.168.1.101:15022 不通，是不是方案本身不能通？」先纠正一个概念：规则是整 IP 1:1 改写，不含 -p tcp --dport，端口无关，TCP / UDP / ICMP 走完全相同的路径。既然 :22 通，:15022 不通就不是架构上限，而是链路上某个具体环节断了。

7.1 黄金判据：一条命令把问题切成两半

执行环境：本侧网关（它自己就是专网 peer）

nc -vz -w 3 10.10.0.2 15022
# 对称方案里再补一条：直接测对端专网代表地址
nc -vz -w 3 10.10.0.208 15022

这条命令直走 wg0，不经过 ARP 代答与本侧全部 DNAT / SNAT 规则：

结果	结论	下一步
不通	问题在对端服务或汇聚节点路由（监听地址 / 防火墙 / AllowedIPs 未追加 / 服务未启动）	去对端查 `ss -tulnp`、汇聚节点查 `wg show wg0 allowed-ips`
通	专网与对端都好，问题只剩「端侧 → 本侧网关」的二层可达性，或本侧网关规则状态	查 ①② 两段

一次调用就把排查范围压掉一半，这是整套方案里比较实用的一条命令。

7.2 逐段定位表（对称后共六段）

段	位置	判据命令（执行环境）	典型根因
①	端侧 → 本侧网关二层	端侧 `ip neigh show <代表地址>`、`ip route get <代表地址>`	ARP 缓存有旧记录、WiFi AP 客户端隔离、跨 VLAN、静态 ARP；学到的 MAC 必须是网关网卡 MAC
②	本侧网关规则状态	网关：脚本 `--status`、`systemctl is-active wg-lan-gateway`、`wg show wg0 latest-handshakes`	DHCP 租约变化 / 重启导致别名、neigh proxy、iptables 丢失
③	出站 DNAT / SNAT	本侧网关 `conntrack -L`、`tcpdump -ni wg0`	出站 DNAT 目标写错、汇聚节点 AllowedIPs 未含对端代表地址
④	汇聚节点转发	汇聚节点 `wg show wg0 allowed-ips`、`tcpdump -ni wg0`	代表地址 `/32` 没追加给正确的网关 peer
⑤	入站 DNAT / SNAT	对端网关 `tcpdump -ni wg0`、`conntrack -L`	入站 DNAT 缺失；入站 SNAT 缺失导致端侧回包走默认网关
⑥	对端业务服务	对端 `ss -tulnp \| grep <端口>`、`ufw status`	服务只 bind 物理网卡地址、防火墙按源地址限制、服务未启动

7.3 那个 15022 案例的答案

概率最高的根因是 ⑥：对端服务只监听 192.168.1.101:15022。DNAT 后目的已变成专网地址，内核不交付；而 sshd 监听 0.0.0.0，于是「22 通、15022 不通」。修复：监听改 0.0.0.0（Docker 改端口映射写法）。

另一个边界：若目标端口其实在对端 LAN 里另一台未被代理的设备上，需按 2.1 的代表地址表给它补一条映射与一个专网代表地址，并同步汇聚节点的 AllowedIPs。

八、现场实施笔记

这一章按时间顺序记一下实际走过的路，比按知识点罗列更容易看出每个决定是怎么来的。以下均为本单位授权设备的内部实施记录。

起初以为装个客户端就行。 端侧是 KaihongOS 控制器，先考虑在设备上装通用客户端，查下去发现两个问题：标准系统要系统签名和预置 HAP，轻量系统根本没有对应能力；更麻烦的是，就算装上，同网段 ARP 也不会进 TUN。于是把方向改成「网络侧做转发，端侧保持纯终端」。

第一台中转机选了 Windows 上的 WSL，走了弯路。 规则全绿，但外部设备完全连不上。抓包才看清：mirrored 模式下 WSL 与宿主共享网络栈，没有独立 MAC，局域网里的 ARP 广播由 Windows 栈独占处理。免费 ARP、ip neigh proxy、proxy_arp 挨个试过，全无效。后来换了一台独立安装 Ubuntu 的物理机（内网 192.168.1.111），链路才立起来。这一步的教训是：网关的二层身份是硬前提，不是配置能补的。

换物理机后仍然不通，卡在 ARP 代答。 网关能收到 who-has 192.168.1.101，就是不应答。查了一圈才明白 proxy ARP 只替「别的网段」的主机应答，同网段直连地址不在它的语义里。改成让网关自己持有 192.168.1.101/32 别名，内核对本地地址无条件应答，一次就通。当天测到 ping 192.168.1.101 3/3、:22 拿到 SSH banner、wg0 抓包见 10.10.0.4 ↔ 10.10.0.2、conntrack 里 DNAT 与 MASQUERADE 都有计数。

接着撞上 Docker。 这台机器装了 Docker，FORWARD 默认策略是 DROP，链首还被 Docker 自己的跳转占着，用 -A 追加的 ACCEPT 根本轮不到。改成 -I FORWARD 1 插链首才生效。另外 wg-quick@wg0 显示 enabled 却是 inactive（现场是手工起的），systemd oneshot 里写 Requires= 会直接起不来，改成 ExecStartPre 轮询等 wg0 出现。

还有一次 21 小时的静默中断。 汇聚节点下发 peer 时用了 wg syncconf，传入配置没有 [Interface] 段，结果监听端口被重置成随机端口、接口私钥被清空。客户端界面一直显示「已连接」，数据全不通。从那以后下发 peer 一律用 wg set 增量增删，并加了 60 秒巡检。

扩容时出过一次 IP 互抢。 组内加第三台设备，分配函数从低位扫描空位，正好扫到已吊销设备留下的 .2；配置包又只给整组生成一份 conf，现场拿同一份文件装了第二台 Ubuntu，两台同私钥同 IP 同时上线，把第一台挤掉了。后来改成单调递进分配、每台设备独立 conf 加设备清单。

最近一次是 15022 端口不通。 现场问「是不是中转方案本身不能通」。在网关上直接 nc -vz 10.10.0.2 15022 一把刀切两半，确认是服务端侧的事——sshd 监听 0.0.0.0 所以 22 通，业务进程只 bind 了物理网卡地址，DNAT 后目的已变，内核不交付。

当前的进度与克制。 上面这些是单向基线的实测。双端对称的多设备映射（两侧代表地址表、入站 SNAT、汇聚节点 AllowedIPs 追加）规则已在第五章完整给出，但现场联调还没做完，所以第六章 6.2 明确标了「待补充」。另外真机冷启动的完整掉电自启也没擅自去测，只验证了 systemctl restart wg-lan-gateway 能恢复——生产机器不便说停就停。

九、踩过的坑清单

#	现象	根因	修复
1	客户端显示已连接，但数据全不通，持续 21 小时	`wg syncconf` 清空汇聚节点私钥 / 端口漂移成随机端口	一律 `wg set` 增量增删；加 60s 健康巡检
2	网关收到 ARP 广播却不代答，wg0 零包	目标落在入接口直连网段，Linux 不做 proxy ARP	网关持有 `/32` 代表地址（两侧都要）
3	WSL 里规则全绿，外部设备完全连不上	mirrored 模式共享 Windows 网络栈，无独立 MAC	换物理机 / 桥接 VM
4	网关规则全绿但 FORWARD 不转发	Docker 把 `-P FORWARD` 设为 DROP，链首被 Docker 链占据	两侧一律 `-I FORWARD 1`
5	开机后转发失效	iptables / neigh proxy / 别名都是运行时状态	两侧各配 systemd oneshot 重放幂等脚本
6	`wg-quick@wg0` enabled 但 inactive，oneshot 起不来	手工起的专网接口，强依赖 `Requires=` 不满足	改 `ExecStartPre` 轮询等 wg0
7	扩容后两台 Ubuntu 互抢 IP	分配函数回填低位空位 + 整组只发一份 conf	单调递进分配 + 每台设备独立 conf + 设备清单
8	小请求通、大文件卡死	专网 MTU 1420，未钳制 MSS	`TCPMSS --clamp-mss-to-pmtu`（两侧）
9	ping 通、SSH 通、业务端口不通	服务只 bind 物理网卡 IP，DNAT 后目的已变	监听 `0.0.0.0` 或网关 wg0 地址
10	反向访问超时，抓包见 SYN 到了端侧但无 SYN-ACK 回网关	入站未做 SNAT，端侧回包按默认网关发给路由器	`-o <LAN_IF> -s 10.10.0.0/24 -j MASQUERADE`
11	只有单向能通，另一方向静默丢包	FORWARD 只放行 `ESTABLISHED,RELATED`，反向主动连接是 NEW	双向各加一条 ACCEPT
12	包到汇聚节点就消失，对端网关 wg0 零包	对应网关 peer 的 AllowedIPs 没追加专网代表地址 `/32`	`wg set ... allowed-ips` 或走平台下发
13	对端网关分不清该转给哪台设备	所有流量 DNAT 到网关 wg0 IP，原始代表地址已丢失	每台设备一个唯一专网代表地址 `/32`
14	专网 ping 得通，平台显示「离线」	`latest-handshake` 不随 keepalive 刷新	连接 / 使用两维分离，握手 ∨ 近期流量
15	审计时间比系统时间早 8 小时	时间字段混用本地时区	数据库存 UTC naive，展示层统一转换
16	改密 / 停用后旧会话还能用 12 小时	JWT 无失效机制	`token_version`，改密即 +1 使旧 token 作废
17	本机「出站通、入站不通」	Windows Public 网络位置 + Hyper-V 防火墙默认阻止入站	换独立 Linux 网关

十、适用边界与已知限制

代表地址需要规划，且只加 /32。 每增加一台互通设备要加一个 /32 代表地址、两条 DNAT、一个专网代表地址。绝不把整个 192.168.1.0/24 引到网关，那会抢占本侧局域网全部 ARP，直接影响本侧网络。
汇聚节点与内部平台必须配合。 代表地址表不是纯网关侧配置：汇聚节点上两个网关 peer 的 AllowedIPs 要同步追加 /32，平台要能维护「网关 ↔ 代表地址 ↔ 端侧设备」映射并识别「网关组 / 共享接入」资源类型。未经平台下发而手工改汇聚节点，下次 wg set 下发会被覆盖。
端侧看到的对端是网关 IP。 入站 SNAT 把源改成本侧网关的 LAN IP，换来「端侧零配置、回包不依赖静态路由」。若业务强依赖对端真实源 IP，需改走纯路由方案（端侧或主路由加到专网段的路由），代价是端侧不再完全零配置。
分组隔离要按代表地址段做。 一台网关代理一批设备，隔离规则不能只按网关 wg0 IP 写，否则同网关下的不同项目组会互相可见。
两台网关各是一个单点。 任一台故障则该侧整片 LAN 断连。建议静态 IP 或 DHCP 保留、加监控；高可用需 VRRP + 规则同步，尚未实现。
OpenHarmony 端侧当接入点不可行，原因见 1.3；想免掉网关，前提是改应用地址或改现场 LAN 网段，再让每台标准系统设备自行接入专网。
冷启动自启未实测。 已验证 systemctl restart wg-lan-gateway 能恢复，未擅自重启生产机器做完整掉电验证。
两侧 LAN 内都不能有设备占用代表地址，两侧分别 arping -D 探测，不能只看一侧。
本文不覆盖准入合规审批。 实施前需取得本单位网络与信息安全主管部门的审批，云资源、端口开放与访问关系应纳入单位资产管理。

十一、实施清单（每步标注执行环境）

前置条件：企业内部专网已建成并获授权，两台网关均已作为 peer 接入；以下动作由本单位网络管理员在自有设备上执行。

步	执行环境	操作
0	单位网络管理与信息安全审批	确认两厂区互联范围、云资源归属、端口与访问关系已备案；安全组按最小权限仅放行两台网关的已知源地址
1	企业云上汇聚节点	确认专网接口 `10.10.0.1/24` 正常、`ip_forward` 已开、系统防火墙按既有规范放行内部 UDP 端口，peer 状态正常
2	两台网关（各自 Linux）	使用平台下发的各自独立密钥与专属 `.conf` 接入专网，配置 `PersistentKeepalive = 25`；确认 `ping 10.10.0.1` 与对端网关 wg0 地址通
3	地址规划（离线，先做）	按 2.1 定好代表地址表：本侧代表地址（`/32`，两侧分别 `arping -D` 探测）+ 每台设备唯一专网代表地址（`/32`）
4	汇聚节点 / 内部平台	给两个网关 peer 的 AllowedIPs 追加各自代理的专网代表地址 `/32`；用 `wg set` 或走平台下发，不用 `wg syncconf`
5	A 侧网关（root）	按 5.4 第一段执行：加 `/32` 别名、neigh proxy、出站 / 入站 DNAT、双向 SNAT、双向 FORWARD、TCPMSS、`ip_forward`
6	B 侧网关（root）	按 5.4 第二段执行（环境变量按本侧地址改）；确认 `rp_filter` = 0 或 2、Docker 环境用 `-I FORWARD 1`
7	两侧业务服务	确认监听 `0.0.0.0:<端口>` 或网关 wg0 地址；防火墙允许源 `10.10.0.0/24`
8	两侧网关	各装 systemd oneshot，`systemctl enable --now wg-lan-gateway`；网关 IP 改静态或做 DHCP 保留
9	两侧 KaihongOS 设备	无需任何操作：不改 IP、不装或配置网络客户端、无需评估设备客户端能力；应用照常填本侧代表地址与端口，像访问近端邻居一样使用；若之前失败过，清一次 ARP 缓存
10	双向验收	按 6.2 九项逐条验证：两个方向各 `ping` 一次、各连一次业务端口，两端 `conntrack -L` 都能看到出站与入站 NAT，汇聚节点 `wg show wg0 allowed-ips` 含全部代表地址

若要新增网关而非替换，务必走平台的「组内扩容」申请新 peer，不能复制旧 conf——见第九章第 7 条。回滚顺序：两侧各自 setup-lan-alias.sh --undo → setup-lan-gateway.sh --undo → systemctl disable --now wg-lan-gateway，再回平台撤销代表地址。

十二、结语

把这套方案抽象成一句话：

三层专网解决「互相找不到」，本机持有 /32 地址解决「同网段 ARP 不进路由」，双向 1:1 DNAT 解决「地址重叠且不可改」，唯一专网代表地址解决「一台网关代理多台设备时的身份问题」。四层各司其职，把跨厂区的复杂度全部收敛到两端的网络侧——设备不必改 IP、不必配客户端、也不必具备相应能力，用起来就像所有节点都在近端同一个局域网里。

几个可以迁移到其它现场的判断原则：

先判断包停在哪一层。端侧访问同网段地址时先 ARP、后路由；包在二层就停住的话，调专网配置是白费力气。
「一台网关带一片 LAN」要对称地做两次。只在一端部署叫远程访问；两端各放一台网关、各自维护代表地址表，才叫「所有设备像在同一个局域网里」。
能用「持有地址」解决的，别依赖「代理应答」。内核对本地地址的 ARP 应答是无条件的，proxy ARP 有条件且语义容易被误解。
对称之后要立刻处理回包路径。入站不做 SNAT，端侧回包就会走默认网关；这是双向方案与单向方案最容易被忽略的分水岭。
NAT 之后，服务看到的源和目的都变了。写验收用例时，一定要覆盖「只 bind 物理网卡地址」这类隐含假设。
设计一条能二分的判据，比列二十条检查项更有用。
运行时状态一定要有重放机制，iptables、neigh proxy、别名地址、sysctl 全都在重启后消失，两端都要。

附录 A 参考资料

以下均为公开权威资料，用于核对本文涉及的协议语义与内核行为：

WireGuard 官方文档与协议说明 — https://www.wireguard.com/
RFC 826, An Ethernet Address Resolution Protocol — https://www.rfc-editor.org/rfc/rfc826
RFC 3022, Traditional IP Network Address Translator (Traditional NAT) — https://www.rfc-editor.org/rfc/rfc3022
Linux 内核文档 ip-sysctl.txt（proxy_arp、rp_filter、ip_forward） — https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
netfilter / iptables 官方文档与 HOWTO — https://www.netfilter.org/documentation/
conntrack-tools 用户手册 — https://conntrack-tools.netfilter.org/manual.html
OpenHarmony 官方文档：VpnExtensionAbility 与网络管理约束 — https://docs.openharmony.cn/
《计算机信息网络国际联网管理暂行规定》（合规边界，见文首声明） — 中国政府网公开法规文本

本文所有命令均基于 Ubuntu 22.04 LTS 与 Linux netfilter（iptables legacy 后端）验证；不同发行版 / nft 后端需按对应语法调整。

附录 B 创作说明与版权声明

创作说明（AI 参与情况）

本文基于作者团队在工业现场的部署记录、故障工单与抓包结果整理，属于人工实践总结 + AI 工具辅助文字整理。AI 工具仅用于文字润色、Markdown 排版与表格结构化；技术选型判断、地址规划、命令、故障现象、实测数据与排障结论均来自现场实施，并由作者逐条复核。第八章「现场实施笔记」为第一人称原始过程记录。

发布前请按实际情况补充：所用 AI 工具名称、人工修改的具体内容（如结构重构、数据核对、命令验证），并在 CSDN 编辑器中如实勾选 / 填写 AI 辅助创作声明，不要标记与事实不符的「纯自主创作」。

本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。文中示例地址、域名与命令均已脱敏，不构成可直接用于生产环境的配置；读者应结合自身网络环境评估后实施。

脱敏与环境

公网地址统一写作示例域名 hub.example.com；192.168.1.0/24 与 10.10.0.0/24 为示例私网网段；MAC、账号、邮箱、密钥、口令均未收录。
环境：汇聚节点与两台网关为 Ubuntu 22.04 LTS，两端终端为 KaihongOS / OpenHarmony 控制器，内部管理平台为 FastAPI + SQLite + systemd + nginx（原生部署）。
相关脚本：setup-cloud-hub.sh、setup-remote-client.sh、setup-lan-gateway.sh、setup-lan-alias.sh、setup-bridged-vm.sh（后三个为网关侧，支持 apply / --status / --undo）。现有脚本覆盖单侧规则，双端对称部署时按 5.4 的两段规则分别落地。
本文不包含任何生产凭据；分享、转发前请再次确认没有把 .env、keys/、*.conf（含私钥）一并带出。

附录 C 发布配置建议

按国内技术社区（以 CSDN 为例）的发布规范填写，可避开大部分格式类退稿：

项	建议
标题	使用当前标题；关键词「OpenHarmony」「KaihongOS」「地址映射」「局域网互联」前置。若需进一步降低误判，可改为《跨厂区工业终端免配置互通：基于 1:1 地址别名映射的实践》
摘要	120–200 字，示例见下方
分类 / 专栏	网络与通信 → 局域网 / 网络工程；或操作系统 → OpenHarmony
标签	`OpenHarmony`、`KaihongOS`、`网络工程`、`iptables`、`ARP`、`WireGuard`、`工业物联网`（3–5 个，精准细分）
原创声明	勾选「原创」，并如实填写 AI 辅助创作情况（见附录 B）
封面 / 配图	建议把两张 Mermaid 图导出为 PNG 一并上传：既满足「图文结合」的质量维度，也兼容不支持 Mermaid 渲染的客户端与 App
代码块	全文已统一标注语言（`bash` / `ini` / `text` / `mermaid`）；粘贴到编辑器后确认没有丢失语言标记
外链	仅保留附录 A 的官方 / 标准文档链接；不放公众号、二维码、个人联系方式、资源下载群、付费链接
发布前自检	① 文首合规声明完整保留；② 无真实 IP / 账号 / 密钥 / 邮箱；③ 标题、摘要、导语与首屏无容易引起用途误判的表述；④ 未出现绝对化用语与营销信息；⑤ 两张图能正常显示；⑥ 目录锚点在目标编辑器里可用

摘要示例（可直接复制）

两个厂区的局域网都使用 192.168.1.0/24，工业终端的业务地址固定且不便修改，设备也不适合安装任何网络客户端。本文记录一套在企业自有加密专网之上的双端对称 1:1 地址别名映射方案：两端各一台 Linux 网关持有 /32 代表地址代答 ARP，配合双向 DNAT / SNAT 与 conntrack 回程还原，使 OpenHarmony / KaihongOS 设备无需改 IP、改网关、装客户端，即可像在同一局域网内双向互访。文中给出地址规划表、两侧可直接执行的规则、验收清单、排障二分法与 17 条现场踩坑记录，并说明适用边界与合规前提。

本文仅用于企业内部网络工程的技术交流，不涉及国际联网、互联网访问或任何第三方接入工具的使用与传播。

开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

React Native 0.84 鸿蒙 JSBridge 白名单网关：内嵌 H5 越权调用原生的三层拦截与真机实测

开源鸿蒙跨平台开发者社区

Windows 上开发 React Native iOS App，用 KXBuild 连接 iPhone 真机跑 Metro、Fast Refresh 和原生断点

在 Windows 上开发 React Native iOS App 的全流程：用 KXBuild 的模板或社区 CLI 新建项目、体检、在 ios 目录 pod install，接上 iPhone 按 F5，Metro 加载 JS、保存即 Fast Refresh 热更，Swift/OC 原生代码也能断点，已有的 xcodebuild 脚本原样兼容，最后用 Release 配置打出可上架 ipa