iPhone IKEv2 prema RouterOS: koji identifikator ide gdje
Četiri odvojena zahtjeva odlučuju o iOS IKEv2 tunelu: birana adresa, očekivani identitet servera, tvrđeni identitet klijenta i certifikatni materijal.
Dolazak do MikroTik gatewaya rješava samo transportnu polovinu IKEv2 implementacije i ništa više. Zatim četiri odvojena zahtjeva odlučuju hoće li tunel nastati: adresa koju telefon bira, identitet servera koji očekuje, identitet koji tvrdi za sebe i certifikatni materijal koji podupire tu tvrdnju. Provjeravajte ih tim redom i zaustavite se na prvom koji se ne slaže s onim što gateway predstavlja. Svaki se uređuje na drugom mjestu, zbog čega pogrešna izmjena obično premješta kvar umjesto da ga popravi.
| 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 |
Provjerite polja profila redom kojim ih razmjena koristi
Udaljena adresa je odredište prvog IKE paketa i ništa više. Udaljeni identifikator je ono za što telefon očekuje da će gateway dokazati da jest, i to je ime, a ne ruta. Popunjavanje oba istim imenom hosta funkcionira kada certifikat gatewaya nosi to ime, a ne uspijeva na način koji izgleda kao problem rutiranja kada ga ne nosi. Čitajte profil kao slijed zahtjeva, a ne kao popis polja za popunjavanje.
Lokalni identifikator je telefonov vlastiti zahtjev i mora biti ime koje RouterOS unos identiteta prihvaća za klijentski certifikat koji telefon predstavlja. Ako se njih dvoje ne slažu, gateway odbija vezu nakon što je sam certifikat validiran, a zapisnik izgleda kao problem autorizacije, a ne imenovanja.
Provjerite identifikatore prema onome što gateway predstavlja
RouterOS unos partnera konfiguriran za autentifikaciju certifikatom predstavlja vlastiti certifikat, a njegov se identitet crpi iz tog certifikata osim ako niste konfigurirali drukčije. Ako udaljeni identifikator telefona imenuje DNS ime gatewaya, certifikat gatewaya treba to ime na mjestu koje će telefon prihvatiti, obično u alternativnom imenu subjekta. Certifikat izdan za drugo uobičajeno ime neće proći validaciju iako su ključ i lanac savršeni.
Upravljani Apple profili mogu nositi i ograničenje imena certifikata koje se ocjenjuje uz polja identifikatora. Pregledajte sadržaj umjesto da ime za validaciju zaključujete iz onoga što prikazuje zaslon postavki, jer to nisu ista postavka.
Provjerite je li klijentski certifikat ključ, a ne samo sidro povjerenja
Uvoz CA certifikata daje telefonu nešto čime može validirati gateway. Ne daje telefonu klijentski identitet, a autentifikacija certifikatom zahtijeva klijentski završni certifikat i njegov privatni ključ dostavljene zajedno odobrenim putem upisa. PKCS#12 izgrađen bez privatnog ključa daje profil koji se čisto instalira i ništa ne autentificira.
Završni klijentski certifikat također treba identitet koji RouterOS strana očekuje, što znači da se subjekt ili alternativno ime subjekta mora poklopiti s odgovarajućom konfiguracijom identiteta. Izdavanje klijentskih i serverskih certifikata iz jednog CA čini lanac praktičnim i ne čini ta dva završna certifikata zamjenjivima.
Provjerite prihvaća li RouterOS politika to ime
Na gatewayu unos partnera postavlja način razmjene i metodu autentifikacije, a unos identiteta veže prihvaćeni udaljeni identitet uz certifikat i uz politiku koja slijedi. U RouterOS v7 taj se par izražava kroz IPsec unose partnera i identiteta, na primjer partner IKEv2 s auth-method=digital-signature. Provjerite stvarni sadržaj izbornika na instaliranoj verziji, a ne vodič napisan za stariju.
Ovdje je i nesklad najjeftinije popraviti, jer vam gateway može reći i identitet koji je primio i identitet koji je želio. Proširivanje prihvaćenog identiteta da bi se greška ušutkala uklanja vezu koja je implementaciji davala smisao.
Provjerite koja je faza pala prije nego što išta uredite
Pročitajte pokušaj na oba kraja i klasificirajte ga prije nego što promijenite prijedlog. Nesklad prijedloga, nedostajući ključ za potpisivanje, nepouzdan izdavatelj, pogrešan identifikator partnera i odbijena autorizacija klijenta — sve izgleda kao mrtav tunel s telefona, a svaki ima drugog vlasnika. Mijenjanje svih pet postavki odjednom jamči da iz rezultata nećete naučiti ništa.
Zabilježite predstavljeni identitet, očekivani identitet, izdavatelja i serijski broj certifikata te naziv relevantne politike, držeći privatne ključeve i tajne profila izvan tog zapisa. Kad autentifikacija uspije, testirajte privatnu uslugu i njezin odgovor, jer dodjela adresa, selektori, DNS i politika pristupa još moraju raditi nakon što IKE razmjena završi.