iPhone IKEv2 til RouterOS: hvilken identifikator hører hvor
Fire separate krav afgør en IKEv2-tunnel på iOS: den opkaldte adresse, den forventede serveridentitet, den hævdede klientidentitet og certifikatmaterialet.
At nå MikroTik-gatewayen afgør kun transportdelen af en IKEv2-opsætning og intet andet. Derefter afgør fire separate krav, om tunnelen dannes: adressen telefonen ringer til, den serveridentitet den forventer, den identitet den hævder for sig selv, og det certifikatmateriale der understøtter det krav. Kontrollér dem i den rækkefølge, og stop ved det første, der ikke stemmer med det, gatewayen præsenterer. Hvert af dem redigeres et andet sted, og derfor flytter en forkert redigering normalt fejlen i stedet for at 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 |
Kontrollér profilfelterne i den rækkefølge, udvekslingen bruger dem
Fjernadressen er destinationen for den første IKE-pakke og intet mere. Fjernidentifikatoren er det, telefonen forventer gatewayen beviser at være, og det er et navn, ikke en rute. At udfylde begge med samme værtsnavn virker, når gatewayens certifikat bærer det navn, og fejler på en måde, der ligner et routingproblem, når det ikke gør. Læs profilen som en sekvens af krav, ikke som en liste af felter, der skal udfyldes.
Lokalidentifikatoren er telefonens eget krav, og den skal være et navn, som RouterOS-identitetsposten accepterer for det klientcertifikat, telefonen præsenterer. Hvis de to ikke stemmer, afviser gatewayen forbindelsen, efter certifikatet selv er valideret, og loggen ligner et autorisationsproblem snarere end et navneproblem.
Kontrollér identifikatorerne mod det, gatewayen præsenterer
En RouterOS-peerpost konfigureret til certifikatautentificering præsenterer sit eget certifikat, og dens identitet hentes fra det certifikat, medmindre du har konfigureret andet. Hvis telefonens fjernidentifikator angiver gatewayens DNS-navn, skal gatewayens certifikat have det navn et sted, telefonen accepterer, typisk et alternativt subjektnavn. Et certifikat udstedt til et andet fælles navn vil ikke validere, selv om nøglen og kæden er perfekte.
Administrerede Apple-profiler kan også bære en certifikatnavnebegrænsning, der vurderes ud over identifikatorfelterne. Undersøg nyttelasten i stedet for at udlede valideringsnavnet fra det, indstillingsskærmen viser, fordi de to ikke er den samme indstilling.
Kontrollér, at klientcertifikatet er en nøgle, ikke bare et tillidsanker
Import af et CA-certifikat giver telefonen noget at validere gatewayen med. Det giver ikke telefonen en klientidentitet, og certifikatautentificering kræver klientens slutcertifikat og dets private nøgle leveret sammen gennem den godkendte tilmeldingsvej. En PKCS#12 bygget uden den private nøgle giver en profil, der installeres rent og autentificerer intet.
Klientens slutcertifikat har også brug for en identitet, som RouterOS-siden forventer, hvilket betyder, at subjektet eller det alternative subjektnavn skal passe med den tilsvarende identitetskonfiguration. Udstedelse af klient- og servercertifikater fra én CA gør kæden bekvem og gør ikke de to slutcertifikater udskiftelige.
Kontrollér, at RouterOS-politikken accepterer det navn
På gatewayen sætter peerposten udvekslingstilstanden og autentificeringsmetoden, og identitetsposten binder den accepterede fjernidentitet til et certifikat og til den politik, der følger. I RouterOS v7 udtrykkes det par gennem IPsec-peer- og identitetsposter, for eksempel en IKEv2-peer med auth-method=digital-signature. Kontrollér det faktiske menuindhold på din installerede version i stedet for en gennemgang skrevet til en ældre.
Det er også her, en uoverensstemmelse er billigst at rette, fordi gatewayen kan fortælle dig både den identitet, den modtog, og den identitet, den ville have. At udvide den accepterede identitet for at dæmpe fejlen fjerner den binding, der gjorde opsætningen meningsfuld.
Kontrollér, hvilket trin der fejlede, før du redigerer noget
Læs forsøget i begge ender, og klassificér det, før du ændrer et forslag. Uoverensstemmelse i forslaget, en manglende signeringsnøgle, en ikke-betroet udsteder, en forkert peeridentifikator og en afvist klientautorisation ligner alle en død tunnel fra telefonen, og hver har en anden ejer. At ændre alle fem indstillinger på én gang garanterer, at du ikke lærer noget af resultatet.
Notér den præsenterede identitet, den forventede identitet, certifikatets udsteder og serienummer samt det relevante politiknavn, mens private nøgler og profilhemmeligheder holdes uden for den registrering. Når autentificeringen lykkes, test en privat tjeneste og dens svar, fordi adressetildeling, selektorer, DNS og adgangspolitik stadig skal virke, efter IKE-udvekslingen er færdig.