O seu Meraki MX suporta o Cisco Secure Client?

Duas cadeias de apoio não concordam sobre se a Meraki consegue fazer AnyConnect, e ambas estão confiantemente erradas da mesma forma. A questão não é se um MX fala IKEv2, porque o AnyConnect no equipamento é um serviço TLS e não um de IPsec. Duas verificações separadas decidem a resposta, e nenhuma delas é uma comparação de marcas. Faça-as por ordem e obtém um registo de compatibilidade em vez de uma opinião.

Primeiro o modelo e a versão

Comece pelo equipamento exato e pelo software que ele executa, porque a funcionalidade está limitada a ambos. A Meraki publica uma matriz com os modelos suportados e o firmware mínimo, e essa matriz é a única autoridade que vale a pena citar. Um modelo que aparece na lista não está automaticamente numa versão que suporte a funcionalidade, e uma versão que a suporta pode não ser a que está a executar. Registe o modelo e o firmware instalado como dois factos separados. Depois leia a matriz para esse par.

Não raciocine a partir de um modelo semelhante da mesma família. A lista é por modelo, e as diferenças são reais.

O AnyConnect é um serviço SSL, não IPsec

A Meraki descreve o AnyConnect no MX como uma VPN baseada em aplicações sobre TLS e DTLS, e documenta-o ao lado de um serviço de VPN de cliente L2TP/IPsec separado. São dois produtos que partilham um painel por acaso. Comparar IKEv1 com IKEv2 diz-lhe sobre o serviço IPsec e nada sobre se o serviço TLS existe no seu equipamento. Se a sua evidência é uma tabela de versões IKE, esteve a responder a outra pergunta.

Identifique que serviço o equipamento expõe antes de comparar clientes. Um perfil L2TP/IPsec que funciona não se transforma num perfil AnyConnect por chegar à mesma organização, e os dois exigem configuração de cliente diferente.

Que funções o MX oferece realmente

A lista de funções do ASA da Cisco não é a lista de funções do MX, e um cliente que suporta doze coisas não faz com que a passagem as suporte. Compare as funções de que realmente precisa: método de autenticação, comportamento do túnel dividido, tratamento de DNS e o direito que o equipamento exige. Tire cada uma da documentação da Meraki para a versão implementada.

A autenticação é onde isto costuma morder. Um método que o cliente oferece e o equipamento não consegue configurar é um caso de apoio que espera para acontecer.

Versão do cliente e direito

O Cisco Secure Client é o nome atual da mesma família de clientes, pelo que um documento que mencione o AnyConnect não é necessariamente antigo. O que importa é a versão que a sua organização implementa e se a versão do equipamento está validada contra ela.

Verifique o requisito de licença no mesmo guia em vez de o presumir a partir de outra plataforma. Depois mantenha o nome do ponto final, a verificação do certificado e o fluxo de autenticação aprovado juntos num único registo de serviço, porque estes três falham de forma independente. Um aviso de certificado por onde os utilizadores passam com um clique não é um resultado de compatibilidade, é uma configuração não verificada. O acesso remoto é apenas metade do trabalho, porque o utilizador continua a precisar de rotas e permissões para chegar ao destino.

Escreva o registo com cinco campos

Modelo, firmware, modo de acesso remoto, versão do cliente e as funções que a implementação exige. Cinco campos, e a resposta a podemos usar o AnyConnect está na combinação e não em qualquer um deles isoladamente. Esse registo também diz ao próximo engenheiro o que reverificar após uma atualização de firmware.

Depois teste o caminho de ponta a ponta: autentique-se, resolva um nome interno, alcance um recurso permitido e confirme que um recurso a que não devia chegar é recusado. Um início de sessão que tem sucesso com um recurso que nunca carrega é um resultado parcial, e a metade em falta é normalmente encaminhamento ou autorização, não o cliente. Arquive a combinação testada com a alteração, para que a pessoa seguinte herde evidência em vez de um slogan.