¿Admite su Meraki MX Cisco Secure Client?

Dos hilos de soporte no coinciden sobre si Meraki puede hacer AnyConnect, y ambos se equivocan con la misma seguridad. La pregunta no es si un MX habla IKEv2, porque AnyConnect en el equipo es un servicio TLS y no uno de IPsec. Dos comprobaciones separadas deciden la respuesta, y ninguna es una comparación de marcas. Hágaslas en orden y obtendrá un registro de compatibilidad en lugar de una opinión.

Primero el modelo y la versión

Empiece por el equipo exacto y el software que ejecuta, porque la función está limitada a ambos. Meraki publica una matriz con los modelos admitidos y el firmware mínimo, y esa matriz es la única autoridad que merece citarse. Un modelo que aparece en la lista no está automáticamente en una versión que admita la función, y una versión que la admite puede no ser la que usted ejecuta. Registre el modelo y el firmware instalado como dos hechos separados. Después lea la matriz para ese par.

No razone a partir de un modelo similar de la misma familia. La lista es por modelo, y las diferencias son reales.

AnyConnect es un servicio SSL, no IPsec

Meraki describe AnyConnect en el MX como una VPN basada en aplicaciones sobre TLS y DTLS, y la documenta junto a un servicio de VPN de cliente L2TP/IPsec separado. Son dos productos que comparten un panel por casualidad. Comparar IKEv1 con IKEv2 le habla del servicio IPsec y nada de si el servicio TLS existe en su equipo. Si su evidencia es una tabla de versiones de IKE, ha estado respondiendo otra pregunta.

Identifique qué servicio expone el equipo antes de comparar clientes. Un perfil L2TP/IPsec que funciona no se convierte en un perfil AnyConnect porque llegue a la misma organización, y los dos necesitan una configuración de cliente distinta.

Qué funciones ofrece realmente el MX

La lista de funciones del ASA de Cisco no es la lista de funciones del MX, y un cliente que admite doce cosas no hace que la pasarela las admita. Compare las funciones que realmente necesita: método de autenticación, comportamiento del túnel dividido, gestión de DNS y el derecho que exija el equipo. Tome cada una de la documentación de Meraki para la versión desplegada.

La autenticación es donde esto suele doler. Un método que el cliente ofrece y el equipo no puede configurar es un caso de soporte esperando a ocurrir.

Versión del cliente y derecho

Cisco Secure Client es el nombre actual de la misma familia de clientes, así que un documento que mencione AnyConnect no es necesariamente obsoleto. Lo que importa es la versión que despliega su organización y si la versión del equipo está validada contra ella.

Compruebe el requisito de licencia en la misma guía en lugar de suponerlo desde otra plataforma. Después mantenga el nombre del punto final, la verificación del certificado y el flujo de autenticación aprobado juntos en un registro de servicio, porque esos tres fallan de forma independiente. Un aviso de certificado por el que los usuarios hacen clic no es un resultado de compatibilidad, es una configuración no verificada. El acceso remoto es solo la mitad del trabajo, porque el usuario todavía necesita rutas y permisos para llegar al destino.

Escriba el registro con cinco campos

Modelo, firmware, modo de acceso remoto, versión del cliente y las funciones que requiere el despliegue. Cinco campos, y la respuesta a si podemos usar AnyConnect vive en la combinación y no en cualquiera de ellos por separado. Ese registro también dice al siguiente ingeniero qué volver a comprobar tras una actualización de firmware.

Después pruebe la ruta de extremo a extremo: autentíquese, resuelva un nombre interno, llegue a un recurso permitido y confirme que se rechaza un recurso al que no debería llegar. Un inicio de sesión que tiene éxito con un recurso que nunca carga es un resultado parcial, y la mitad que falta suele ser enrutamiento o autorización, no el cliente. Archive la combinación probada con el cambio, para que la siguiente persona herede evidencia en lugar de un eslogan.