O seu Meraki MX admite Cisco Secure Client?
Decídeno dúas comprobacións distintas: o modelo MX coa súa versión de firmware e que servizo de acceso remoto expón realmente o equipo.
Dous fíos de soporte non coinciden sobre se Meraki pode facer AnyConnect, e ambos se equivocan coa mesma seguridade. A pregunta non é se un MX fala IKEv2, porque AnyConnect no equipo é un servizo TLS e non un de IPsec. Dúas comprobacións separadas deciden a resposta, e ningunha é unha comparación de marcas. Fágaas en orde e obterá un rexistro de compatibilidade en lugar dunha opinión.
Primeiro o modelo e a versión
Comece polo equipo exacto e o software que executa, porque a función está limitada a ambos. Meraki publica unha matriz cos modelos admitidos e o firmware mínimo, e esa matriz é a única autoridade que merece citarse. Un modelo que aparece na lista non está automaticamente nunha versión que admita a función, e unha versión que a admite pode non ser a que vostede executa. Rexistre o modelo e o firmware instalado como dous feitos separados. Despois lea a matriz para ese par.
Non razoemos a partir dun modelo similar da mesma familia. A lista é por modelo, e as diferenzas son reais.
AnyConnect é un servizo SSL, non IPsec
Meraki describe AnyConnect no MX como unha VPN baseada en aplicacións sobre TLS e DTLS, e documéntaa xunto a un servizo de VPN de cliente L2TP/IPsec separado. Son dous produtos que comparten un panel por casualidade. Comparar IKEv1 con IKEv2 fálalle do servizo IPsec e nada de se o servizo TLS existe no seu equipo. Se a súa evidencia é unha táboa de versións IKE, estivo respondendo outra pregunta.
Identifique que servizo expón o equipo antes de comparar clientes. Un perfil L2TP/IPsec que funciona non se converte nun perfil AnyConnect porque chegue á mesma organización, e os dous necesitan unha configuración de cliente distinta.
Que funcións ofrece realmente o MX
A lista de funcións do ASA de Cisco non é a lista de funcións do MX, e un cliente que admite doce cousas non fai que a pasarela as admita. Compare as funcións que realmente necesita: método de autenticación, comportamento do túnel dividido, xestión de DNS e o dereito que exixa o equipo. Tome cada unha da documentación de Meraki para a versión despregada.
A autenticación é onde isto adoita doer. Un método que o cliente ofrece e o equipo non pode configurar é un caso de soporte esperando a ocorrer.
Versión do cliente e dereito
Cisco Secure Client é o nome actual da mesma familia de clientes, así que un documento que mencione AnyConnect non é necesariamente obsoleto. O que importa é a versión que despregue a súa organización e se a versión do equipo está validada contra ela.
Comprobe o requisito de licenza na mesma guía en lugar de supoñelo desde outra plataforma. Despois manteña o nome do punto final, a verificación do certificado e o fluxo de autenticación aprobado xuntos nun rexistro de servizo, porque eses tres fallan de forma independente. Un aviso de certificado polo que os usuarios fan clic non é un resultado de compatibilidade, é unha configuración non verificada. O acceso remoto só é a metade do traballo, porque o usuario aínda necesita rutas e permisos para chegar ao destino.
Escriba o rexistro con cinco campos
Modelo, firmware, modo de acceso remoto, versión do cliente e as funcións que require o despregamento. Cinco campos, e a resposta a podemos usar AnyConnect vive na combinación e non en calquera deles por separado. Ese rexistro tamén lle di ao seguinte enxeñeiro que hai que volver comprobar tras unha actualización de firmware.
Despois probe a ruta de extremo a extremo: autentíquese, resolva un nome interno, chegue a un recurso permitido e confirme que se rexeita un recurso ao que non debería chegar. Un inicio de sesión que ten éxito cun recurso que nunca carga é un resultado parcial, e a metade que falta adoita ser encamiñamento ou autorización, non o cliente. Arquive a combinación probada co cambio, para que a seguinte persoa herde evidencia en lugar dun eslogan.