Migrar unha VPN: licenzas, funcións e política nun único rexistro

As sesións que aínda funcionan no concentrador antigo parecen proba de que a migración está case rematada. Son un só elemento do inventario, e o menos interesante. O que o cambio necesita é un rexistro que ate a pasarela de destino, o cliente compatible, o dereito adquirido e a política de admisión aplicada nun único artefacto que alguén posúa. Sen el, a migración é unha serie de suposicións que, por separado, parecen razoables.

Catro columnas, non unha lista de verificación

Que pode soportar o hardware, que permite o contrato e que admite o conxunto de regras son tres preguntas separadas, e mesturalas produce un plan que ninguén pode auditar. Manténs en columnas separadas e fai que cada unha cite a súa fonte. Un dispositivo que acepta unha conexión demostra que un dispositivo pode conectarse, e non explica nada sobre o alcance das funcións nin a base de reconto. Tres columnas que non coinciden son moito máis útiles que un parágrafo que soa seguro.

O rexistro remátase cando alguén con dereito a iso completa as catro columnas. Unha columna asinada polo propietario equivocado é un rumor con data.

Plataforma e dereito

Rexistra a pasarela compatible, os sistemas operativos do cliente, a ruta de autenticación e as ferramentas de xestión. Non manteñas vivo un cliente obsoleto só porque o seu perfil antigo aínda se abre, xa que ese perfil é unha afirmación de compatibilidade que o provedor pode que xa non cumpra. Contrasta a declaración de soporte actual coa versión que pensas despregar.

Para o dereito, rexistra o produto, o tipo de licenza, o prazo e a base de reconto, e logo concílialo a través do propietario da conta. Inferir dereitos a partir dun contador histórico de sesións é como unha organización descobre un déficit despois do cambio en lugar de antes.

As guías de pedido dos provedores ilustran por que importan estas distincións. A guía de pedido de Secure Client de Cisco, por exemplo, separa os niveis Advantage, Premier e VPN Only, cada un coa súa propia medida e alcance de funcións. Usa o acordo actual en lugar de traducir mecanicamente unha etiqueta antiga.

Funcións e política aplicada

Enumera as capacidades que o despregamento necesita realmente: modos de túnel permitidos, avaliación de dispositivos, integración de autenticación e calquera outro módulo. Comproba o soporte e o dereito de cada unha por separado, porque unha función pode estar soportada e sen licenza, ou con licenza e non soportada na versión escollida. Só conta unha fila que diga si a ambas as preguntas.

Cando o destino é un ASA, a columna de funcións lese do propio equipo e non dun contrato, así que captura a pasarela antes do día do cambio. show vpn-sessiondb summary dá o inventario de sesións activas e os recontos cos que se mide o teu dereito, show vpn-sessiondb detail anyconnect mostra que tipo de cliente e que perfil usou realmente cada sesión atribuída, e show running-config webvpn captura a configuración da pasarela da que dependen esas sesións, e esa é a única parte do rexistro que ningún documento de licenza pode conter.

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

Despois do cambio, executa as mesmas tres na nova pasarela e compáraas coas copias capturadas. Que os recontos de sesións se movan é esperable; un tipo de cliente ou unha estrofa webvpn que aparece nun lado e non no outro é o achado, e pertence ao rexistro cunha explicación, non a un comentario de ticket. Garda as capturas en bruto ademais das diferenzas, porque o seguinte revisor querrá ver que se comparou. Con outro provedor o equivalente é a táboa de sesións e a exportación de perfís desa plataforma, nun formato que non coincidirá, así que compara as preguntas que se lle fan e non o texto.

Logo asigna usuarios e dispositivos ás regras do destino, os permisos de recursos e o comportamento de rexeitamento. Unha licenza que habilita unha función non é unha configuración que a exerza, e a fenda entre ambas é onde viven a maioría das sorpresas de migración.

Escribe os casos de rexeitamento co mesmo coidado que os casos permitidos. Un plan que só demostra que un administrador pode conectarse probou o camiño máis doado e ningunha das fronteiras.

Acepta a ambos os lados da decisión

Antes do cambio, executa un plan de aceptación aprobado sobre os tipos de cliente previstos, os métodos de autenticación e os recursos. Inclúe un dispositivo ou unha identidade que deba ser rexeitada, e confirma que regra a seleccionou e a que pode chegar a sesión resultante. Acorda os casos de denegación antes de que se abra a xanela de cambio, para que ninguén poida descartalos en silencio baixo presión de tempo. Un plan sen caso de denegación probou o camiño feliz e nada máis.

Mantén unha ruta de reversión e unha ruta de xestión que non dependa do que se está a migrar. Preserva a configuración e os rexistros de identidade de forma segura, e deixa atrás os axustes criptográficos obsoletos en lugar de arrastralos. Nunca pegues identificadores de licenza nin rexistros de usuarios en notas públicas.

Fai que o propietario asine o dereito e a correspondencia de política xuntos. O rexistro rematado responde dúas preguntas á vez: que ten licenza para despregar a organización e que regras admiten e restrinxen realmente aos seus usuarios.