Planifique los ajustes de IKEv2 para más de un cliente

Un perfil que funciona en un escritorio es una prueba exitosa de un solo cliente. No es un despliegue multiplataforma, y tratarlo como tal produce el patrón de soporte habitual: Windows se conecta, el teléfono falla en la comprobación de identidad y el portátil gestionado se reconecta cada vez que se despierta. Las diferencias son reales y en su mayoría previsibles, por eso el plan debe ser una matriz y no una captura de pantalla.

Primero decida el contrato de identidad

Documente la identidad del servidor, la confianza en el certificado y el método de autenticación del cliente antes de hablar de algoritmos. Esos tres elementos deciden si un cliente puede autenticarse, y son las partes que las plataformas expresan de forma distinta.

Compruebe cómo cada plataforma nombra el identificador esperado y cómo trata los nombres alternativos del sujeto. Un perfil que acepta un nombre de servidor en un cliente puede rechazar el mismo certificado en otro porque el campo del identificador se rellena con un valor distinto.

Después elija la intersección criptográfica

Compare las propuestas que puede ofrecer cada cliente compatible y elija una intersección moderna que la puerta de enlace también permita. No active una lista antigua sobredimensionada para que se conecte un solo dispositivo viejo, porque esa lista se convierte en el valor predeterminado de la puerta de enlace para todos los que vengan después. Anote por qué cada opción antigua sigue ahí. Si nadie puede nombrar el dispositivo que la necesita, no es un requisito.

Mantenga separados los ajustes de IKE y CHILD en el plan. Una propuesta aceptable para el intercambio IKE no es automáticamente aceptable para el tráfico protegido, y ambas se negocian por separado. Una puerta de enlace que acepta una propuesta en una capa todavía puede rechazarla en la otra, y el registro mostrará un fallo que parece como si la primera capa hubiera funcionado.

Aprovisione las credenciales mediante un proceso verificado y mantenga la contraseña de usuario, el secreto compartido y la clave privada del cliente en campos propios. El ensayo y error en cajas con nombres parecidos es la forma en que una prueba que funciona se convierte en una no reproducible.

Pruebe el ciclo de vida, no el estado estable

Para cada cliente, pruebe la autenticación inicial, la aplicación prevista, la resolución de DNS y la cobertura de familias de direcciones. Después ejercite las partes que solo aparecen más tarde: renovación, suspensión y un cambio de red normal.

La compatibilidad con MOBIKE y el comportamiento de reautenticación pueden diferir del resultado estable que acaba de medir. Registre el evento y el estado de la asociación en ese momento, no solo si la interfaz acaba pareciendo conectada.

Defina qué puede hacer el tráfico directo mientras la VPN no está disponible. Es una decisión de política separada de si el cliente se reconecta, y la mayoría de los despliegues responden la segunda pregunta mientras ignoran la primera. Escriba la respuesta en las notas de despliegue junto a los nombres de los perfiles. Alguien la necesitará durante una interrupción y no tendrá tiempo de reconstruirla.

Use comprobaciones de identidad del servidor cuando una plataforma no esté de acuerdo

Cuando un perfil funciona en una plataforma y otra rechaza su nombre, compare el identificador que el cliente envió realmente con los identificadores que lleva el certificado. Esa comparación resuelve la mayoría de estos casos más rápido que cambiar las listas de cifrado.

Guarde la matriz probada junto con el origen de la configuración y el procedimiento de actualización. Cuando termine el soporte de un cliente antiguo, retire su excepción de forma deliberada en lugar de dejar ajustes de compatibilidad más débiles ocultos en la puerta de enlace para que los encuentre la próxima auditoría. La documentación de IKEv2 de strongSwan es una referencia útil sobre cómo se configuran los intercambios.