在做网络工程的这些年里，我遇到过不少类似的需求：

“我们内部有个 Web 系统，领导希望能在外网访问一下，不然每次都得连 VPN 太麻烦。”

听上去简单，但真正要落地，往往涉及网络结构、权限控制、安全策略、流量承载、企业合规等一连串问题。

下面我结合一次典型项目，把我给客户提供的几套可行方案、背后的技术逻辑、实际踩过的坑，都系统地整理出来，供你参考。

客户的背景情况大概是这样：

• 内部 Web 系统部署在内网 10.0.0.x 网段；
• 系统主要被售后人员使用，有时需要在出差时查看；
• 不希望“上外网的人都能访问”，但希望“有权限的人随时能看”；
• 公司规模不大，没有持续运维团队，方案必须稳定、好维护。

这类需求，常见的技术路线分为两类：

1. 把内网系统通过某种方式暴露到外网（可控、有限地开放）
2. 让外网用户通过某种通道“进入内网”后再访问

别看只是顺序上的区别，背后的思路完全不同。在具体实施前，我通常会先和客户沟通清楚以下几个问题：

• 是否必须使用浏览器访问？能不能接受客户端？
• 用户规模？并发量？
• 对访问速度的要求？延迟是否敏感？
• 数据是否敏感？如果泄露会不会造成损失？
• 该系统未来是否会扩展、接入更多模块？

这些问题的答案，会直接决定后面选择的方案。

方案一：公网反向代理（NGINX / Apache）+ 严格访问控制

这是许多公司最容易想到的方案：

通过公网服务器做反向代理，把内网服务“转发”出去。

实施结构大概如下：

外网用户 → 公网服务器(Nginx) → 内网系统(10.0.0.x)

适用场景

• 系统访问量不大
• 能接受在公网“暴露”一个入口
• 运维团队有一定能力维护 Nginx 和防火墙

做法步骤

1. 在云服务器或 DMZ 放置一台 Web 前置机

2. 配置 Nginx 的反向代理指向内网 IP

3. 内外网之间需要开通指定端口（通常是 80/443）

4. 配置强制 HTTPS

5. 再配合一层访问控制：

• 基于 IP 白名单（如果用户固定）
• 基于账号/密码（Basic Auth 或 Web 登录）
• 或者绑定企业统一登录（OAuth2/SAML）

优点

• 实现成本最低
• 用户体验最好：浏览器直接访问
• 开发几乎不需要改动

缺点

• 安全强依赖配置，稍有疏漏可能暴露风险
• 前置机需要长期维护升级
• 内网服务必须对外开通端口（很多客户并不喜欢）

一次类似项目里，客户外网管理员忘记更新 Nginx 的 SSL 证书，导致系统第二天整个都访问不了。后来我们加了证书过期提醒和自动续期。

方案二：VPN 方案 —— IPSec / SSL / OpenVPN / L2TP

这个在传统企业里非常常见：

外网用户先“进入”内网，再访问系统。

结构如下：

外网用户 → VPN → 内网(10.0.0.x) → Web 系统

适用场景

• 需要高安全性
• 内网系统数量不止一个
• 接入人员要控制（可随时开关账号）
• 公司希望“外网不能直接访问任何系统，只能通过 VPN”

优点

• 不需要开放内网端口到公网
• 安全性最高（特别是 IPSec）
• 多个内网系统都可以统一访问

缺点

• 用户端要安装 VPN 客户端
• 初次使用成本高
• 带宽、并发受限于 VPN 网关能力

适合规模

10–200 人的团队最适用。

很多小公司觉得 VPN 麻烦，但从长期维护角度讲，它反而是最省心的：

账号、权限、安全域划分多在一个入口统一管理。

方案三：零信任远程访问（ZTNA）/ SDP（Software Defined Perimeter）

如果客户的预算、未来扩展需求更高，我会推荐使用零信任架构。

核心理念很简单：

