iPhone IKEv2 cara a RouterOS: que identificador vai onde
Catro afirmacións separadas deciden un túnel IKEv2 de iOS: o enderezo marcado, a identidade de servidor esperada, a identidade de cliente reclamada e o material do certificado.
Chegar á pasarela MikroTik só resolve a metade de transporte dunha implantación IKEv2 e nada máis. Despois, catro afirmacións separadas deciden se se forma o túnel: o enderezo que marca o teléfono, a identidade de servidor que espera, a identidade que reclama para si mesmo e o material do certificado que apoia esa afirmación. Compóbeas nesa orde e detéñase na primeira que non coincida co que presenta a pasarela. Cada unha edítase nun lugar distinto, e por iso unha edición errónea adoita mover o fallo en lugar de arranxalo.
| 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 |
Comprobe os campos do perfil na orde en que os usa o intercambio
O enderezo remoto é o destino do primeiro paquete IKE e nada máis. O identificador remoto é o que o teléfono espera que a pasarela demostre ser, e é un nome, non unha ruta. Encher ambos co mesmo nome de host funciona cando o certificado da pasarela leva ese nome, e falla dun xeito que parece un problema de encamiñamento cando non o leva. Lea o perfil como unha secuencia de afirmacións e non como unha lista de campos que encher.
O identificador local é a afirmación do propio teléfono, e debe ser un nome que a entrada de identidade de RouterOS acepte para o certificado de cliente que presenta o teléfono. Se os dous non coinciden, a pasarela rexeita a conexión despois de que o propio certificado se validase, e o rexistro parece un problema de autorización e non de nomeado.
Comprobe os identificadores contra o que presenta a pasarela
Unha entrada de par de RouterOS configurada para autenticación con certificado presenta o seu propio certificado, e a súa identidade tómase dese certificado salvo que configurase o contrario. Se o identificador remoto do teléfono nomea o nome DNS da pasarela, o certificado da pasarela necesita ese nome nun lugar que o teléfono acepte, normalmente un nome alternativo do suxeito. Un certificado emitido para outro nome común non validará aínda que a clave e a cadea sexan perfectas.
Os perfís de Apple xestionados tamén poden levar unha restrición de nome de certificado que se avalía ademais dos campos de identificador. Inspeccione a carga útil en lugar de inferir o nome de validación do que mostra a pantalla de axustes, porque as dúas cousas non son o mesmo axuste.
Comprobe que o certificado de cliente é unha clave e non só unha áncora de confianza
Importar un certificado de CA dálle ao teléfono algo co que validar a pasarela. Non lle dá unha identidade de cliente, e a autenticación con certificado necesita o certificado folla de cliente e a súa clave privada entregados xuntos pola ruta de inscrición aprobada. Un PKCS#12 creado sen a clave privada produce un perfil que se instala limpiamente e non autentica nada.
A folla de cliente tamén necesita unha identidade que espere o lado RouterOS, o que significa que o suxeito ou o nome alternativo do suxeito debe coincidir coa configuración de identidade correspondente. Emitir certificados de cliente e servidor desde unha soa CA fai cómoda a cadea e non fai intercambiables as dúas follas.
Comprobe que a política de RouterOS acepta ese nome
Na pasarela, a entrada de par fixa o modo de intercambio e o método de autenticación, e a entrada de identidade liga a identidade remota aceptada a un certificado e á política que segue. En RouterOS v7 ese emparellamento exprésase mediante as entradas de par e identidade de IPsec, por exemplo un par IKEv2 con auth-method=digital-signature. Comprobe o contido real do menú da versión instalada e non unha guía escrita para unha anterior.
Aquí tamén é onde unha discrepancia resulta máis barata de corrixir, porque a pasarela pode dicirlle tanto a identidade que recibiu como a que quería. Ampliar a identidade aceptada para silenciar o erro elimina o vínculo que daba sentido á implantación.
Comprobe que etapa fallou antes de editar nada
Lea o intento nos dous extremos e clasifíqueo antes de cambiar unha proposta. Unha discrepancia de proposta, unha clave de sinatura ausente, un emisor non fiable, un identificador de par erróneo e unha autorización de cliente rexeitada parecen todas un túnel morto desde o teléfono, e cada unha ten un responsable distinto. Cambiar os cinco axustes á vez garante que non aprenderá nada do resultado.
Anote a identidade presentada, a identidade esperada, o emisor e o número de serie do certificado e o nome da política pertinente, mantendo as claves privadas e os segredos do perfil fóra dese rexistro. Cando a autenticación teña éxito, probe un servizo privado e a súa resposta, porque a asignación de enderezos, os selectores, o DNS e a política de acceso aínda teñen que funcionar despois de que remate o intercambio IKE.