iPhone IKEv2 ke RouterOS: pengenal mana ke mana
Empat klaim terpisah menentukan terowongan IKEv2 di iOS: alamat yang dipanggil, identitas server yang diharapkan, identitas klien yang diklaim, dan materi sertifikat.
Mencapai gateway MikroTik hanya menyelesaikan separuh transport dari penerapan IKEv2 dan tidak lebih. Setelah itu, empat klaim terpisah menentukan apakah terowongan terbentuk: alamat yang dipanggil ponsel, identitas server yang diharapkannya, identitas yang diklaimnya untuk dirinya sendiri, dan materi sertifikat yang menopang klaim itu. Periksa semuanya dalam urutan itu, dan berhenti pada yang pertama yang tidak cocok dengan apa yang disajikan gateway. Masing-masing diedit di tempat berbeda, karena itu suntingan yang salah biasanya memindahkan kegagalan alih-alih memperbaikinya.
| 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 |
Periksa bidang profil dalam urutan yang digunakan pertukaran
Alamat jarak jauh adalah tujuan paket IKE pertama dan tidak lebih. Pengenal jarak jauh adalah apa yang diharapkan ponsel dibuktikan gateway tentang dirinya, dan itu nama, bukan rute. Mengisi keduanya dengan nama host yang sama berfungsi bila sertifikat gateway memuat nama itu, dan gagal dengan cara yang tampak seperti masalah perutean bila tidak. Bacalah profil sebagai rangkaian klaim, bukan daftar bidang yang harus diisi.
Pengenal lokal adalah klaim ponsel itu sendiri, dan harus berupa nama yang diterima entri identitas RouterOS untuk sertifikat klien yang disajikan ponsel. Jika keduanya tidak cocok, gateway menolak koneksi setelah sertifikat itu sendiri tervalidasi, dan log tampak seperti masalah otorisasi, bukan penamaan.
Periksa pengenal terhadap apa yang disajikan gateway
Entri peer RouterOS yang dikonfigurasi untuk autentikasi sertifikat menyajikan sertifikatnya sendiri, dan identitasnya diambil dari sertifikat itu kecuali Anda mengonfigurasi sebaliknya. Jika pengenal jarak jauh ponsel menyebut nama DNS gateway, sertifikat gateway memerlukan nama itu di tempat yang akan diterima ponsel, biasanya nama alternatif subjek. Sertifikat yang diterbitkan untuk nama umum lain tidak akan tervalidasi meskipun kunci dan rantainya sempurna.
Profil Apple terkelola juga dapat memuat batasan nama sertifikat yang dievaluasi selain bidang pengenal. Periksa muatannya alih-alih menyimpulkan nama validasi dari apa yang ditampilkan layar pengaturan, karena keduanya bukan pengaturan yang sama.
Periksa bahwa sertifikat klien adalah kunci, bukan sekadar jangkar kepercayaan
Mengimpor sertifikat CA memberi ponsel sesuatu untuk memvalidasi gateway. Itu tidak memberi ponsel identitas klien, dan autentikasi sertifikat memerlukan sertifikat daun klien dan kunci privatnya dikirim bersama melalui jalur pendaftaran yang disetujui. PKCS#12 yang dibuat tanpa kunci privat menghasilkan profil yang terpasang bersih dan tidak mengautentikasi apa pun.
Daun klien juga memerlukan identitas yang diharapkan sisi RouterOS, artinya subjek atau nama alternatif subjek harus sejajar dengan konfigurasi identitas yang sesuai. Menerbitkan sertifikat klien dan server dari satu CA membuat rantai nyaman dan tidak membuat kedua daun saling dapat ditukar.
Periksa bahwa kebijakan RouterOS menerima nama itu
Di gateway, entri peer menetapkan mode pertukaran dan metode autentikasi, dan entri identitas mengikat identitas jarak jauh yang diterima ke sertifikat dan ke kebijakan yang menyusul. Di RouterOS v7 pasangan itu dinyatakan melalui entri peer dan identitas IPsec, misalnya peer IKEv2 dengan auth-method=digital-signature. Periksa isi menu yang sebenarnya pada rilis terpasang Anda, bukan panduan yang ditulis untuk rilis lama.
Di sini juga ketidakcocokan paling murah diperbaiki, karena gateway dapat memberi tahu Anda identitas yang diterima maupun yang diinginkan. Memperlebar identitas yang diterima untuk membungkam galat menghapus ikatan yang membuat penerapan itu bermakna.
Periksa tahap mana yang gagal sebelum menyunting apa pun
Baca upaya di kedua ujung dan klasifikasikan sebelum mengubah proposal. Ketidakcocokan proposal, kunci penandatanganan yang hilang, penerbit yang tidak tepercaya, pengenal peer yang salah, dan otorisasi klien yang ditolak semuanya tampak seperti terowongan mati dari ponsel, dan masing-masing punya pemilik berbeda. Mengubah kelima pengaturan sekaligus menjamin Anda tidak belajar apa pun dari hasilnya.
Catat identitas yang disajikan, identitas yang diharapkan, penerbit dan nomor seri sertifikat, serta nama kebijakan yang relevan, sambil menjaga kunci privat dan rahasia profil di luar catatan itu. Setelah autentikasi berhasil, uji layanan privat dan balasannya, karena penetapan alamat, selektor, DNS, dan kebijakan akses tetap harus bekerja setelah pertukaran IKE selesai.