iPhone IKEv2 til RouterOS: kva identifikator høyrer kvar
Fire separate krav avgjer ein IKEv2-tunnel på iOS: den oppringde adressa, venta serveridentitet, hevda klientidentitet og sertifikatmaterialet.
Å nå MikroTik-gatewayen gjer berre halve transportdelen av ein IKEv2-utrulling og ingenting anna. Deretter avgjer fire separate krav om tunnelen vert danna: adressa telefonen ringjer, serveridentiteten han ventar, identiteten han hevdar for seg sjølv, og sertifikatmaterialet som støttar det kravet. Kontroller dei i den rekkjefølgja, og stopp ved det første som ikkje stemmer med det gatewayen presenterer. Kvart av dei vert redigert på ein annan stad, og difor flyttar ei feil redigering vanlegvis feilen i staden for å rette han.
| 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 |
Kontroller profilfelta i den rekkjefølgja utvekslinga brukar dei
Fjernadressa er målet for den første IKE-pakken og ingenting meir. Fjernidentifikatoren er det telefonen ventar at gatewayen provar at han er, og det er eit namn, ikkje ei rute. Å fylle begge med same vertsnamn verkar når sertifikatet til gatewayen ber det namnet, og feilar på ein måte som ser ut som eit ruteproblem når det ikkje gjer det. Les profilen som ei rekkje krav, ikkje som ei liste med felt som skal fyllast ut.
Lokalidentifikatoren er det eigne kravet til telefonen, og han må vere eit namn som RouterOS-identitetsoppføringa godtek for klientsertifikatet telefonen presenterer. Viss dei to ikkje stemmer, avviser gatewayen tilkoplinga etter at sertifikatet sjølv er validert, og loggen ser ut som eit autorisasjonsproblem snarare enn eit namneblem.
Kontroller identifikatorane mot det gatewayen presenterer
Ei RouterOS-peer-oppføring sett opp for sertifikatautentisering presenterer sitt eige sertifikat, og identiteten hennar er henta frå det sertifikatet med mindre du har sett opp noko anna. Viss fjernidentifikatoren til telefonen nemner DNS-namnet til gatewayen, treng sertifikatet til gatewayen det namnet på ein stad telefonen godtek, vanlegvis eit alternativt subjektnamn. Eit sertifikat utferda til eit anna vanleg namn vil ikkje validere sjølv om nøkkelen og kjeda er perfekte.
Administrerte Apple-profil kan òg bere ei sertifikatnamnavgrensing som vert vurdert i tillegg til identifikatorfelta. Undersøk nyttelasta i staden for å utleie valideringsnamnet frå det innstillingsskjermen viser, fordi dei to ikkje er den same innstillinga.
Kontroller at klientsertifikatet er ein nøkkel, ikkje berre eit tillitsanker
Import av eit CA-sertifikat gir telefonen noko å validere gatewayen med. Det gir ikkje telefonen ein klientidentitet, og sertifikatautentisering krev bladsertifikatet til klienten og den private nøkkelen hans levert saman gjennom den godkjende registreringsvegen. Ein PKCS#12 bygd utan den private nøkkelen gir ein profil som installerer seg reint og ikkje autentiserer noko.
Klientbladet treng òg ein identitet som RouterOS-sida ventar, noko som tyder at subjektet eller det alternative subjektnamnet må stemme med den tilsvarande identitetskonfigurasjonen. Å utferde klient- og serversertifikat frå éin CA gjer kjeda praktisk og gjer ikkje dei to blada utbyttbare.
Kontroller at RouterOS-policyen godtek det namnet
På gatewayen set peer-oppføringa utvekslingsmodusen og autentiseringsmetoden, og identitetsoppføringa bind den godtekne fjernidentiteten til eit sertifikat og til policyen som følgjer. I RouterOS v7 vert det paret uttrykt gjennom IPsec-peer- og identitetsoppføringane, til dømes ein IKEv2-peer med auth-method=digital-signature. Kontroller det faktiske menyinnhaldet på den installerte versjonen din, ikkje ein gjennomgang skriven for ein eldre.
Det er òg her ein usemje er billegast å rette, fordi gatewayen kan fortelje deg både identiteten han tok imot og den han ville ha. Å utvide den godtekne identiteten for å dempe feilen fjernar bindinga som gjorde utrullinga meiningsfull.
Kontroller kva trinn som feila før du redigerer noko
Les forsøket i begge endar og klassifiser det før du endrar eit framlegg. Usemje i framlegget, ein manglande signeringsnøkkel, ein utferdar du ikkje stolar på, ein feil peer-identifikator og ein avvist klientautorisasjon ser alle ut som ein daud tunnel frå telefonen, og kvar har ein ulik eigar. Å endre alle fem innstillingane samstundes garanterer at du ikkje lærer noko av resultatet.
Noter den presenterte identiteten, den venta identiteten, utferdaren og serienummeret til sertifikatet og namnet på den relevante policyen, medan private nøklar og profilhemmelegg held seg utanfor den registreringa. Når autentiseringa lukkast, test ein privat teneste og svaret hans, fordi adressetildeling, selektorar, DNS og tilgangspolicy framleis må verke etter at IKE-utvekslinga er ferdig.