iPhone IKEv2 cap a RouterOS: quin identificador va on
Quatre afirmacions separades decideixen un túnel IKEv2 d'iOS: l'adreça marcada, la identitat de servidor esperada, la identitat de client reclamada i el material del certificat.
Arribar a la passarel·la MikroTik només resol la meitat de transport d'una implantació IKEv2 i res més. Després, quatre afirmacions separades decideixen si el túnel es forma: l'adreça que marca el telèfon, la identitat del servidor que espera, la identitat que reclama per a si mateix i el material del certificat que dona suport a aquesta reclamació. Comproveu-les en aquest ordre i atureu-vos a la primera que no coincideixi amb el que presenta la passarel·la. Cadascuna s'edita en un lloc diferent, i per això una edició equivocada normalment mou la fallada en lloc d'arreglar-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 |
Comproveu els camps del perfil en l'ordre en què els fa servir l'intercanvi
L'adreça remota és la destinació del primer paquet IKE i res més. L'identificador remot és allò que el telèfon espera que la passarel·la demostri que és, i és un nom, no una ruta. Omplir tots dos amb el mateix nom d'amfitrió funciona quan el certificat de la passarel·la porta aquest nom, i falla d'una manera que sembla un problema d'encaminament quan no el porta. Llegiu el perfil com una seqüència d'afirmacions i no com una llista de camps per omplir.
L'identificador local és l'afirmació del propi telèfon, i ha de ser un nom que l'entrada d'identitat de RouterOS accepti per al certificat de client que presenta el telèfon. Si tots dos no coincideixen, la passarel·la rebutja la connexió després que el certificat mateix s'hagi validat, i el registre sembla un problema d'autorització i no d'anomenament.
Comproveu els identificadors contra el que presenta la passarel·la
Una entrada de parell de RouterOS configurada per a autenticació amb certificat presenta el seu propi certificat, i la seva identitat es pren d'aquest certificat tret que hàgiu configurat el contrari. Si l'identificador remot del telèfon anomena el nom DNS de la passarel·la, el certificat de la passarel·la necessita aquest nom en un lloc que el telèfon accepti, normalment un nom alternatiu del subjecte. Un certificat emès per a un nom comú diferent no superarà la validació encara que la clau i la cadena siguin perfectes.
Els perfils d'Apple gestionats també poden portar una restricció de nom de certificat que s'avalua a més dels camps d'identificador. Inspeccioneu la càrrega útil en lloc d'inferir el nom de validació del que mostra la pantalla de configuració, perquè les dues coses no són la mateixa opció.
Comproveu que el certificat de client sigui una clau, no només un ancoratge de confiança
Importar un certificat de CA dona al telèfon una cosa amb què validar la passarel·la. No li dona una identitat de client, i l'autenticació amb certificat necessita el certificat fulla de client i la seva clau privada lliurats junts pel camí d'inscripció aprovat. Un PKCS#12 creat sense la clau privada produeix un perfil que s'instal·la net i no autentica res.
El full de client també necessita una identitat que esperi el costat RouterOS, cosa que vol dir que el subjecte o el nom alternatiu del subjecte ha de coincidir amb la configuració d'identitat corresponent. Emetre certificats de client i de servidor des d'una sola CA fa còmode la cadena i no fa intercanviables les dues fulles.
Comproveu que la política de RouterOS accepti aquest nom
A la passarel·la, l'entrada de parell fixa el mode d'intercanvi i el mètode d'autenticació, i l'entrada d'identitat lliga la identitat remota acceptada a un certificat i a la política que segueix. A RouterOS v7 aquesta parella s'expressa amb les entrades de parell i d'identitat d'IPsec, per exemple un parell IKEv2 amb auth-method=digital-signature. Comproveu el contingut real del menú de la versió instal·lada i no una guia escrita per a una versió més antiga.
Aquí també és on una discrepància és més barata d'arreglar, perquè la passarel·la us pot dir tant la identitat que ha rebut com la que volia. Ampliar la identitat acceptada per silenciar l'error elimina el lligam que donava sentit a la implantació.
Comproveu quina etapa ha fallat abans d'editar res
Llegiu l'intent als dos extrems i classifiqueu-lo abans de canviar una proposta. Una discrepància de proposta, una clau de signatura absent, un emissor no fiable, un identificador de parell equivocat i una autorització de client rebutjada semblen tots un túnel mort des del telèfon, i cadascun té un propietari diferent. Canviar les cinc opcions alhora garanteix que no aprendreu res del resultat.
Anoteu la identitat presentada, la identitat esperada, l'emissor i el número de sèrie del certificat i el nom de la política pertinent, mantenint les claus privades i els secrets del perfil fora d'aquest registre. Quan l'autenticació tingui èxit, proveu un servei privat i la seva resposta, perquè l'assignació d'adreces, els selectors, el DNS i la política d'accés encara han de funcionar després que acabi l'intercanvi IKE.