Migrar una VPN: licencias, funciones y política en un solo registro

Las sesiones que todavía funcionan en el concentrador antiguo parecen prueba de que la migración está casi terminada. Son un solo elemento del inventario, y el menos interesante. Lo que el cambio necesita es un registro que ate la puerta de enlace de destino, el cliente compatible, el derecho adquirido y la política de admisión aplicada en un único artefacto que alguien posea. Sin él, la migración es una serie de supuestos que, por separado, parecen razonables.

Cuatro columnas, no una lista de verificación

Qué puede soportar el hardware, qué permite el contrato y qué admite el conjunto de reglas son tres preguntas separadas, y mezclarlas produce un plan que nadie puede auditar. Manténgalas en columnas separadas y haga que cada una cite su fuente. Un dispositivo que acepta una conexión demuestra que un dispositivo puede conectarse, y no explica nada sobre el alcance de las funciones ni la base de conteo. Tres columnas que no coinciden son mucho más útiles que un párrafo que suena seguro.

El registro está terminado cuando alguien con derecho a ello completa las cuatro columnas. Una columna firmada por el propietario equivocado es un rumor con fecha.

Plataforma y derecho

Registre la puerta de enlace compatible, los sistemas operativos del cliente, la ruta de autenticación y las herramientas de gestión. No mantenga vivo un cliente obsoleto solo porque su perfil antiguo aún se abre, ya que ese perfil es una afirmación de compatibilidad que el proveedor puede que ya no cumpla. Contraste la declaración de soporte actual con la versión que piensa desplegar.

Para el derecho, registre el producto, el tipo de licencia, el plazo y la base de conteo, y luego concílielo a través del propietario de la cuenta. Inferir derechos a partir de un contador histórico de sesiones es como una organización descubre un déficit después del cambio en lugar de antes.

Las guías de pedido de los proveedores ilustran por qué importan estas distinciones. La guía de pedido de Secure Client de Cisco, por ejemplo, separa los niveles Advantage, Premier y VPN Only, cada uno con su propia medida y alcance de funciones. Use el acuerdo actual en lugar de traducir mecánicamente una etiqueta antigua.

Funciones y política aplicada

Enumere las capacidades que el despliegue necesita realmente: modos de túnel permitidos, evaluación de dispositivos, integración de autenticación y cualquier otro módulo. Compruebe el soporte y el derecho de cada una por separado, porque una función puede estar soportada y sin licencia, o con licencia y no soportada en la versión elegida. Solo cuenta una fila que diga sí a ambas preguntas.

Cuando el destino es un ASA, la columna de funciones se lee del propio equipo y no de un contrato, así que capture la puerta de enlace antes del día del cambio. show vpn-sessiondb summary da el inventario de sesiones activas y los recuentos con los que se mide su derecho, show vpn-sessiondb detail anyconnect muestra qué tipo de cliente y qué perfil usó realmente cada sesión atribuida, y show running-config webvpn captura la configuración de la puerta de enlace de la que dependen esas sesiones, y esa es la única parte del registro que ningún documento de licencia puede contener.

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

Después del cambio, ejecute las mismas tres en la nueva puerta de enlace y compárelas con las copias capturadas. Que los recuentos de sesiones se muevan es esperable; un tipo de cliente o una estrofa webvpn que aparece en un lado y no en el otro es el hallazgo, y pertenece al registro con una explicación, no a un comentario de ticket. Guarde las capturas en bruto además de las diferencias, porque el siguiente revisor querrá ver qué se comparó. Con otro proveedor el equivalente es la tabla de sesiones y la exportación de perfiles de esa plataforma, en un formato que no coincidirá, así que compare las preguntas que se le hacen y no el texto.

Luego asigne usuarios y dispositivos a las reglas del destino, los permisos de recursos y el comportamiento de rechazo. Una licencia que habilita una función no es una configuración que la ejerza, y la brecha entre ambas es donde viven la mayoría de las sorpresas de migración.

Escriba los casos de rechazo con el mismo cuidado que los casos permitidos. Un plan que solo demuestra que un administrador puede conectarse ha probado el camino más fácil y ninguna de las fronteras.

Acepte a ambos lados de la decisión

Antes del cambio, ejecute un plan de aceptación aprobado sobre los tipos de cliente previstos, los métodos de autenticación y los recursos. Incluya un dispositivo o una identidad que deba rechazarse, y confirme qué regla lo seleccionó y a qué puede llegar la sesión resultante. Acuerde los casos de denegación antes de que se abra la ventana de cambio, para que nadie pueda descartarlos en silencio bajo presión de tiempo. Un plan sin caso de denegación ha probado el camino feliz y nada más.

Mantenga una ruta de reversión y una ruta de gestión que no dependa de lo que se está migrando. Preserve la configuración y los registros de identidad de forma segura, y deje atrás los ajustes criptográficos obsoletos en lugar de arrastrarlos. Nunca pegue identificadores de licencia ni registros de usuarios en notas públicas.

Haga que el propietario firme el derecho y el mapeo de política juntos. El registro terminado responde dos preguntas a la vez: qué tiene licencia para desplegar la organización y qué reglas admiten y restringen realmente a sus usuarios.