不开 VPN 怎么安全访问内网系统？3 种方案对比

「内网系统怎么给外部同事用？」这几乎是每个运维团队每季度都要被问到的问题。传统答案是搭 VPN，但 VPN 的客户端分发、路由冲突、账号权限过大等痛点，让越来越多团队开始寻找 VPN 替代方案。对中小团队而言，基于开源堡垒机的零信任内网访问正在成为更务实的选择——它不要求给每个人开通网络层隧道，而是把「谁能访问哪个系统」的授权放在应用层来做，并留下完整审计。

本文对比三种主流方案：公网端口映射、自建 VPN、以及基于堡垒机的安全网关反向隧道，并结合 Next Terminal 开源堡垒机说明如何在不开 VPN 的前提下安全访问内网 SSH、RDP 与 Web 系统。操作以当前 v3.7.2 文档为准。

为什么「不开 VPN」越来越常见

VPN 解决的是网络层连通性：客户端接入后，就像把电脑插进了内网交换机。问题也正出在这里。

• 客户端与路由负担重：每个使用者都要装客户端、导配置、处理断线重连，跨平台体验参差不齐，IT 支持成本高。
• 权限边界过粗：VPN 打通的是整段网络，而不是某个资产。账号一旦泄露，攻击者获得的往往是过大的网络权限，横向移动的风险随之而来。
• 审计难以落地：VPN 通常只记录「谁连上、连了多久」，很难回答「谁在什么时间访问了哪台服务器、执行了什么操作」，难以满足运维审计与合规要求。

这股趋势背后还有三个现实推力：远程与混合办公让「外部协作者」成为常态，临时授权需求远高于 VPN 开户与销户的承受能力；云与多云普及后，资产不再集中在单一机房，传统 VPN 的集中式网关成了性能与可用性的单点；安全合规要求也从「能连上」升级到「可追溯」，越来越多的审计要求把会话录像、操作留痕当作硬性指标。

正因如此，「用零信任替代 VPN」的思路被越来越多团队接受：不再默认信任「进入内网的人」，而是对每一次访问都做身份校验与授权。

方案一：公网端口映射——最省事，也最危险

把内网服务器 192.168.1.10:22 通过路由器/云安全组映射到公网 1.2.3.4:2222，是上手成本最低的做法，几分钟就能通。但它的代价同样直接：

• 攻击面外置：22、3389 等端口一旦暴露，扫描器与爆破脚本会在数小时内找上门，日志里很快堆满异常登录尝试。
• 身份与授权缺失：端口映射只解决「能连」，不解决「谁可以连哪一个资产」。端口可达即等于人人可试。
• 审计几乎为零：无法在统一位置追溯谁访问过、访问了什么。

更糟的是，为了记忆方便，很多人会把高危端口映射成 2222、33389 这类非标端口，以为「改了端口就安全」。实际上扫描器会做全端口探测，改端口只是把被发现的时间推迟了几分钟，并不能降低风险。

端口映射适合临时调试或个人项目，一旦涉及多人协作与合规，就难以为继。

方案二：自建 VPN——网络层打通，边界却更模糊

以 WireGuard、OpenVPN 为代表的自建 VPN，加密强度高、接入后访问体验自然，是「不开端口映射」后的第一选择。但它在多人协作场景下的局限也很明显：

• 接入即内网：用户连上 VPN 就默认获得整段内网可达性，细粒度的「谁能访问哪台机器」仍需额外做网络策略，配置复杂。
• 账号泄露代价高：一个 VPN 凭证泄露，等于把内网边界交了出去，且难以快速定位受影响范围。
• 审计弱：VPN 日志难以与「谁操作了哪台服务器」建立关联，事后追溯依赖各主机各自记录。

此外，VPN 网关本身也是一个需要 7×24 高可用维护的组件：证书轮换、客户端版本兼容、双因子接入配置都需要专人投入，一旦网关故障，所有远程办公会同时中断。

VPN 适合网络管理员可控、访问人员相对固定的办公网；但对于「给外部协作者开临时权限」这类高频需求，VPN 的开户、回收与审计成本都不低。

方案三：堡垒机 + 安全网关——零信任、反向隧道

这是本文推荐的方向：在内网部署一个轻量安全网关，由它主动向堡垒机发起 WebSocket 反向隧道连接，内网服务器无需开放任何入站公网端口，也不需要配置端口映射或 VPN。用户通过堡垒机访问资产时，流量经网关转发到内网目标。

相比前两种方案，这条路径有几个关键优势：

• 身份先行：所有访问都经过堡垒机统一登录与授权，天然「先鉴权、再转发」。
• 按资产细粒度授权：授权对象是「某台 SSH/RDP/Web 资产」，而不是整段网络，符合最小权限原则。
• 统一审计与录像：会话操作可录制、可回放，谁在何时访问了什么一清二楚。
• 免开公网端口：网关主动连出，天然适配云 VPC、客户现场、隔离机房等复杂网络。