不给系统暴露任何公网入口，所有访问都由专门的零信任网关判断权限后动态建立连接。

结构大致如下：

外网用户 → Access Client (或浏览器) → ZTNA 网关 → 内网应用

实现方式

可选择：

• Cloudflare Access
• Zscaler
• 飞书零信任
• 腾讯或阿里零信任产品
• 自建 SDP（成本高）

优点

• 不开端口、不暴露公网 IP
• 不需要 VPN 客户端（浏览器基于身份访问）
• 审计能力强
• 权限细粒度：按用户/应用授权

缺点

• 成本比 VPN 高
• 初次接入需要规划
• 需要一定的 IT 规范度

适用团队

• 20 人以上
• 有对外协作需求
• 应用数量多、权限复杂的企业

方案四：堡垒机 Web 代理（跳板机方式）

许多企业已经部署堡垒机用来管理服务器，那么其实可以利用堡垒机的 Web 反向代理功能（如跳板机自带的“Web 应用授权”模块）。

结构：

外网用户 → 堡垒机（公网入口）→ 内网 Web 系统

特点

• 不需要暴露内部系统
• 堡垒机会记录操作日志，方便审计
• 权限管理较完善

现实问题

• 很多堡垒机的 Web 代理能力不算强
• 某些系统页面会因为 JS/CORS 出现兼容性问题
• 性能不适合大流量

但对于中小企业而言，这种方式更省心。

方案五：内网穿透（frp、nps、tailscale、花生壳）

这是最轻量、成本最低的办法：

在内网部署客户端，把一个端口映射到外网可访问地址。

结构：

内网 → 内网穿透客户端 → 第三方服务器 → 外网用户

适用场景

• 演示环境、测试环境
• 访问量不高
• 临时性访问
• 预算几乎为零

为什么不推荐用于生产？

• 安全性往往达不到企业级要求
• 带宽不稳定，受第三方平台限制
• 某些工具有“被扫描到”的风险
• 无审计能力

不过在我接触过的创业团队中，这反而是最常见的选择，因为太简单、太便宜。

多方案组合

在真实环境里，并不是只能用一个方案。

我给不少客户做的最终方案是组合式的，例如：

外网访问有限制 → 内网访问开放

• 外网用户通过零信任访问
• 内部办公网可直接访问
• 内网服务器之间不能互相访问（避免横向移动）

对外只开放反向代理，但需要双因子

• 外网入口：Nginx + WAF
• 登录必须启用短信/OTP/MFA
• 管理后台不对外，只能内网 VPN 访问

这种方式既保证访问方便，也兼顾安全性。

结合该客户的实际情况（小团队、访问量不高、系统涉及部分业务数据、安全要适中），我给出的三个优先建议是：

1）优先：VPN（SSL VPN 或 IPSec）

• 安全、可靠、成本低、易维护
• 不会对内网系统造成任何改动
• 权限管理清晰

适合长期使用。

2）第二选择：零信任访问（轻量版本）

若企业未来扩展、员工流动较多，用零信任会更“现代”，更灵活。

3）第三选择：Nginx 做公网反向代理 + 强制访问控制

如果企业最在乎访问的“方便性”，这个方式用户体验最好，但安全上要求部署到位（HTTPS、WAF、双因子、IP 限制等）。

让内网系统能在外网访问，从技术角度讲方案太多了，真正的难点在于安全边界怎么划。

我见过太多企业因为“先能访问再说”，结果几年后公网入口越来越多、越来越乱，最后连自己管理员都搞不清楚哪里暴露了什么。

所以每当客户问“我怎么让外网访问到内网系统？”的时候，我通常会反问一句：

“你希望谁能访问？不能访问的人会不会尝试？”

只要这个问题回答清楚，方案怎么做，其实就是技术细节了。

---END---

​

阅读原文：https://mp.weixin.qq.com/s/Blp-4JqlfXcfRKNuisX-hw