客户案例 · 物流行业 · 500 余名员工

内部支持请求减少 90%

一家在三大洲设有仓库的物流企业，让 500 多名员工用上了同一张“开箱即用”的网络 — 然后眼看着 VPN 工单队列烟消云散。

网络环境本就恶劣；旧 VPN 更是雪上加霜

物流人员从货物所在的地方接入网络：运营商级 NAT、客户现场的强制门户、只放行 443 端口的仓库 Wi-Fi。而旧版 VPN 恰恰需要这些网络封锁的端口 — 于是能在任意可用路径上主动外连的网状网络自然胜出。

旧版 VPN 在这里失败的原因

运营商级 NATNAT 套 NAT—超时

强制门户仅放行 443 端口—被拦截

仓库 Wi-FiUDP 被丢弃—被丢弃

OpenVLAN 网状网络主动外连，任意路径—已连接

扫描枪已打标签，仅限同步500+在线

安全团队最喜欢的指标不是工单量的下降 — 而是暴露端点的数量。过去挂在公网 IP、靠脆弱白名单保护的每一个仪表盘，现在只响应经过身份验证的网状网络成员。他们拥有的被扫描最多的资产，就这样从互联网上消失了。

# 之前：暴露在公网的资产

vpn-gw.bluefin.example 暴露 · 被扫描最多

ops-dash.bluefin.example DMZ · IP 白名单

scan-api.bluefin.example 公网 · “临时的”，一挂 2 年

# 之后：同样的应用，私有路径

公网端点：0

每个会话都携带身份 + 设备 + 审计记录

Bluefin 的员工穿梭于仓库、办公室与客户现场之间，常常身处封锁传统 VPN 协议的严格管控网络。他们的旧版 VPN 源源不断地制造“连不上”、“昨天还行今天就不行”、“扫描枪应用超时” — 每月数百张工单砸向一个只有四个人的服务台。

OpenVLAN 的网状网络能够适应物流人员实际使用的恶劣网络：NAT 套 NAT、强制门户、UDP 被封 — 连接总能找到通路。手持扫描枪与仓库网关以打了标签的设备接入，它们同步的运维仪表盘改为私有发布，不再挂在 DMZ 的 IP 上。

一个季度内，内部支持请求下降了 90%。剩余工单几乎全是硬件故障。服务台夺回了自己的午后时光，安全团队则让 VPN 的公网端点退役 — 那是他们拥有的被扫描最多的一项资产。

90%

内部支持请求的降幅

可供扫描的公网端点

大洲，同一张体验一致的网络

“我们的服务台过去每天一开工就面对 VPN 工单队列。现在他们面对的是真正的硬件问题。”
— Bluefin Logistics IT 运维经理

Bluefin 计划将同一张网状网络延伸到冷链 IoT 传感器，用一个网络和一份审计日志取代一堆按厂商各自为政的 SIM 卡 VPN 方案。

本案例为演示用途的示例，数据为虚构。

它实际能在哪些网络上工作？

物流人员实际会遇到的那类网络：运营商级 NAT、客户现场的强制门户、严格管控的仓库 Wi-Fi、LTE 上网卡。节点会在网络允许的任意路径上主动外连 — 只要 HTTPS 能用，网状网络就能用。

手持扫描枪如何接入？

它们以打了标签的设备注册，并应用仅限同步的策略 — 一台扫描枪只能访问库存 API，别无其他。如果哪台从叉车上摔了下来，它的访问权限随之失效，替换的那台会继承相同的配置档案。

季节性用工和临时工怎么办？

访问权限由 HR 的 SCIM 数据流驱动，季节性用工的网络权限会在雇佣结束的同一小时终止。再也没人需要在季末清理遗留账号了。

上线期间仓库有停机吗？

没有。每个站点在现有设备旁加装了一台子网路由器，扫描枪则趁回站充电的机会分站点迁移。旧版 VPN 一直保持可用，直到某个站点连续两周报告零回退使用量为止。

工单队列里还剩什么？

几乎全是硬件问题：碎屏、电池报废、每季度一次叉车事故。网络连接类工单 — 旧队列存在的全部理由 — 已经基本消失。