Migrar uma VPN: licenças, funcionalidades e política num único registo

As sessões que ainda funcionam no concentrador antigo parecem prova de que a migração está quase concluída. São um único item do inventário, e o menos interessante. O que a mudança exige é um registo que ligue o gateway de destino, o cliente suportado, o direito adquirido e a política de admissão aplicada num único artefacto que alguém possui. Sem ele, a migração é uma série de pressupostos que, isoladamente, parecem razoáveis.

Quatro Colunas, Não Uma Lista de Verificação

O que o hardware consegue suportar, o que o contrato permite e o que o conjunto de regras admite são três perguntas separadas, e misturá-las produz um plano que ninguém consegue auditar. Mantenha-as em colunas separadas e faça com que cada uma cite a sua fonte. Um dispositivo que aceita uma ligação prova que um dispositivo consegue ligar-se, e não explica nada sobre o âmbito das funcionalidades nem sobre a base de contagem. Três colunas que discordam são muito mais úteis do que um parágrafo que soa seguro.

O registo fica concluído quando as quatro colunas são preenchidas por alguém com direito a preenchê-las. Uma coluna assinada pelo proprietário errado é um rumor com data.

Plataforma e Direito

Registe o gateway suportado, os sistemas operativos do cliente, o caminho de autenticação e as ferramentas de gestão. Não mantenha um cliente obsoleto vivo só porque o perfil antigo ainda abre, pois esse perfil é uma afirmação de compatibilidade que o fornecedor pode já não cumprir. Compare a declaração de suporte atual com a versão que pretende implementar.

Para o direito, registe o produto, o tipo de licença, o prazo e a base de contagem, e depois reconcilie-o através do proprietário da conta. Inferir direitos a partir de um contador histórico de sessões é como uma organização descobre uma falta depois da mudança e não antes.

Os guias de encomenda dos fornecedores mostram porque estas distinções importam. O guia de encomenda do Secure Client da Cisco, por exemplo, separa os níveis Advantage, Premier e VPN Only, cada um com a sua medida e âmbito de funcionalidades. Use o acordo atual em vez de traduzir mecanicamente um rótulo antigo.

Funcionalidades e Política Aplicada

Enumere as capacidades de que a implementação realmente precisa: modos de túnel permitidos, avaliação de dispositivos, integração de autenticação e qualquer outro módulo. Verifique o suporte e o direito de cada uma separadamente, porque uma funcionalidade pode estar suportada e sem licença, ou licenciada e não suportada na versão escolhida. Só conta uma linha que responda sim às duas perguntas.

Quando o destino é um ASA, a coluna das funcionalidades lê-se do equipamento e não de um contrato, por isso capture o gateway antes do dia da mudança. show vpn-sessiondb summary dá o inventário de sessões ativas e as contagens com que o seu direito é medido, show vpn-sessiondb detail anyconnect mostra que tipo de cliente e perfil cada sessão atribuída realmente usou, e show running-config webvpn captura a configuração do gateway de que essas sessões dependem, e essa é a única parte do registo que nenhum documento de licença pode conter.

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

Depois da mudança, execute os mesmos três no novo gateway e compare-os com as cópias capturadas. Que as contagens de sessões mudem é esperado; um tipo de cliente ou um bloco webvpn que aparece de um lado e não do outro é o achado, e pertence ao registo com uma explicação, não a um comentário de ticket. Guarde as capturas em bruto além das diferenças, porque o próximo revisor vai querer ver o que foi comparado. Noutro fornecedor o equivalente é a tabela de sessões e a exportação de perfis dessa plataforma, num formato que não vai coincidir, por isso compare as perguntas que lhe são feitas e não o texto.

Depois mapeie utilizadores e dispositivos às regras do destino, às permissões de recursos e ao comportamento de rejeição. Uma licença que habilita uma funcionalidade não é uma configuração que a exerce, e a lacuna entre as duas é onde vive a maioria das surpresas da migração.

Escreva os casos de rejeição com o mesmo cuidado que os casos permitidos. Um plano que só prova que um administrador consegue ligar-se testou o caminho mais fácil e nenhuma das fronteiras.

Aceite dos Dois Lados da Decisão

Antes da mudança, execute um plano de aceitação aprovado sobre os tipos de cliente previstos, os métodos de autenticação e os recursos. Inclua um dispositivo ou identidade que tem de ser rejeitado, e confirme que regra o selecionou e a que pode chegar a sessão resultante. Acorde os casos de negação antes de abrir a janela de mudança, para que ninguém os possa descartar em silêncio sob pressão de tempo. Um plano sem caso de negação testou o caminho feliz e nada mais.

Mantenha um caminho de reversão e uma via de gestão que não dependam do que está a ser migrado. Preserve a configuração e os registos de identidade em segurança, e deixe para trás as definições criptográficas obsoletas em vez de as transportar. Nunca cole identificadores de licença ou registos de utilizadores em notas públicas.

Peça ao proprietário que assine o direito e o mapeamento de política em conjunto. O registo concluído responde a duas perguntas ao mesmo tempo: o que a organização tem licença para implementar, e que regras admitem e restringem realmente os seus utilizadores.