iPhone IKEv2 al RouterOS: kiu identigilo iras kien
Kvar apartaj asertoj decidas pri IKEv2-tunelo en iOS: la vokata adreso, la atendata servila identeco, la asertata klienta identeco kaj la atestila materialo.
Aliĝi al la MikroTik-pordego solvas nur la transportan duonon de IKEv2-implementado kaj nenion alian. Poste kvar apartaj asertoj decidas, ĉu la tunelo formiĝos: la adreso, kiun la telefono vokas, la servila identeco, kiun ĝi atendas, la identeco, kiun ĝi asertas por si, kaj la atestila materialo, kiu subtenas tiun aserton. Kontrolu ilin en tiu ordo kaj haltu ĉe la unua, kiu ne kongruas kun tio, kion la pordego prezentas. Ĉiu estas redaktebla en alia loko, tial malĝusta redakto kutime movas la fuŝon anstataŭ ripari ĝin.
| 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 |
Kontrolu la profilajn kampojn en la ordo, kiun la interŝanĝo uzas
La fora adreso estas la celo de la unua IKE-paketo kaj nenio pli. La fora identigilo estas tio, kion la telefono atendas, ke la pordego pruvu esti, kaj ĝi estas nomo, ne itinero. Plenigi ambaŭ per la sama gastigantnomo funkcias, kiam la atestilo de la pordego portas tiun nomon, kaj malsukcesas tiel, ke ĝi aspektas kiel itinera problemo, kiam ĝi ne portas ĝin. Legu la profilon kiel sinsekvon de asertoj, ne kiel liston da kampoj plenigendaj.
La loka identigilo estas la propra aserto de la telefono, kaj ĝi devas esti nomo, kiun la identeca rikordo de RouterOS akceptas por la klienta atestilo, kiun la telefono prezentas. Se la du malkongruas, la pordego rifuzas la konekton post kiam la atestilo mem validiĝis, kaj la protokolo aspektas kiel permesa problemo, ne nomiga.
Kontrolu la identigilojn kontraŭ tio, kion la pordego prezentas
RouterOS-kunula rikordo agordita por atestila aŭtentikigo prezentas sian propran atestilon, kaj ĝia identeco venas el tiu atestilo, se vi ne agordis alie. Se la fora identigilo de la telefono nomas la DNS-nomon de la pordego, la atestilo de la pordego bezonas tiun nomon en loko, kiun la telefono akceptos, kutime alternativa subjekta nomo. Atestilo eldonita por alia komuna nomo malsukcesos validiĝi eĉ se la ŝlosilo kaj la ĉeno estas perfektaj.
Administrataj Apple-profiloj ankaŭ povas porti atestilan nomlimigon, kiu estas taksata aldoniĝe al la identigaj kampoj. Ekzamenu la ŝarĝon anstataŭ dedukti la validigan nomon el tio, kion montras la agorda ekrano, ĉar la du ne estas la sama agordo.
Kontrolu, ke la klienta atestilo estas ŝlosilo, ne nur fido-ankro
Importi CA-atestilon donas al la telefono ion, per kio ĝi povas validigi la pordegon. Ĝi ne donas al la telefono klientan identecon, kaj atestila aŭtentikigo bezonas la klientan finan atestilon kaj ĝian privatan ŝlosilon liveritajn kune tra la aprobita aliĝa vojo. PKCS#12 konstruita sen la privata ŝlosilo produktas profilon, kiu instaliĝas pure kaj aŭtentikigas nenion.
La klienta fina atestilo ankaŭ bezonas identecon, kiun la RouterOS-flanko atendas, do la subjekto aŭ alternativa subjekta nomo devas kongrui kun la responda identeca agordo. Eldoni klientajn kaj servilajn atestilojn el unu CA faras la ĉenon oportuna kaj ne faras la du finajn atestilojn interŝanĝeblaj.
Kontrolu, ke la RouterOS-politiko akceptas tiun nomon
Sur la pordego la kunula rikordo fiksas la interŝanĝan reĝimon kaj la aŭtentikigan metodon, kaj la identeca rikordo ligas la akceptitan foran identecon al atestilo kaj al la sekva politiko. En RouterOS v7 tiu paro esprimiĝas per la IPsec-kunulaj kaj identecaj rikordoj, ekzemple kunulo IKEv2 kun auth-method=digital-signature. Kontrolu la faktan menuenhavon de via instalita eldono anstataŭ gvidilon verkitan por pli malnova.
Ĉi tie ankaŭ malkongruo estas plej malmultekoste riparebla, ĉar la pordego povas diri al vi kaj la identecon, kiun ĝi ricevis, kaj tiun, kiun ĝi volis. Larĝigi la akceptitan identecon por silentigi la eraron forigas la ligon, kiu donis sencon al la implementado.
Kontrolu, kiu etapo malsukcesis, antaŭ ol redakti ion ajn
Legu la provon ĉe ambaŭ finoj kaj klasifiku ĝin antaŭ ol ŝanĝi proponon. Propona malkongruo, mankanta subskriba ŝlosilo, nefidinda eldoninto, malĝusta kunula identigilo kaj rifuzita klienta permeso ĉiuj aspektas kiel morta tunelo el la telefono, kaj ĉiu havas alian posedanton. Ŝanĝi ĉiujn kvin agordojn samtempe garantias, ke vi lernos nenion el la rezulto.
Registru la prezentitan identecon, la atendantan identecon, la eldoninton kaj serian numeron de la atestilo kaj la nomon de la koncerna politiko, tenante privatajn ŝlosilojn kaj profilajn sekretojn ekster tiu registro. Kiam la aŭtentikigo sukcesos, testu privatan servon kaj ĝian respondon, ĉar adres-asignado, selektiloj, DNS kaj alirpolitiko ankoraŭ devas funkcii post la fino de la IKE-interŝanĝo.