iPhone IKEv2 til RouterOS: hvilken identifikator hører hvor
Fire separate krav avgjør en IKEv2-tunnel på iOS: den oppringte adressen, forventet serveridentitet, hevdet klientidentitet og sertifikatmaterialet.
Å nå MikroTik-gatewayen avgjør bare transportdelen av en IKEv2-utrulling og ingenting annet. Deretter avgjør fire separate krav om tunnelen dannes: adressen telefonen ringer, serveridentiteten den forventer, identiteten den hevder for seg selv, og sertifikatmaterialet som underbygger det kravet. Kontroller dem i den rekkefølgen, og stopp ved det første som ikke stemmer med det gatewayen presenterer. Hvert av dem redigeres på et ulikt sted, og derfor flytter en feil redigering vanligvis feilen i stedet for å rette den.
| 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 profilfeltene i den rekkefølgen utvekslingen bruker dem
Fjernadressen er målet for den første IKE-pakken og ingenting mer. Fjernidentifikatoren er det telefonen forventer at gatewayen beviser at den er, og det er et navn, ikke en rute. Å fylle begge med samme vertsnavn virker når gatewayens sertifikat bærer det navnet, og feiler på en måte som ser ut som et ruteproblem når det ikke gjør det. Les profilen som en sekvens av krav, ikke som en liste med felter som skal fylles ut.
Lokalidentifikatoren er telefonens eget krav, og den må være et navn som RouterOS-identitetsoppføringen godtar for klientsertifikatet telefonen presenterer. Hvis de to ikke stemmer, avviser gatewayen tilkoblingen etter at sertifikatet selv er validert, og loggen ser ut som et autorisasjonsproblem snarere enn et navneproblem.
Kontroller identifikatorene mot det gatewayen presenterer
En RouterOS-peer-oppføring konfigurert for sertifikatautentisering presenterer sitt eget sertifikat, og identiteten hentes fra det sertifikatet med mindre du har konfigurert noe annet. Hvis telefonens fjernidentifikator angir gatewayens DNS-navn, trenger gatewayens sertifikat det navnet på et sted telefonen godtar, vanligvis et alternativt subjektnavn. Et sertifikat utstedt til et annet vanlig navn vil ikke validere selv om nøkkelen og kjeden er perfekte.
Administrerte Apple-profiler kan også bære en sertifikatnavnbegrensning som vurderes i tillegg til identifikatorfeltene. Undersøk nyttelasten i stedet for å utlede valideringsnavnet fra det innstillingsskjermen viser, fordi de to ikke er den samme innstillingen.
Kontroller at klientsertifikatet er en nøkkel, ikke bare et tillitsanker
Import av et CA-sertifikat gir telefonen noe å validere gatewayen med. Det gir ikke telefonen en klientidentitet, og sertifikatautentisering krever klientens bladsertifikat og dens private nøkkel levert sammen gjennom den godkjente registreringsveien. En PKCS#12 bygget uten den private nøkkelen gir en profil som installeres rent og ikke autentiserer noe.
Klientbladet trenger også en identitet som RouterOS-siden forventer, noe som betyr at subjektet eller det alternative subjektnavnet må stemme med den tilsvarende identitetskonfigurasjonen. Å utstede klient- og serversertifikater fra én CA gjør kjeden praktisk og gjør ikke de to bladene utbyttbare.
Kontroller at RouterOS-policyen godtar det navnet
På gatewayen setter peer-oppføringen utvekslingsmodusen og autentiseringsmetoden, og identitetsoppføringen binder den godtatte fjernidentiteten til et sertifikat og til policyen som følger. I RouterOS v7 uttrykkes det paret gjennom IPsec-peer- og identitetsoppføringene, for eksempel en IKEv2-peer med auth-method=digital-signature. Kontroller det faktiske menyinnholdet på den installerte versjonen din, ikke en gjennomgang skrevet for en eldre.
Det er også her en uoverensstemmelse er billigst å rette, fordi gatewayen kan fortelle deg både identiteten den mottok og den den ville ha. Å utvide den godtatte identiteten for å dempe feilen fjerner bindingen som gjorde utrullingen meningsfull.
Kontroller hvilket trinn som feilet før du redigerer noe
Les forsøket i begge ender og klassifiser det før du endrer et forslag. Uoverensstemmelse i forslaget, en manglende signeringsnøkkel, en ikke-klarert utsteder, en feil peer-identifikator og en avvist klientautorisasjon ser alle ut som en død tunnel fra telefonen, og hver har en ulik eier. Å endre alle fem innstillingene samtidig garanterer at du ikke lærer noe av resultatet.
Noter den presenterte identiteten, den forventede identiteten, sertifikatets utsteder og serienummer og navnet på den relevante policyen, mens private nøkler og profilhemmeligheter holdes utenfor den registreringen. Når autentiseringen lykkes, test en privat tjeneste og svaret dens, fordi adressetildeling, selektorer, DNS og tilgangspolicy fortsatt må virke etter at IKE-utvekslingen er ferdig.