iPhone IKEv2 till RouterOS: vilken identifierare hör var
Fyra separata påståenden avgör en IKEv2-tunnel på iOS: den uppringda adressen, förväntad serveridentitet, hävdad klientidentitet och certifikatmaterialet.
Att nå MikroTik-gatewayen avgör bara transportdelen av en IKEv2-distribution och ingenting annat. Därefter avgör fyra separata påståenden om tunneln bildas: adressen som telefonen ringer, serveridentiteten den förväntar sig, identiteten den hävdar för sig själv och certifikatmaterialet som underbygger det påståendet. Kontrollera dem i den ordningen och stanna vid det första som inte stämmer med det gatewayen presenterar. Var och en redigeras på olika ställen, och därför flyttar en felaktig redigering oftast felet i stället för att åtgärda det.
| 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 |
Kontrollera profilfälten i den ordning som utbytet använder dem
Fjärradressen är destinationen för det första IKE-paketet och ingenting mer. Fjärridentifieraren är vad telefonen förväntar sig att gatewayen bevisar att den är, och det är ett namn, inte en rutt. Att fylla båda med samma värdnamn fungerar när gatewayens certifikat bär det namnet, och misslyckas på ett sätt som ser ut som ett routingproblem när det inte gör det. Läs profilen som en följd av påståenden, inte som en lista med fält att fylla i.
Den lokala identifieraren är telefonens eget påstående, och den måste vara ett namn som RouterOS identitetspost accepterar för det klientcertifikat som telefonen presenterar. Om de två inte stämmer avvisar gatewayen anslutningen efter att certifikatet självt har validerats, och loggen ser ut som ett auktoriseringsproblem snarare än ett namngivningsproblem.
Kontrollera identifierarna mot det gatewayen presenterar
En RouterOS-peer-post konfigurerad för certifikatautentisering presenterar sitt eget certifikat, och dess identitet hämtas från det certifikatet om du inte har konfigurerat något annat. Om telefonens fjärridentifierare anger gatewayens DNS-namn behöver gatewayens certifikat det namnet på en plats som telefonen accepterar, vanligen ett alternativt subjektnamn. Ett certifikat som utfärdats för ett annat vanligt namn valideras inte ens om nyckeln och kedjan är felfria.
Hanterade Apple-profiler kan också bära en certifikatnamnsbegränsning som utvärderas utöver identifierarfälten. Granska nyttolasten i stället för att härleda valideringsnamnet från det inställningsskärmen visar, eftersom de två inte är samma inställning.
Kontrollera att klientcertifikatet är en nyckel, inte bara ett förtroendeankare
Import av ett CA-certifikat ger telefonen något att validera gatewayen med. Det ger inte telefonen en klientidentitet, och certifikatautentisering kräver klientens lövcertifikat och dess privata nyckel levererade tillsammans via den godkända registreringsvägen. En PKCS#12 byggd utan den privata nyckeln ger en profil som installeras rent och inte autentiserar något.
Klientlövet behöver också en identitet som RouterOS-sidan förväntar sig, vilket betyder att subjektet eller det alternativa subjektnamnet måste stämma med motsvarande identitetskonfiguration. Att utfärda klient- och servercertifikat från en och samma CA gör kedjan bekväm och gör inte de två löven utbytbara.
Kontrollera att RouterOS-policyn accepterar det namnet
På gatewayen anger peer-posten utbytesläget och autentiseringsmetoden, och identitetsposten binder den accepterade fjärridentiteten till ett certifikat och till policyn som följer. I RouterOS v7 uttrycks det paret genom IPsec-peer- och identitetsposterna, till exempel en IKEv2-peer med auth-method=digital-signature. Kontrollera det faktiska menyinnehållet i din installerade version, inte en genomgång skriven för en äldre.
Här är en avvikelse också billigast att åtgärda, eftersom gatewayen kan berätta både identiteten den tog emot och den den ville ha. Att vidga den accepterade identiteten för att tysta felet tar bort den bindning som gav distributionen mening.
Kontrollera vilket steg som misslyckades innan du redigerar något
Läs försöket i båda ändar och klassificera det innan du ändrar ett förslag. En avvikelse i förslaget, en saknad signeringsnyckel, en ej betrodd utfärdare, en felaktig peer-identifierare och ett avvisat klienttillstånd ser alla ut som en död tunnel från telefonen, och var och en har en annan ägare. Att ändra alla fem inställningarna på en gång garanterar att du inte lär dig något av resultatet.
Anteckna den presenterade identiteten, den förväntade identiteten, certifikatets utfärdare och serienummer samt namnet på den relevanta policyn, och håll privata nycklar och profilhemligheter utanför den anteckningen. När autentiseringen lyckas, testa en privat tjänst och dess svar, eftersom adresstilldelning, selektorer, DNS och åtkomstpolicy fortfarande måste fungera efter att IKE-utbytet är klart.