iPhone IKEv2 para RouterOS: que identificador vai onde
Quatro afirmações separadas decidem um túnel IKEv2 em iOS: o endereço marcado, a identidade de servidor esperada, a identidade de cliente reclamada e o material do certificado.
Chegar ao gateway MikroTik resolve apenas a metade de transporte de uma implantação IKEv2 e mais nada. Depois, quatro afirmações separadas decidem se o túnel se forma: o endereço que o telefone marca, a identidade de servidor que espera, a identidade que reclama para si e o material de certificado que sustenta essa reivindicação. Verifique-as nessa ordem e pare na primeira que não coincidir com o que o gateway apresenta. Cada uma edita-se num lugar diferente, por isso uma edição errada costuma mover a falha em vez de corrigi-la.
| 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 |
Verifique os campos do perfil na ordem em que a troca os usa
O endereço remoto é o destino do primeiro pacote IKE e nada mais. O identificador remoto é aquilo que o telefone espera que o gateway prove ser, e é um nome, não uma rota. Preencher ambos com o mesmo nome de host funciona quando o certificado do gateway contém esse nome, e falha de uma forma que parece um problema de encaminhamento quando não contém. Leia o perfil como uma sequência de afirmações, não como uma lista de campos a preencher.
O identificador local é a reivindicação do próprio telefone, e tem de ser um nome que a entrada de identidade do RouterOS aceite para o certificado de cliente que o telefone apresenta. Se os dois não coincidirem, o gateway rejeita a ligação depois de o certificado em si ter sido validado, e o registo parece um problema de autorização e não de nomenclatura.
Verifique os identificadores contra o que o gateway apresenta
Uma entrada de par do RouterOS configurada para autenticação por certificado apresenta o seu próprio certificado, e a sua identidade é retirada desse certificado, salvo se tiver configurado de outra forma. Se o identificador remoto do telefone indicar o nome DNS do gateway, o certificado do gateway precisa desse nome num local que o telefone aceite, normalmente um nome alternativo do sujeito. Um certificado emitido para outro nome comum não validará, mesmo que a chave e a cadeia estejam perfeitas.
Os perfis Apple geridos também podem conter uma restrição de nome de certificado avaliada além dos campos de identificador. Inspecione a carga útil em vez de inferir o nome de validação a partir do que o ecrã de definições mostra, porque não são a mesma definição.
Verifique se o certificado de cliente é uma chave, e não apenas uma âncora de confiança
Importar um certificado de CA dá ao telefone algo com que validar o gateway. Não lhe dá uma identidade de cliente, e a autenticação por certificado exige o certificado-folha de cliente e a respetiva chave privada entregues juntos pelo caminho de inscrição aprovado. Um PKCS#12 criado sem a chave privada produz um perfil que se instala sem erros e não autentica nada.
A folha de cliente também precisa de uma identidade que o lado RouterOS espera, o que significa que o sujeito ou o nome alternativo do sujeito tem de coincidir com a configuração de identidade correspondente. Emitir certificados de cliente e de servidor a partir de uma única CA torna a cadeia cómoda e não torna as duas folhas intercambiáveis.
Verifique se a política do RouterOS aceita esse nome
No gateway, a entrada de par define o modo de troca e o método de autenticação, e a entrada de identidade liga a identidade remota aceite a um certificado e à política que se segue. No RouterOS v7 esse par exprime-se pelas entradas de par e de identidade do IPsec, por exemplo um par IKEv2 com auth-method=digital-signature. Verifique o conteúdo real do menu da versão instalada e não um guia escrito para uma anterior.
É também aqui que uma discrepância é mais barata de corrigir, porque o gateway lhe pode dizer tanto a identidade que recebeu como a que pretendia. Alargar a identidade aceite para silenciar o erro remove a ligação que dava sentido à implantação.
Verifique que etapa falhou antes de editar seja o que for
Leia a tentativa nos dois extremos e classifique-a antes de alterar uma proposta. Uma discrepância de proposta, uma chave de assinatura em falta, um emissor não fidedigno, um identificador de par errado e uma autorização de cliente rejeitada parecem todas um túnel morto visto do telefone, e cada uma tem um responsável diferente. Alterar as cinco definições de uma vez garante que não aprende nada com o resultado.
Registe a identidade apresentada, a identidade esperada, o emissor e o número de série do certificado e o nome da política relevante, mantendo as chaves privadas e os segredos do perfil fora desse registo. Quando a autenticação tiver êxito, teste um serviço privado e a sua resposta, porque a atribuição de endereços, os seletores, o DNS e a política de acesso ainda têm de funcionar depois de a troca IKE terminar.