迁移 VPN：许可、功能与策略记在同一份记录里

旧集中器上仍能工作的会话，看起来像是迁移已基本完成的证据。但它只是清单里的一项，而且是最没意思的一项。切换真正需要的是一份记录，把目标网关、受支持的客户端、已购授权和实际执行的准入策略串成一件有人负责的凭据。没有它，迁移就是一连串单独看都合理的假设。

四列，而不是一张清单

硬件能承载什么、合同允许什么、规则集许可什么，是三个彼此独立的问题，把它们混在一起，只会得到没人能审计的计划。请分列记录，并让每一列注明出处。 一台能接受连接的设备，只证明设备能连上，它对功能范围或计数口径毫无说明。三列互相矛盾，远比一段听起来很有把握的文字有用。

当四列都由有权限的人填好，记录才算完成。由错误负责人签字的列，只是一条带日期的传闻。

平台与授权

记录受支持的网关、客户端操作系统、认证路径和管理工具。不要仅仅因为旧配置文件还能打开，就继续维持过时的客户端；那份配置是一份兼容性声明，供应商可能已不再履行。把当前的支持声明与计划部署的版本对照核查。

授权方面，要记录产品、许可类型、期限和计数口径，并通过账户负责人核对。从历史会话计数去推断权利，正是组织在切换之后、而不是之前发现缺口的方式。

供应商的订购指南说明了这些区分为何重要。例如 Cisco 的Secure Client 订购指南把 Advantage、Premier 和 VPN Only 三档分开，各有自己的计量口径和功能范围。请使用现行协议，而不是机械照搬旧标签。

功能与已执行策略

列出部署真正需要的功能：允许的隧道模式、设备评估、认证集成，以及任何其他模块。每一项都要单独核查支持情况和授权，因为某个功能可能被支持却没许可，也可能有许可却在所选版本上不被支持。只有两个问题都答“是”的行才算数。

当目标是 ASA 时，功能这一列要从设备本身读取，而不是从合同上抄，所以要在切换日之前抓取网关。 show vpn-sessiondb summary 给出活动会话清单，以及衡量你授权的计数； show vpn-sessiondb detail anyconnect 显示每个归属会话实际用了哪种客户端类型和配置文件； show running-config webvpn 抓取这些会话所依赖的网关配置，而这是任何许可文件都无法包含的那部分记录。

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

切换之后，在新网关上跑同样三条命令，并与抓取的副本做比对。会话数变化是预期之内；某一侧出现而另一侧缺失的客户端类型或 webvpn 配置段，才是真正的发现，它应当连同解释写进记录，而不是留在工单评论里。原始抓取和差异都要保存，因为下一位复核者会想看比对的是什么。换成别的供应商，对应物是该平台自己的会话表和配置文件导出，格式对不上，所以要比的是向它提出的问题，而不是文字。

然后把用户和设备映射到目标侧的规则、资源权限和拒绝行为。能启用某项功能的许可，并不等于真正行使它的配置，两者之间的空隙正是大多数迁移意外所在。

拒绝用例要像允许用例一样认真写下来。只证明管理员能连上的计划，只测了最省事的那条路，一个边界都没测。

在决策的两侧都做验收

切换之前，针对预期客户端类型、认证方式和资源跑一份已批准的验收计划。要包含一个必须被拒绝的设备或身份，并确认是哪条规则选中了它、由此产生的会话能到达什么。在变更窗口打开前就谈定拒绝用例，这样没人能在时间压力下悄悄把它们删掉。没有拒绝用例的计划，只测了顺利路径，别的什么也没测。

保留回滚路径和一条不依赖被迁移对象的管理通道。安全保存配置和身份记录，把过时的加密设置留在原处，而不是一路带过去。绝不要把许可标识或用户记录粘进公开笔记。

让负责人同时签署授权和政策映射。完成的记录一次回答两个问题：组织获准部署什么，以及哪些规则真正放行并约束其用户。