iPhone IKEv2 uz RouterOS: kurš identifikators kur nonāk
Četri atsevišķi apgalvojumi izšķir iOS IKEv2 tuneli: izvēlētā adrese, gaidītā servera identitāte, pieprasītā klienta identitāte un sertifikāta materiāls.
MikroTik vārtejas sasniegšana atrisina tikai IKEv2 ieviešanas transporta pusi un neko citu. Pēc tam četri atsevišķi apgalvojumi izšķir, vai tunelis izveidosies: adrese, uz kuru telefons zvana, gaidītā servera identitāte, sev pieprasītā identitāte un sertifikāta materiāls, kas šo apgalvojumu pamato. Pārbaudiet tos šajā secībā un apstājieties pie pirmā, kas neatbilst tam, ko uzrāda vārteja. Katrs tiek rediģēts citā vietā, tāpēc nepareizs labojums parasti pārvieto kļūmi, nevis to novērš.
| 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 |
Pārbaudiet profila laukus tādā secībā, kādā tos izmanto apmaiņa
Attālā adrese ir pirmā IKE paketes galamērķis un nekas vairāk. Attālais identifikators ir tas, ko telefons gaida, ka vārteja pierādīs esam, un tas ir nosaukums, nevis maršruts. Abu aizpildīšana ar vienu un to pašu resursdatora nosaukumu darbojas, ja vārtejas sertifikāts satur šo nosaukumu, un neizdodas tā, kas izskatās pēc maršrutēšanas problēmas, ja tas to nesatur. Lasiet profilu kā apgalvojumu virkni, nevis kā aizpildāmu lauku sarakstu.
Vietējais identifikators ir paša telefona apgalvojums, un tam jābūt nosaukumam, ko RouterOS identitātes ieraksts pieņem telefona uzrādītajam klienta sertifikātam. Ja abi neatbilst, vārteja noraida savienojumu pēc tam, kad pats sertifikāts ir validēts, un žurnāls izskatās pēc autorizācijas, nevis nosaukuma problēmas.
Pārbaudiet identifikatorus pret to, ko uzrāda vārteja
RouterOS partnera ieraksts, kas konfigurēts sertifikāta autentifikācijai, uzrāda savu sertifikātu, un tā identitāte tiek iegūta no šī sertifikāta, ja vien neesat konfigurējis citādi. Ja telefona attālais identifikators nosauc vārtejas DNS nosaukumu, vārtejas sertifikātam šis nosaukums ir vajadzīgs vietā, ko telefons pieņems, parasti subjekta alternatīvajā nosaukumā. Sertifikāts, kas izsniegts citam vispārīgajam nosaukumam, netiks validēts arī tad, ja atslēga un ķēde ir nevainojamas.
Pārvaldītie Apple profili var saturēt arī sertifikāta nosaukuma ierobežojumu, kas tiek vērtēts papildus identifikatora laukiem. Pārbaudiet saturu, nevis seciniet validācijas nosaukumu no tā, ko rāda iestatījumu ekrāns, jo tie nav viens un tas pats iestatījums.
Pārbaudiet, vai klienta sertifikāts ir atslēga, nevis tikai uzticības enkurs
CA sertifikāta importēšana dod telefonam kaut ko, ar ko validēt vārteju. Tas nedod telefonam klienta identitāti, un sertifikāta autentifikācijai vajadzīgs klienta lapas sertifikāts un tā privātā atslēga, kas piegādāti kopā pa apstiprināto reģistrācijas ceļu. PKCS#12, kas veidots bez privātās atslēgas, dod profilu, kas tīri instalējas un neko neautentificē.
Klienta lapai vajadzīga arī identitāte, ko gaida RouterOS puse, tas nozīmē, ka subjektam vai subjekta alternatīvajam nosaukumam jāsakrīt ar atbilstošo identitātes konfigurāciju. Klienta un servera sertifikātu izsniegšana no vienas CA padara ķēdi ērtu un nepadara abas lapas savstarpēji aizstājamas.
Pārbaudiet, vai RouterOS politika pieņem šo nosaukumu
Uz vārtejas partnera ieraksts nosaka apmaiņas režīmu un autentifikācijas metodi, un identitātes ieraksts saista pieņemto attālo identitāti ar sertifikātu un ar politiku, kas seko. RouterOS v7 šis pāris tiek izteikts ar IPsec partnera un identitātes ierakstiem, piemēram, IKEv2 partneris ar auth-method=digital-signature. Pārbaudiet faktisko izvēlnes saturu savā instalētajā laidienā, nevis rokasgrāmatu, kas rakstīta vecākam.
Šeit arī neatbilstību ir vislētāk novērst, jo vārteja var pateikt gan saņemto, gan vēlamo identitāti. Pieņemtās identitātes paplašināšana, lai klusinātu kļūdu, noņem saiti, kas ieviešanai deva jēgu.
Pārbaudiet, kurš posms neizdevās, pirms kaut ko rediģējat
Izlasiet mēģinājumu abos galos un klasificējiet to pirms priekšlikuma maiņas. Priekšlikuma neatbilstība, trūkstoša parakstīšanas atslēga, neuzticams izdevējs, nepareizs partnera identifikators un noraidīta klienta autorizācija no telefona izskatās kā miris tunelis, un katram ir cits atbildīgais. Visu piecu iestatījumu maiņa uzreiz garantē, ka no rezultāta neko neuzzināsiet.
Pierakstiet uzrādīto identitāti, gaidīto identitāti, sertifikāta izdevēju un sērijas numuru un attiecīgās politikas nosaukumu, turot privātās atslēgas un profila noslēpumus ārpus šī pieraksta. Kad autentifikācija izdodas, pārbaudiet privātu pakalpojumu un tā atbildi, jo adrešu piešķiršanai, selektoriem, DNS un piekļuves politikai joprojām jādarbojas pēc IKE apmaiņas beigām.