从 VPN 迁移到 ZTNA：实用的分阶段指南
从传统远程访问 VPN 迁移到零信任网络访问（ZTNA），并不意味着必须一次性完成具有破坏性的全面替换。
更稳妥的方法是分阶段迁移：先了解 VPN 当前承担的访问任务，再识别适合资源级授权的访问路径，让 ZTNA 与现有 VPN 并行运行，验证实际运营流程，然后逐步缩小 VPN 的访问范围。
目标并不是为了淘汰 VPN 技术本身，而是用对实际所需资源的明确授权，替代不必要的广泛网络访问。
比较 ZTNA 与 VPN · 了解 ZTXGate 的 VPN 替代方案
1. 明确真正要迁移的内容
首先要把 VPN 产品本身与它当前承载的访问模式区分开。
记录以下内容：
- 哪些用户和团队进行远程连接
- 他们访问哪些应用、服务器和子网
- 需要哪些协议
- 哪些用户拥有长期访问，哪些是临时访问
- 如何验证用户身份
- 是否检查设备姿态
- 哪些防火墙或网络分段规则限制 VPN 访问
- 哪些运营流程依赖 VPN
这项盘点会揭示一个重要区别：有些连接只是因为用户需要访问某个具体应用，而另一些场景确实需要更广泛的网络连接能力。
这两类场景不应自动采用同一种迁移方式。
2. 决定哪些访问迁移到 ZTNA，哪些保留
当访问可以明确描述为“已知身份 + 已知设备 + 明确定义的资源”之间的关系时，ZTNA 通常非常适合。
常见候选场景包括：
- 员工访问私有业务应用
- 开发人员访问特定开发系统
- 管理员访问明确的管理服务
- 承包商需要受限或有时间限制的访问
- 用户只需访问一个应用，而不应获得整个子网的访问权限
某些 VPN 场景仍然可能合理，例如：
- 站点到站点连接
- 基础设施网络
- 有意需要广泛协议或子网访问的工作流
- 暂时无法清晰建模为单独资源的遗留环境
成功的迁移并不要求把所有网络访问场景都强行转换为 ZTNA。
3. 选择一个小规模的第一批迁移对象
不要从最复杂或最关键的业务环境开始。
适合试点的环境通常具有以下特点：
- 用户范围容易识别
- 所需资源比较明确
- 访问策略相对简单
- 团队能够提供有效反馈
- 在评估期间，现有 VPN 可以作为受控的备用路径
例如，只需要少量内部开发服务的开发团队，通常比管理大量生产网络的运维团队更适合作为第一批试点。
第一阶段的目的，是验证访问模型和运营流程，而不是一次证明整个企业架构。
4. 建立身份与设备信任
传统 VPN 通常在建立隧道前验证用户身份。ZTNA 则让身份和设备上下文更直接地参与每个受保护资源的授权决策。
迁移前应明确：
- 用户如何认证
- 用户和组如何配置
- 设备如何注册和识别
- 需要哪些设备姿态信号
- 敏感资源是否要求额外认证
- 被禁用用户或被撤销设备如何失去访问权限
在 ZTXGate 中，身份可通过 OIDC 和 SCIM 集成；已注册设备及受支持的设备姿态集成可以参与策略决策。
5. 从资源而不是子网开始建模
VPN 策略通常从网络对象出发：路由、子网、端口、防火墙区域和 ACL。
ZTNA 迁移则应从受保护的资源开始。
不要只问：
这个用户可以连接哪个网络？
而应问：
这个用户应当从哪台设备、在什么条件下访问哪个资源？
资源可以按照业务或运营边界进行分组，例如：
- 开发应用
- 财务系统
- 管理服务
- 生产环境管理接口
- 可供承包商访问的资源
第一批策略应保持简单。过于复杂的规则难以验证，也会增加迁移排障难度。
6. 让 ZTNA 与 VPN 并行运行
分阶段过渡通常比一次性硬切换更容易运营。
试点期间：
- 对已批准的备用场景保留现有 VPN
- 将选定资源迁移到 ZTNA 路径
- 确认用户可以通过新访问模型完成正常工作
- 将新的授权和审计可见性与原有流程进行比较
- 找出最初盘点中遗漏的依赖关系
并行运行可以帮助发现隐藏假设，例如应用会调用其他内部服务、管理员还需要另一种协议，或用户依赖从未正式记录的路由。
备用路径不应成为永久保留两套访问方式的理由。随着新路径的可靠性得到验证，应逐步缩小备用范围。
7. 验证安全与运营，而不仅仅是“能否连接”
用户能够打开应用，并不意味着迁移已经完成。
还应验证完整生命周期：
- 新用户配置
- 设备注册
- 访问审批
- 临时访问到期
- 用户移除
- 设备撤销
- 认证失败
- 策略拒绝
- 审计记录
- 必要时向 SIEM 转发
- 备份和恢复流程
同时应测试外部依赖不可用时的行为。例如，如果策略依赖外部身份、MDM、EDR 或 MFA 服务，应明确这些服务不可达时系统如何处理。
对于受限或断网环境，这一点尤其重要。
8. 按批次迁移
试点稳定后，用同样的方法迁移其他资源组。
一种可行顺序是：
- 低风险内部应用
- 开发和工程资源
- 承包商或合作伙伴访问
- 管理服务
- 敏感生产资源
具体顺序取决于实际环境。关键是让每一批规模足够小，使策略、依赖和回退路径都保持清晰。
每完成一批，都应检查旧 VPN 权限是否可以进一步收紧。
9. 随着 ZTNA 覆盖扩大，逐步缩小 VPN 范围
如果用户迁移后仍保留原有 VPN 权限，那么原本希望减少的广泛访问路径其实仍然存在。
每批迁移稳定后：
- 将已迁移用户移出不再需要的 VPN 组
- 删除不再需要的路由
- 收紧旧访问路径对应的防火墙规则
- 记录仍然必须使用 VPN 的例外情况
- 监控是否存在对已退役访问路径的意外依赖
最终状态可以是完全停用远程访问 VPN，也可以只保留一个更小的 VPN 范围，用于特定网络场景。
两种结果都可能合理。
10. 定义清晰的退出条件
停用旧访问路径之前，应设置客观检查项。
对每个已迁移的用户组确认：
- 所有必要资源都已建模
- 身份和设备注册运行可靠
- 访问策略已经验证
- 临时和审批式访问符合预期
- 监控和审计记录可用
- 支持团队了解新的操作流程
- 恢复流程已经记录
- 没有必要的工作流仍依赖广泛 VPN 连接
这样可以避免项目长期停留在“两套访问系统永久并存”的状态。
示例：一次聚焦式迁移
假设一个开发团队当前通过 VPN 访问多个内部系统。
当前状态
- VPN 提供到开发子网的连接
- 防火墙规则限制部分目标
- 开发人员登录 VPN 完成认证
- 生产管理只开放给较小的特权用户组
第一批 ZTNA 迁移
先定义实际资源：
- 源代码服务
- 开发应用服务器
- 构建系统
- 内部文档
然后应用类似策略：
- 开发团队 → 开发资源
- 仅限已注册设备
- 生产管理 → 单独授权的管理员
- 敏感生产访问 → 有时间限制或需要审批，并要求更强验证
对于尚未迁移的依赖，可以暂时保留 VPN。随着这些依赖逐步明确并迁移，VPN 范围也可以继续缩小。
ZTXGate 如何适配这类迁移
ZTXGate 围绕明确的资源访问设计，而不是广泛的网络准入。
在分阶段 VPN 迁移中，它可以结合：
- 用户与设备身份
- OIDC 和 SCIM 集成
- 设备注册及受支持的姿态信号
- 资源级策略
- 临时访问和申请审批式访问
- 敏感资源的加强认证
- 基于 WireGuard 的受管访问
- 面向合适 Web 应用的许可式无客户端 HTTP/HTTPS 访问
- 集中审计记录与 SIEM 转发
- 由客户或 MSP 运营的部署方式，无需强制依赖 CoreZT 托管的云控制平面
因此，ZTXGate 可以与现有 VPN 并行引入，再按资源逐步扩大覆盖范围，而不要求立即进行全网络替换。
迁移检查清单
进入下一批迁移前，请确认：
- 是否已经盘点当前 VPN 后面的用户和资源？
- 哪些场景确实仍需要广泛网络连接？
- 身份和设备生命周期流程是否准备就绪？
- 资源策略是否足够简单，便于审查？
- 验证期间能否让新旧路径并行运行？
- 是否测试了入驻、撤销、临时访问、日志和恢复？
- 本批次完成后能否缩小旧 VPN 路径？
- 支持和运营团队是否理解新的访问流程？
当每个阶段同时减少不确定性和访问范围时，VPN 到 ZTNA 的迁移最容易管理。
VPN 替代 · ZTNA vs VPN · ZTNA 如何工作 · 自托管与云 ZTNA