iPhone IKEv2 na RouterOS: watter identifiseerder hoort waar
Vier afsonderlike aansprake bepaal 'n iOS IKEv2-tonnel: die geskakelde adres, die verwagte bedieneridentiteit, die beweerde kliëntidentiteit en die sertifikaatmateriaal.
Om by die MikroTik-hek uit te kom, beslis net die vervoerhelfte van 'n IKEv2-ontplooiing en niks anders nie. Vier afsonderlike aansprake bepaal dan of die tonnel gevorm word: die adres wat die foon skakel, die bedieneridentiteit wat dit verwag, die identiteit wat dit vir homself aanspreek, en die sertifikaatmateriaal wat daardie aanspraak ondersteun. Kontroleer hulle in daardie volgorde, en stop by die eerste een wat nie met die hek se aanbod ooreenstem nie. Elkeen is op 'n ander plek wysigbaar, en daarom verskuif 'n verkeerde wysiging gewoonlik die fout in plaas daarvan om dit reg te maak.
| 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 |
Kontroleer die profielvelde in die volgorde waarin die uitruiling hulle gebruik
Die Afgeleë adres is die bestemming vir die eerste IKE-pakket en niks meer nie. Die Afgeleë identifiseerder is wat die foon verwag die hek moet bewys, en dit is 'n naam, nie 'n roete nie. Om albei met dieselfde gasheernaam in te vul werk wanneer die hek se sertifikaat daardie naam dra, en misluk op 'n manier wat soos 'n roeteprobleem lyk wanneer dit nie die geval is nie. Lees die profiel as 'n reeks aansprake eerder as 'n lys velde om in te vul.
Die Plaaslike identifiseerder is die foon se eie aanspraak, en dit moet 'n naam wees wat die RouterOS-identiteitsinskrywing vir die kliëntsertifikaat wat die foon aanbied, aanvaar. Stem die twee nie ooreen nie, verwerp die hek die verbinding nadat die sertifikaat self geslaag het, en die log lyk soos 'n magtigingsprobleem eerder as 'n naamprobleem.
Kontroleer die identifiseerders teen wat die hek aanbied
'n RouterOS-portaalinskrywing wat vir sertifikaatverifikasie opgestel is, bied sy eie sertifikaat aan, en sy identiteit kom uit daardie sertifikaat tensy jy anders opgestel het. As die foon se Afgeleë identifiseerder die hek se DNS-naam noem, het die hek se sertifikaat daardie naam nodig op 'n plek wat die foon sal aanvaar, tipies 'n onderwerp-alternatiewe naam. 'n Sertifikaat wat vir 'n ander algemene naam uitgereik is, sal nie valideer nie, selfs al is die sleutel en ketting perfek.
Bestuurde Apple-profiele kan ook 'n sertifikaatnaambeperking dra wat bykomend by die identifiseerdervelde geëvalueer word. Ondersoek die loonvrag eerder as om die verifikasienaam af te lei uit wat die instellingsskerm wys, want die twee is nie dieselfde instelling nie.
Kontroleer dat die kliëntsertifikaat 'n sleutel is, nie net 'n vertrouensanker nie
Die invoer van 'n CA-sertifikaat gee die foon iets waarmee dit die hek kan valideer. Dit gee nie vir die foon 'n kliëntidentiteit nie, en sertifikaatverifikasie het die kliëntbladsertifikaat en sy private sleutel nodig wat saam deur die goedgekeurde inskrywingsroete gelewer word. 'n PKCS#12 wat sonder die private sleutel gebou is, lewer 'n profiel wat skoon installeer en niks verifieer nie.
Die kliëntblad het ook 'n identiteit nodig wat die RouterOS-kant verwag, wat beteken die onderwerp of onderwerp-alternatiewe naam moet ooreenstem met die ooreenstemmende identiteitskonfigurasie. Om kliënt- en bedienersertifikate van een CA uit te reik maak die ketting gerieflik en maak nie die twee blaaie onderling verwisselbaar nie.
Kontroleer dat die RouterOS-beleid daardie naam aanvaar
Op die hek stel die portaalinskrywing die uitruilmodus en verifikasiemetode vas, en die identiteitsinskrywing bind die aanvaarde afgeleë identiteit aan 'n sertifikaat en aan die beleid wat daarop volg. In RouterOS v7 word daardie koppeling uitgedruk deur die IPsec-portaal- en identiteitsinskrywings, byvoorbeeld 'n IKEv2-portaal met auth-method=digital-signature. Kontroleer die werklike menu-inhoud op jou geïnstalleerde weergawe eerder as 'n deurloop wat vir 'n ouer een geskryf is.
Dit is ook waar 'n wanverhouding die goedkoopste reg te maak is, want die hek kan jou beide die identiteit wat dit ontvang het en die identiteit wat dit wou hê, vertel. Om die aanvaarde identiteit te verbreed om die fout stil te maak, verwyder die binding wat die ontplooiing betekenisvol gemaak het.
Kontroleer watter stadium gefaal het voordat jy enigiets wysig
Lees die poging aan beide kante en klassifiseer dit voordat jy 'n voorstel verander. 'n Voorstel-wanverhouding, 'n ontbrekende ondertekeningsleutel, 'n onbetroubare uitreiker, 'n verkeerde portaalidentifiseerder en 'n verwerpte kliëntmagtiging lyk almal soos 'n dooie tonnel van die foon af, en elkeen het 'n ander eienaar. Om al vyf instellings gelyk te verander, waarborg dat jy niks uit die resultaat leer nie.
Teken die aangebode identiteit, die verwagte identiteit, die sertifikaatuitreiker en -reeksnommer, en die betrokke beleidsnaam aan, terwyl jy private sleutels en profielgeheime uit daardie rekord hou. Sodra verifikasie slaag, toets 'n private diens en sy antwoord, want adrestoewysing, keurders, DNS en toegangsbeleid moet nog werk nadat die IKE-uitruiling klaar is.