iPhone IKEv2 zum RouterOS: welche Kennung wohin gehört
Vier getrennte Behauptungen entscheiden über einen IKEv2-Tunnel unter iOS: die gewählte Adresse, die erwartete Serveridentität, die beanspruchte Client-Identität und das Zertifikatsmaterial.
Die MikroTik-Gateway zu erreichen, klärt nur die Transport-Hälfte einer IKEv2-Bereitstellung und sonst nichts. Danach entscheiden vier getrennte Behauptungen, ob der Tunnel entsteht: die Adresse, die das Telefon wählt, die Serveridentität, die es erwartet, die Identität, die es für sich selbst beansprucht, und das Zertifikatsmaterial, das diese Behauptung stützt. Prüfen Sie sie in dieser Reihenfolge und halten Sie bei der ersten an, die nicht zu dem passt, was das Gateway präsentiert. Jede wird an einer anderen Stelle bearbeitet, weshalb eine falsche Bearbeitung den Fehler meist verschiebt, statt ihn zu beheben.
| 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 |
Prüfen Sie die Profilfelder in der Reihenfolge, in der der Austausch sie verwendet
Die entfernte Adresse ist das Ziel des ersten IKE-Pakets und nichts weiter. Die entfernte Kennung ist das, was das Telefon vom Gateway als Nachweis seiner Identität erwartet, und sie ist ein Name, keine Route. Beide mit demselben Hostnamen zu füllen funktioniert, wenn das Gateway-Zertifikat diesen Namen trägt, und scheitert auf eine Weise, die wie ein Routingproblem aussieht, wenn es ihn nicht trägt. Lesen Sie das Profil als Folge von Behauptungen, nicht als Liste auszufüllender Felder.
Die lokale Kennung ist die eigene Behauptung des Telefons und muss ein Name sein, den der RouterOS-Identitätseintrag für das Client-Zertifikat akzeptiert, das das Telefon vorlegt. Stimmen die beiden nicht überein, lehnt das Gateway die Verbindung ab, nachdem das Zertifikat selbst validiert wurde, und das Protokoll sieht wie ein Autorisierungs- statt wie ein Namensproblem aus.
Prüfen Sie die Kennungen gegen das, was das Gateway präsentiert
Ein für Zertifikatsauthentifizierung konfigurierter RouterOS-Peer-Eintrag präsentiert sein eigenes Zertifikat, und seine Identität stammt aus diesem Zertifikat, sofern Sie nichts anderes konfiguriert haben. Nennt die entfernte Kennung des Telefons den DNS-Namen des Gateways, braucht das Gateway-Zertifikat diesen Namen an einer Stelle, die das Telefon akzeptiert, üblicherweise als alternativer Subjektname. Ein für einen anderen Common Name ausgestelltes Zertifikat wird nicht validiert, selbst wenn Schlüssel und Kette einwandfrei sind.
Verwaltete Apple-Profile können außerdem eine Zertifikatsnamen-Beschränkung tragen, die zusätzlich zu den Kennungsfeldern ausgewertet wird. Untersuchen Sie die Nutzlast, statt den Validierungsnamen aus dem abzuleiten, was der Einstellungsbildschirm zeigt, denn beides ist nicht dieselbe Einstellung.
Prüfen Sie, ob das Client-Zertifikat ein Schlüssel ist und nicht nur ein Vertrauensanker
Der Import eines CA-Zertifikats gibt dem Telefon etwas, womit es das Gateway validieren kann. Es gibt ihm keine Client-Identität, und Zertifikatsauthentifizierung benötigt das Client-Endzertifikat und dessen privaten Schlüssel gemeinsam über den freigegebenen Registrierungspfad. Ein ohne den privaten Schlüssel erstelltes PKCS#12 ergibt ein Profil, das sich sauber installieren lässt und nichts authentifiziert.
Das Client-Endzertifikat braucht außerdem eine Identität, die die RouterOS-Seite erwartet, das heißt, Subject oder alternativer Subjektname müssen zur entsprechenden Identitätskonfiguration passen. Client- und Serverzertifikate von einer CA auszustellen macht die Kette bequem und macht die beiden Endzertifikate nicht austauschbar.
Prüfen Sie, ob die RouterOS-Richtlinie diesen Namen akzeptiert
Auf dem Gateway legt der Peer-Eintrag den Austauschmodus und die Authentifizierungsmethode fest, und der Identitätseintrag bindet die akzeptierte entfernte Identität an ein Zertifikat und an die folgende Richtlinie. In RouterOS v7 wird diese Paarung über die IPsec-Peer- und Identitätseinträge ausgedrückt, zum Beispiel ein IKEv2-Peer mit auth-method=digital-signature. Prüfen Sie die tatsächlichen Menüinhalte Ihrer installierten Version statt einer Anleitung für eine ältere.
Hier lässt sich eine Abweichung auch am günstigsten beheben, weil das Gateway Ihnen sowohl die empfangene als auch die gewünschte Identität nennen kann. Die akzeptierte Identität zu erweitern, um den Fehler zum Schweigen zu bringen, entfernt die Bindung, die der Bereitstellung ihren Sinn gab.
Prüfen Sie, welche Stufe fehlgeschlagen ist, bevor Sie etwas bearbeiten
Lesen Sie den Versuch auf beiden Seiten und ordnen Sie ihn ein, bevor Sie einen Vorschlag ändern. Eine Vorschlagsabweichung, ein fehlender Signaturschlüssel, ein nicht vertrauenswürdiger Aussteller, eine falsche Peer-Kennung und eine abgelehnte Client-Autorisierung sehen vom Telefon aus alle wie ein toter Tunnel aus, und jede hat einen anderen Verantwortlichen. Alle fünf Einstellungen gleichzeitig zu ändern garantiert, dass Sie aus dem Ergebnis nichts lernen.
Halten Sie die präsentierte Identität, die erwartete Identität, Aussteller und Seriennummer des Zertifikats sowie den Namen der relevanten Richtlinie fest, und halten Sie private Schlüssel und Profilgeheimnisse aus dieser Aufzeichnung heraus. Wenn die Authentifizierung gelingt, testen Sie einen privaten Dienst und seine Antwort, denn Adresszuweisung, Selektoren, DNS und Zugriffsrichtlinie müssen nach dem IKE-Austausch weiterhin funktionieren.