iPhone IKEv2 hacia RouterOS: qué identificador va dónde
Cuatro afirmaciones separadas deciden un túnel IKEv2 de iOS: la dirección marcada, la identidad de servidor esperada, la identidad de cliente reclamada y el material del certificado.
Llegar a la puerta de enlace MikroTik solo resuelve la mitad de transporte de una implementación IKEv2 y nada más. Después, cuatro afirmaciones separadas deciden si se forma el túnel: la dirección que marca el teléfono, la identidad de servidor que espera, la identidad que reclama para sí mismo y el material de certificado que respalda esa afirmación. Compruébelas en ese orden y deténgase en la primera que no coincida con lo que presenta la puerta de enlace. Cada una se edita en un lugar distinto, por eso una edición equivocada suele mover el fallo en lugar de arreglarlo.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
Compruebe los campos del perfil en el orden en que los usa el intercambio
La dirección remota es el destino del primer paquete IKE y nada más. El identificador remoto es lo que el teléfono espera que la puerta de enlace demuestre ser, y es un nombre, no una ruta. Rellenar ambos con el mismo nombre de host funciona cuando el certificado de la puerta de enlace lleva ese nombre, y falla de una manera que parece un problema de enrutamiento cuando no lo lleva. Lea el perfil como una secuencia de afirmaciones y no como una lista de campos que rellenar.
El identificador local es la afirmación del propio teléfono, y debe ser un nombre que la entrada de identidad de RouterOS acepte para el certificado de cliente que presenta el teléfono. Si los dos no coinciden, la puerta de enlace rechaza la conexión después de que el propio certificado se haya validado, y el registro parece un problema de autorización y no de nombres.
Compruebe los identificadores contra lo que presenta la puerta de enlace
Una entrada de par de RouterOS configurada para autenticación con certificado presenta su propio certificado, y su identidad se toma de ese certificado salvo que haya configurado lo contrario. Si el identificador remoto del teléfono nombra el nombre DNS de la puerta de enlace, el certificado de la puerta de enlace necesita ese nombre en un lugar que el teléfono acepte, normalmente un nombre alternativo del sujeto. Un certificado emitido para otro nombre común no validará aunque la clave y la cadena sean perfectas.
Los perfiles de Apple gestionados también pueden llevar una restricción de nombre de certificado que se evalúa además de los campos de identificador. Inspeccione la carga útil en lugar de inferir el nombre de validación de lo que muestra la pantalla de ajustes, porque las dos cosas no son el mismo ajuste.
Compruebe que el certificado de cliente es una clave y no solo un ancla de confianza
Importar un certificado de CA da al teléfono algo con lo que validar la puerta de enlace. No le da una identidad de cliente, y la autenticación con certificado necesita el certificado hoja de cliente y su clave privada entregados juntos por la ruta de inscripción aprobada. Un PKCS#12 creado sin la clave privada produce un perfil que se instala limpiamente y no autentica nada.
La hoja de cliente también necesita una identidad que espere el lado RouterOS, lo que significa que el sujeto o el nombre alternativo del sujeto debe coincidir con la configuración de identidad correspondiente. Emitir certificados de cliente y servidor desde una sola CA hace cómoda la cadena y no hace intercambiables las dos hojas.
Compruebe que la política de RouterOS acepta ese nombre
En la puerta de enlace, la entrada de par fija el modo de intercambio y el método de autenticación, y la entrada de identidad vincula la identidad remota aceptada a un certificado y a la política que sigue. En RouterOS v7 ese emparejamiento se expresa mediante las entradas de par e identidad de IPsec, por ejemplo un par IKEv2 con auth-method=digital-signature. Compruebe el contenido real del menú de la versión instalada y no una guía escrita para una anterior.
Aquí también es donde una discrepancia resulta más barata de corregir, porque la puerta de enlace puede decirle tanto la identidad que recibió como la que quería. Ampliar la identidad aceptada para silenciar el error elimina el vínculo que daba sentido a la implementación.
Compruebe qué etapa falló antes de editar nada
Lea el intento en ambos extremos y clasifíquelo antes de cambiar una propuesta. Una discrepancia de propuesta, una clave de firma ausente, un emisor no confiable, un identificador de par equivocado y una autorización de cliente rechazada parecen todas un túnel muerto desde el teléfono, y cada una tiene un responsable distinto. Cambiar los cinco ajustes a la vez garantiza que no aprenderá nada del resultado.
Anote la identidad presentada, la identidad esperada, el emisor y el número de serie del certificado y el nombre de la política pertinente, manteniendo las claves privadas y los secretos del perfil fuera de ese registro. Cuando la autenticación tenga éxito, pruebe un servicio privado y su respuesta, porque la asignación de direcciones, los selectores, el DNS y la política de acceso todavía tienen que funcionar después de que termine el intercambio IKE.