iPhone IKEv2 RouterOS-i: milline identifikaator kuhu kuulub
Neli eraldi väidet otsustavad iOS-i IKEv2 tunnelite üle: valitav aadress, oodatav serveri identiteet, esitatav kliendi identiteet ja sertifikaadimaterjal.
MikroTiki väravani jõudmine lahendab IKEv2 juurutuse ainult transpordipoole ega midagi muud. Seejärel otsustavad tunnelitekkimise üle neli eraldi väidet: telefon valitav aadress, oodatav serveri identiteet, enda kohta esitatav identiteet ja seda väidet toetav sertifikaadimaterjal. Kontrollige neid selles järjekorras ja peatuge esimesel, mis ei ühti sellega, mida värav esitab. Igaüht muudetakse eri kohas, mistõttu vale muudatus tavaliselt viib tõrke edasi, selle asemel et see parandada.
| 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 |
Kontrollige profiili välju järjekorras, milles vahetus neid kasutab
Kaugaadress on esimese IKE-paketi sihtkoht ja ei midagi enamat. Kaugidentifikaator on see, mida telefon ootab värava enda tõestavat olevat, ja see on nimi, mitte marsruut. Mõlema täitmine sama hostinimega toimib siis, kui värava sertifikaat seda nime kannab, ja ebaõnnestub viisil, mis näeb välja nagu marsruutimisprobleem, kui ei kanna. Lugege profiili väidete jadana, mitte täidetavate väljade loendina.
Kohalik identifikaator on telefoni enda väide ja peab olema nimi, mille RouterOS-i identiteedikirje aktsepteerib telefoni esitatava kliendisertifikaadi jaoks. Kui need kaks ei ühti, lükkab värav ühenduse tagasi pärast seda, kui sertifikaat ise on valideeritud, ja logi näeb välja nagu autoriseerimis-, mitte nimeprobleem.
Kontrollige identifikaatoreid selle vastu, mida värav esitab
Sertifikaadi autentimiseks seadistatud RouterOS-i partnerkirje esitab oma sertifikaadi ja selle identiteet pärineb sellest sertifikaadist, kui te pole teisiti seadistanud. Kui telefoni kaugidentifikaator nimetab värava DNS-nime, vajab värava sertifikaat seda nime kohas, mille telefon aktsepteerib, tavaliselt subjekti alternatiivses nimes. Teise üldnime jaoks välja antud sertifikaat ei valideeru ka siis, kui võti ja ahel on täiuslikud.
Hallatavad Apple'i profiilid võivad kanda ka sertifikaadinime piirangut, mida hinnatakse lisaks identifikaatorväljadele. Uurige kasulikku koormust, selle asemel et tuletada valideerimisnimi seadete ekraanil näidatavast, sest need kaks ei ole sama säte.
Kontrollige, et kliendisertifikaat on võti, mitte ainult usaldusankur
CA-sertifikaadi importimine annab telefonile midagi, millega väravat valideerida. See ei anna telefonile kliendiidentiteeti ja sertifikaadiautentimine vajab kliendi lõppsertifikaati ja selle privaatvõtit, mis tarnitakse koos kinnitatud registreerimisteekonna kaudu. Ilma privaatvõtmeta koostatud PKCS#12 annab profiili, mis paigaldub puhtalt ega autenti midagi.
Kliendi lõppsertifikaat vajab ka identiteeti, mida RouterOS-i pool ootab, mis tähendab, et subjekt või subjekti alternatiivne nimi peab ühtima vastava identiteedikonfiguratsiooniga. Kliendi- ja serverisertifikaatide väljastamine ühest CA-st teeb ahela mugavaks ega muuda kahte lõppsertifikaati vahetatavaks.
Kontrollige, et RouterOS-i poliitika selle nime vastu võtab
Väravas määrab partnerkirje vahetusrežiimi ja autentimismeetodi ning identiteedikirje seob aktsepteeritud kaugidentiteedi sertifikaadi ja järgneva poliitikaga. RouterOS v7-s väljendatakse see paar IPseci partner- ja identiteedikirjetega, näiteks IKEv2 partner kirjega auth-method=digital-signature. Kontrollige oma paigaldatud versiooni tegelikku menüüsisu, mitte vanemale versioonile kirjutatud juhendit.
Siin on lahknevust ka kõige odavam parandada, sest värav saab teile öelda nii vastuvõetud kui ka soovitud identiteedi. Aktsepteeritud identiteedi laiendamine vea vaigistamiseks eemaldab sideme, mis andis juurutusele mõtte.
Kontrollige, milline etapp ebaõnnestus, enne kui midagi muudate
Lugege katset mõlemas otsas ja liigitage see enne pakkumise muutmist. Pakkumise lahknevus, puuduv allkirjavõti, ebausaldusväärne väljaandja, vale partneridentifikaator ja tagasilükatud kliendi autoriseerimine näevad telefonist kõik välja nagu surnud tunnel ja igaühel on eri omanik. Kõigi viie sätte korraga muutmine tagab, et te ei õpi tulemusest midagi.
Kirjutage üles esitatud identiteet, oodatav identiteet, sertifikaadi väljaandja ja seerianumber ning asjakohase poliitika nimi, hoides privaatvõtmed ja profiilisaladused sellest kirjest väljas. Kui autentimine õnnestub, testige privaatset teenust ja selle vastust, sest aadresside määramine, selektorid, DNS ja juurdepääsupoliitika peavad pärast IKE-vahetuse lõppu ikka toimima.