iPhone IKEv2 prema RouterOS: koji identifikator ide kamo
Četiri odvojena zahtjeva odlučuju o IKEv2 tunelu na iOS-u: birana adresa, očekivani identitet poslužitelja, tvrđeni identitet klijenta i certifikatni materijal.
Dolazak do MikroTik pristupnika rješava samo transportnu polovicu IKEv2 implementacije i ništa više. Zatim četiri odvojena zahtjeva odlučuju hoće li tunel nastati: adresa koju telefon bira, identitet poslužitelja koji očekuje, identitet koji tvrdi za sebe i certifikatni materijal koji podupire tu tvrdnju. Provjeravajte ih tim redoslijedom i zaustavite se na prvom koji se ne slaže s onim što pristupnik 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 redoslijedom 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 pristupnik dokazati da jest, i to je ime, a ne ruta. Popunjavanje obaju istim imenom hosta funkcionira kada certifikat pristupnika nosi to ime, a ne uspijeva na način koji izgleda kao problem usmjeravanja kada ga ne nosi. Čitajte profil kao slijed zahtjeva, a ne kao popis polja za popunjavanje.
Lokalni identifikator je vlastiti zahtjev telefona i mora biti ime koje RouterOS unos identiteta prihvaća za klijentski certifikat koji telefon predstavlja. Ako se njih dvoje ne slažu, pristupnik odbija vezu nakon što je sam certifikat validiran, a zapisnik izgleda kao problem autorizacije, a ne imenovanja.
Provjerite identifikatore prema onome što pristupnik 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 pristupnika, certifikat pristupnika 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 iste postavke.
Provjerite je li klijentski certifikat ključ, a ne samo sidro povjerenja
Uvoz CA certifikata daje telefonu nešto čime može validirati pristupnik. 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 poslužiteljskih 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 pristupniku 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 pristupnik može reći i identitet koji je primio i identitet koji je želio. Proširivanje prihvaćenog identiteta da bi se pogreš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.