iPhone IKEv2 nei RouterOS: hokker identifikator heart wêr
Fjouwer aparte bewearings bepale in IKEv2-tunnel op iOS: it keazen adres, de ferwachte tsjinnersidentiteit, de bewearde kliïntidentiteit en it sertifikaatmateriaal.
It berikken fan de MikroTik-poarte lost allinnich de ferfiershelte fan in IKEv2-ynset op en neat oars. Dêrnei bepale fjouwer aparte bewearings oft de tunnel foarmet: it adres dat de telefoan kiest, de tsjinnersidentiteit dy't er ferwachtet, de identiteit dy't er foar himsels beweart, en it sertifikaatmateriaal dat dy bewearing stipet. Kontrolearje se yn dy folchoarder en stop by de earste dy't net oerienkomt mei wat de poarte presintearret. Elk wurdt op in oar plak bewurke, dêrom ferpleatst in ferkearde bewurking meast de flater ynstee fan him te reparearjen.
| 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 |
Kontrolearje de profylfjilden yn 'e folchoarder dy't de útwikseling se brûkt
It fiere adres is de bestimming fan it earste IKE-pakket en neat mear. De fiere identifikator is wat de telefoan ferwachtet dat de poarte bewiist te wêzen, en it is in namme, gjin rûte. Beide folje mei deselde hostnamme wurket as it sertifikaat fan de poarte dy namme draacht, en mislearret op in wize dy't as in routingprobleem liket as dat net sa is. Lês it profyl as in rige bewearings, net as in list fan fjilden om te foljen.
De lokale identifikator is de eigen bewearing fan 'e telefoan, en it moat in namme wêze dy't de RouterOS-identiteitsynfier akseptearret foar it kliïntsertifikaat dat de telefoan presintearret. As de twa net oerienkomme, wegeret de poarte de ferbining nei't it sertifikaat sels falidearre is, en it log liket op in autorisaasjeprobleem ynstee fan in nammeprobleem.
Kontrolearje de identifikators tsjin wat de poarte presintearret
In RouterOS-peer-ynfier ynsteld foar sertifikaatautentikaasje presintearret syn eigen sertifikaat, en syn identiteit komt út dat sertifikaat, útsein as jo oars ynsteld hawwe. As de fiere identifikator fan 'e telefoan de DNS-namme fan 'e poarte neamt, hat it sertifikaat fan 'e poarte dy namme nedich op in plak dat de telefoan akseptearret, meastentiids in alternatyve subjektnamme. In sertifikaat útjûn foar in oare miene namme sil net falidearje, ek al binne de kaai en de keten perfekt.
Behearde Apple-profylen kinne ek in sertifikaatnammebeheining drage dy't neist de identifikatorfjilden beoardiele wurdt. Undersykje de lading ynstee fan de falidaasjenamme ôf te lieden út wat it ynstellingsskerm toant, want de twa binne net deselde ynstelling.
Kontrolearje dat it kliïntsertifikaat in kaai is, net allinnich in fertrouwensanker
It ymportearjen fan in CA-sertifikaat jout de telefoan wat om de poarte mei te falidearjen. It jout de telefoan gjin kliïntidentiteit, en sertifikaatautentikaasje hat it kliïntblêdsertifikaat en syn partikuliere kaai nedich, tegearre levere fia it goedkarde registraasjepaad. In PKCS#12 boud sûnder de partikuliere kaai produsearret in profyl dat skjin ynstallearret en neat autentisearret.
It kliïntblêd hat ek in identiteit nedich dy't de RouterOS-kant ferwachtet, wat betsjut dat it subjekt of de alternatyve subjektnamme oerienkomme moat mei de oerienkommende identiteitskonfiguraasje. Kliïnt- en tsjinnersertifikaten út ien CA útjaan makket de keten handich en makket de twa blêden net útwikselber.
Kontrolearje dat it RouterOS-belied dy namme akseptearret
Op de poarte set de peer-ynfier de útwikselmodus en de autentikaasjemetoade fêst, en de identiteitsynfier bynt de akseptearre fiere identiteit oan in sertifikaat en oan it belied dat dêrop folget. Yn RouterOS v7 wurdt dat pear útdrukt fia de IPsec-peer- en identiteitsynfier, bygelyks in IKEv2-peer mei auth-method=digital-signature. Kontrolearje de werklike menu-ynhâld fan jo ynstalleare ferzje, net in gids skreaun foar in âldere.
Hjir is in mismatching ek it goedkeapst te reparearjen, want de poarte kin jo sawol de identiteit fertelle dy't er ûntfong as dy't er woe. It akseptearre identiteit ferbreedzje om de flater stil te meitsjen ferwideret de bining dy't de ynset betsjutting joech.
Kontrolearje hokker stadium mislearre is foardat jo eat bewurkje
Lês de poging oan beide einen en klassifisearje him foardat jo in foarstel feroarje. In foarstel-mismatching, in ûntbrekkende ûndertekenkaai, in net fertroude útjouwer, in ferkearde peer-identifikator en in wegere kliïntautorisaasje lykje allegear fan 'e telefoan ôf op in deade tunnel, en elk hat in oare eigner. Alle fiif ynstellingen tagelyk feroarje garandearret dat jo neat fan it resultaat leare.
Skriuw de presintearre identiteit, de ferwachte identiteit, de útjouwer en it searjenûmer fan it sertifikaat en de namme fan it oanbelangjende belied op, en hâld partikuliere kaaien en profylgeheimen bûten dat rekord. As de autentikaasje slagget, test dan in partikuliere tsjinst en syn antwurd, want adrestawizing, selektors, DNS en tagongsbelied moatte noch wurkje neidat de IKE-útwikseling klear is.