iPhone IKEv2 papunta sa RouterOS: aling identifier ang napupunta saan
Apat na magkakahiwalay na pag-aangkin ang nagpapasya sa isang IKEv2 tunnel sa iOS: ang dinidial na address, ang inaasahang identidad ng server, ang ipinahahayag na identidad ng kliyente at ang materyal ng sertipiko.
Ang maabot ang gateway ng MikroTik ay nilulutas lamang ang kalahati ng transportasyon ng isang deployment ng IKEv2 at wala nang iba. Pagkatapos, apat na magkakahiwalay na pag-aangkin ang nagpapasya kung mabubuo ang tunel: ang address na dinidial ng telepono, ang identidad ng server na inaasahan nito, ang identidad na ipinapahayag nito para sa sarili nito, at ang materyal ng sertipiko na sumusuporta sa pag-aangking iyon. Suriin ang mga ito sa ganoong pagkakasunod-sunod, at huminto sa unang hindi tumutugma sa ipinapakita ng gateway. Bawat isa ay ine-edit sa ibang lugar, kaya't ang maling pag-edit ay karaniwang inililipat ang kabiguan sa halip na ayusin ito.
| 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 |
Suriin ang mga field ng profile sa pagkakasunod-sunod na ginagamit ng palitan
Ang malayong address ay ang destinasyon ng unang IKE packet at wala nang iba. Ang malayong identifier ay ang inaasahan ng telepono na patunayan ng gateway na siya, at ito ay pangalan, hindi ruta. Ang pagpuno sa dalawa ng parehong hostname ay gumagana kapag taglay ng sertipiko ng gateway ang pangalang iyon, at nabibigo sa paraang mukhang problema sa routing kapag hindi. Basahin ang profile bilang sunod-sunod na pag-aangkin, hindi bilang listahan ng mga field na pupunan.
Ang lokal na identifier ay ang sariling pag-aangkin ng telepono, at dapat itong pangalang tinatanggap ng entry ng identidad sa RouterOS para sa sertipiko ng kliyente na inihaharap ng telepono. Kung hindi magtugma ang dalawa, tinatanggihan ng gateway ang koneksyon matapos ma-validate ang sertipiko mismo, at ang log ay mukhang problema sa awtorisasyon, hindi sa pagpapangalan.
Suriin ang mga identifier laban sa ipinapakita ng gateway
Ang entry ng peer sa RouterOS na naka-configure para sa authentication ng sertipiko ay naghaharap ng sarili nitong sertipiko, at ang identidad nito ay hinango sa sertipikong iyon maliban kung nag-configure ka ng iba. Kung pinapangalanan ng malayong identifier ng telepono ang DNS name ng gateway, kailangan ng sertipiko ng gateway ang pangalang iyon sa lugar na tatanggapin ng telepono, karaniwang alternatibong pangalan ng subject. Ang sertipikong inisyu para sa ibang karaniwang pangalan ay hindi ma-validate kahit perpekto ang susi at ang chain.
Ang mga managed na profile ng Apple ay maaari ring magdala ng paghihigpit sa pangalan ng sertipiko na sinusuri bilang karagdagan sa mga field ng identifier. Suriin ang payload sa halip na hulaan ang pangalan ng validation mula sa ipinapakita ng screen ng mga setting, dahil hindi ito ang parehong setting.
Suriin na ang sertipiko ng kliyente ay susi, hindi lamang anchor ng pagtitiwala
Ang pag-import ng sertipiko ng CA ay nagbibigay sa telepono ng gamit upang ma-validate ang gateway. Hindi nito binibigyan ang telepono ng identidad ng kliyente, at ang authentication ng sertipiko ay nangangailangan ng leaf certificate ng kliyente at ang pribadong susi nito na inihatid nang magkasama sa pamamagitan ng aprubadong landas ng enrollment. Ang PKCS#12 na ginawa nang walang pribadong susi ay gumagawa ng profile na malinis na naka-install at walang naia-authenticate.
Ang leaf ng kliyente ay nangangailangan din ng identidad na inaasahan ng panig ng RouterOS, ibig sabihin ang subject o alternatibong pangalan ng subject ay dapat tumugma sa kaukulang configuration ng identidad. Ang pag-isyu ng mga sertipiko ng kliyente at server mula sa isang CA ay ginagawang maginhawa ang chain at hindi ginagawang mapagpapalit ang dalawang leaf.
Suriin na tinatanggap ng patakaran ng RouterOS ang pangalang iyon
Sa gateway, itinatakda ng entry ng peer ang mode ng palitan at ang paraan ng authentication, at ikinakabit ng entry ng identidad ang tinanggap na malayong identidad sa sertipiko at sa patakarang kasunod. Sa RouterOS v7 ang pares na iyon ay ipinapahayag sa pamamagitan ng mga entry ng peer at identidad ng IPsec, halimbawa isang peer ng IKEv2 na may auth-method=digital-signature. Suriin ang tunay na nilalaman ng menu sa naka-install na release, hindi isang gabay na isinulat para sa mas luma.
Dito rin pinakamurang ayusin ang hindi pagkakatugma, dahil masasabi ng gateway sa iyo ang identidad na natanggap at ang identidad na gusto nito. Ang pagpapalawak ng tinatanggap na identidad upang patahimikin ang error ay nag-aalis ng bigkis na nagbigay ng kahulugan sa deployment.
Suriin kung aling yugto ang nabigo bago mag-edit ng anuman
Basahin ang pagtatangka sa dalawang dulo at uriin ito bago baguhin ang isang panukala. Ang hindi pagkakatugma ng panukala, nawawalang susi ng lagda, hindi mapagkakatiwalaang issuer, maling identifier ng peer at tinanggihang awtorisasyon ng kliyente ay mukhang patay na tunel mula sa telepono, at bawat isa ay may ibang may-ari. Ang pagbabago sa lahat ng limang setting nang sabay ay nagtitiyak na wala kang matututuhan mula sa resulta.
Itala ang inihayag na identidad, ang inaasahang identidad, ang issuer at serial number ng sertipiko at ang pangalan ng kaugnay na patakaran, habang inilalayo ang mga pribadong susi at lihim ng profile sa talang iyon. Kapag nagtagumpay ang authentication, subukan ang isang pribadong serbisyo at ang sagot nito, dahil kailangan pa ring gumana ang pagtatalaga ng address, mga selector, DNS at patakaran ng pag-access matapos matapos ang palitan ng IKE.