iPhone IKEv2 către RouterOS: ce identificator merge unde
Patru afirmații separate decid un tunel IKEv2 pe iOS: adresa apelată, identitatea de server așteptată, identitatea de client revendicată și materialul certificatului.
Atingerea gateway-ului MikroTik rezolvă doar jumătatea de transport a unei implementări IKEv2 și nimic altceva. Apoi patru afirmații separate decid dacă tunelul se formează: adresa pe care o apelează telefonul, identitatea de server pe care o așteaptă, identitatea pe care o revendică pentru sine și materialul de certificat care susține acea afirmație. Verificați-le în această ordine și opriți-vă la prima care nu corespunde cu ceea ce prezintă gateway-ul. Fiecare se editează într-un loc diferit, de aceea o editare greșită mută de obicei defectul în loc să-l repare.
| 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 |
Verificați câmpurile profilului în ordinea în care schimbul le folosește
Adresa la distanță este destinația primului pachet IKE și nimic mai mult. Identificatorul la distanță este ceea ce telefonul așteaptă ca gateway-ul să dovedească că este, și este un nume, nu o rută. Completarea ambelor cu același nume de gazdă funcționează când certificatul gateway-ului conține acel nume și eșuează într-un mod care pare o problemă de rutare când nu îl conține. Citiți profilul ca o succesiune de afirmații, nu ca o listă de câmpuri de completat.
Identificatorul local este propria afirmație a telefonului și trebuie să fie un nume pe care intrarea de identitate din RouterOS îl acceptă pentru certificatul de client pe care telefonul îl prezintă. Dacă cele două nu coincid, gateway-ul respinge conexiunea după ce certificatul însuși a fost validat, iar jurnalul arată ca o problemă de autorizare, nu de denumire.
Verificați identificatorii față de ceea ce prezintă gateway-ul
O intrare de partener din RouterOS configurată pentru autentificare cu certificat prezintă propriul certificat, iar identitatea ei este preluată din acel certificat dacă nu ați configurat altfel. Dacă identificatorul la distanță al telefonului numește numele DNS al gateway-ului, certificatul gateway-ului are nevoie de acel nume într-un loc pe care telefonul îl acceptă, de obicei un nume alternativ al subiectului. Un certificat emis pentru alt nume comun nu va valida chiar dacă cheia și lanțul sunt perfecte.
Profilele Apple administrate pot purta și o restricție privind numele certificatului, evaluată suplimentar față de câmpurile de identificator. Inspectați încărcătura în loc să deduceți numele de validare din ce afișează ecranul de setări, pentru că cele două nu sunt aceeași setare.
Verificați că certificatul de client este o cheie, nu doar o ancoră de încredere
Importarea unui certificat CA îi dă telefonului ceva cu care să valideze gateway-ul. Nu îi dă o identitate de client, iar autentificarea cu certificat are nevoie de certificatul frunză de client și de cheia lui privată livrate împreună prin calea de înregistrare aprobată. Un PKCS#12 construit fără cheia privată produce un profil care se instalează curat și nu autentifică nimic.
Frunza de client are nevoie și de o identitate pe care partea RouterOS o așteaptă, ceea ce înseamnă că subiectul sau numele alternativ al subiectului trebuie să corespundă configurației de identitate corespunzătoare. Emiterea certificatelor de client și de server dintr-o singură CA face lanțul comod și nu face cele două frunze interschimbabile.
Verificați că politica RouterOS acceptă acel nume
Pe gateway, intrarea de partener stabilește modul de schimb și metoda de autentificare, iar intrarea de identitate leagă identitatea la distanță acceptată de un certificat și de politica ce urmează. În RouterOS v7 această pereche este exprimată prin intrările de partener și de identitate IPsec, de exemplu un partener IKEv2 cu auth-method=digital-signature. Verificați conținutul real al meniului din versiunea instalată, nu un ghid scris pentru una mai veche.
Tot aici o nepotrivire este cel mai ieftin de reparat, pentru că gateway-ul vă poate spune atât identitatea primită, cât și pe cea dorită. Lărgirea identității acceptate pentru a reduce la tăcere eroarea elimină legătura care dădea sens implementării.
Verificați care etapă a eșuat înainte de a edita ceva
Citiți încercarea la ambele capete și clasificați-o înainte de a schimba o propunere. O nepotrivire a propunerii, o cheie de semnare lipsă, un emitent necredibil, un identificator de partener greșit și o autorizare de client respinsă arată toate ca un tunel mort dinspre telefon, iar fiecare are alt responsabil. Schimbarea tuturor celor cinci setări deodată garantează că nu veți învăța nimic din rezultat.
Notați identitatea prezentată, identitatea așteptată, emitentul și numărul de serie al certificatului și numele politicii relevante, ținând cheile private și secretele profilului în afara acelei note. Când autentificarea reușește, testați un serviciu privat și răspunsul lui, pentru că alocarea adreselor, selectorii, DNS-ul și politica de acces trebuie să funcționeze în continuare după terminarea schimbului IKE.