协议覆盖上，Next Terminal 的资产接入并不限于 SSH——RDP、VNC、Telnet 同样可以经安全网关转发，配合内置的 SSH 代理服务器与 RDP 代理服务器，用户既能在浏览器里直接操作，也能用本地熟悉的客户端工具接入，兼顾易用性与既有工作流。

一条典型的访问链路可以概括为：用户浏览器或本地客户端先登录堡垒机并通过授权校验，随后堡垒机经 WebSocket 反向隧道把请求下发到内网安全网关，再由网关转发到目标资产。整条链路中，内网方向始终没有对外开放的入站端口，攻击者无从扫描，这是它与端口映射、VPN 最直观的差别。

如果你正在评估 JumpServer 替代或 Teleport 替代，安全网关的反向隧道能力与审计完整度是值得重点对比的维度。

三种方案横向对比

方案	连接方向	身份/授权	审计	适合场景
公网端口映射	入站直连	无	几乎无	临时调试、个人项目
自建 VPN	入站直连（网关）	网络层、粒度粗	弱	固定办公网、人员稳定
堡垒机 + 安全网关	反向隧道（连出）	应用层、按资产	会话录像、完整审计	多网络、外部协作者、合规要求

可以看到，方案三用「身份与授权先行」换掉了「网络层放行」，这是它与 VPN 的本质区别，也是零信任落地的最直观形态。

落地方案三：反向隧道 + 按资产授权

方案三落地需要三样东西：一个能主动连外的轻量网关、一台承载身份与授权的堡垒机、一套「谁可以访问哪个资产」的授权模型。下面以开源堡垒机 Next Terminal 为例演示最小闭环——它把网关、授权与会话审计做成了开箱即用，流程与同类产品大同小异，理解了这套结构，换其他堡垒机也能照搬。

以「外网用户访问公司内网一台 Linux 服务器」为例，落地方案三时真正需要决策的不是「敲什么命令」，而是下面几个设计点——理解了这些，具体用什么工具都只是实现细节。

1. 网关放在哪、谁负责暴露

关键判断：网关是主动向外连出的，所以它所在网络的服务器不需要任何入站公网端口。你只需要挑一台能访问目标内网资产的机器放网关，它自己拨号连回堡垒机即可。多机房、多 VPC 场景下，在每个网络各放一个网关，就能用同一台堡垒机统一管理，不必为每个网络单独开公网入口。

2. 资产怎么接、授权粒度到哪

资产接入后会面对一个问题：授权是按「整段网络」还是一个「具体资产」？建议细到资产级别——只把某个用户组能访问的那几台服务器放进来，而不是把整个内网 VPC 一次性授权出去。这样即使某个账号泄露，攻击者能横向移动的范围也被压缩到最小。

3. 审计与录像作为默认项

这类方案相比 VPN 的最大价值是「可追溯」。落地时把会话录像、命令操作留痕当作默认开启项，而不是事后补。谁在什么时间访问了哪台服务器、执行了什么，都应该能在统一位置回放。这既满足合规，也是运维排障时追溯问题的依据。

4. 兼顾本地客户端习惯

纯浏览器操作是堡垒机的默认体验，但很多运维同事更习惯本地 SSH 或 RDP 客户端。如果团队有这类需求，方案要同时支持「浏览器即用」和「本地客户端经代理接入」两种路径，让习惯本地工具的人不必改工作流，访问仍收敛到堡垒机的授权与审计之下。

以 Next Terminal 为例，网关反向隧道 + 按资产授权 + 会话审计是开箱即用的，上述四点它都覆盖；配置细节见安全网关、资产管理与资产访问。其他同类堡垒机落地思路一致，只是具体界面各有差异。

落地时最容易踩的坑

方案三收敛了攻击面，但堡垒机成为唯一的对外入口，这里有几个常见的坑值得提前注意。

网关向内网服务器要入站端口是最典型的误解。网关是主动连出的，内网目标不需要任何入站公网端口，也不需要公网 IP；只要网关所在机器能访问目标内网即可。多机房、多 VPC 时在每个网络各放一个网关，资产创建时选中对应网关，不必为每个网络单独开公网入口。

授权粒度画到整段网络。把整个 VPC 一次性授权出去是最省事却最危险的做法——账号泄露时攻击者能横向移动的范围就是整段网。授权只开放某个用户组需要的几台服务器，攻击面就压到最小。

明文部署堡垒机等于前功尽弃。安全网关的加密通信依赖服务端 HTTPS，务必配有效证书；对面向公网的管理后台启用 2FA 或通行密钥，并定期查看会话录像，把「谁访问了什么」纳入日常巡检。

如果是从端口映射迁移过来，更稳妥的起步顺序是：先关掉对外暴露的 SSH/RDP 端口，把资产接入堡垒机并逐一授权，验证权限无误后再删除公网端口映射和安全组规则，避免新旧两条路并存造成管理盲区。VPN 也不必急着全拆——堡垒机解决的是「按资产的受控访问与审计」，少数需要完整网络层互通的场景（比如开发环境整体互联）里，VPN 仍有价值，两者可以并存。