iPhone IKEv2 ke RouterOS: pengenal mana pergi ke mana
Empat dakwaan berasingan menentukan terowong IKEv2 pada iOS: alamat yang didail, identiti pelayan yang dijangka, identiti klien yang didakwa dan bahan sijil.
Mencapai gateway MikroTik hanya menyelesaikan separuh pengangkutan sesuatu penggunaan IKEv2 dan tiada yang lain. Selepas itu, empat dakwaan berasingan menentukan sama ada terowong terbentuk: alamat yang didail telefon, identiti pelayan yang dijangka, identiti yang didakwa untuk dirinya sendiri, dan bahan sijil yang menyokong dakwaan itu. Semak semuanya dalam urutan itu, dan berhenti pada yang pertama yang tidak sepadan dengan apa yang dibentangkan oleh gateway. Setiap satu disunting di tempat berbeza, sebab itu suntingan yang salah biasanya memindahkan kegagalan dan bukannya membaikinya.
| 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 |
Semak medan profil mengikut urutan yang digunakan oleh pertukaran
Alamat jauh ialah destinasi paket IKE pertama dan tiada yang lebih. Pengenal jauh ialah apa yang telefon jangkakan gateway buktikan dirinya, dan ia ialah nama, bukan laluan. Mengisi kedua-duanya dengan nama hos yang sama berfungsi apabila sijil gateway membawa nama itu, dan gagal dengan cara yang kelihatan seperti masalah penghalaan apabila ia tidak membawanya. Baca profil sebagai urutan dakwaan, bukan senarai medan untuk diisi.
Pengenal setempat ialah dakwaan telefon sendiri, dan ia mesti nama yang diterima oleh entri identiti RouterOS untuk sijil klien yang dibentangkan telefon. Jika kedua-duanya tidak sepadan, gateway menolak sambungan selepas sijil itu sendiri disahkan, dan log kelihatan seperti masalah kebenaran, bukan penamaan.
Semak pengenal terhadap apa yang dibentangkan oleh gateway
Entri rakan RouterOS yang dikonfigurasikan untuk pengesahan sijil membentangkan sijilnya sendiri, dan identitinya diambil daripada sijil itu melainkan anda mengkonfigurasi sebaliknya. Jika pengenal jauh telefon menyebut nama DNS gateway, sijil gateway memerlukan nama itu di tempat yang akan diterima telefon, biasanya nama alternatif subjek. Sijil yang dikeluarkan untuk nama umum lain tidak akan disahkan walaupun kunci dan rantaian sempurna.
Profil Apple terurus juga boleh membawa kekangan nama sijil yang dinilai selain medan pengenal. Periksa muatan dan bukannya menyimpulkan nama pengesahan daripada apa yang dipaparkan skrin tetapan, kerana kedua-duanya bukan tetapan yang sama.
Semak bahawa sijil klien ialah kunci, bukan sekadar sauh kepercayaan
Mengimport sijil CA memberi telefon sesuatu untuk mengesahkan gateway. Ia tidak memberi telefon identiti klien, dan pengesahan sijil memerlukan sijil daun klien dan kunci peribadinya dihantar bersama melalui laluan pendaftaran yang diluluskan. PKCS#12 yang dibina tanpa kunci peribadi menghasilkan profil yang dipasang dengan bersih dan tidak mengesahkan apa-apa.
Daun klien juga memerlukan identiti yang dijangka oleh pihak RouterOS, bermakna subjek atau nama alternatif subjek mesti selari dengan konfigurasi identiti yang sepadan. Mengeluarkan sijil klien dan pelayan daripada satu CA menjadikan rantaian mudah dan tidak menjadikan kedua-dua daun boleh ditukar ganti.
Semak bahawa dasar RouterOS menerima nama itu
Di gateway, entri rakan menetapkan mod pertukaran dan kaedah pengesahan, dan entri identiti mengikat identiti jauh yang diterima kepada sijil dan kepada dasar yang menyusul. Dalam RouterOS v7 pasangan itu dinyatakan melalui entri rakan dan identiti IPsec, contohnya rakan IKEv2 dengan auth-method=digital-signature. Semak kandungan menu sebenar pada keluaran yang dipasang, bukan panduan yang ditulis untuk versi lama.
Di sinilah juga ketidakpadanan paling murah diperbaiki, kerana gateway boleh memberitahu anda identiti yang diterima dan yang dikehendaki. Meluaskan identiti yang diterima untuk mendiamkan ralat menghapuskan ikatan yang memberi makna kepada penggunaan itu.
Semak peringkat mana yang gagal sebelum menyunting apa-apa
Baca percubaan di kedua-dua hujung dan klasifikasikannya sebelum menukar cadangan. Ketidakpadanan cadangan, kunci tandatangan yang hilang, pengeluar yang tidak dipercayai, pengenal rakan yang salah dan kebenaran klien yang ditolak semuanya kelihatan seperti terowong mati dari telefon, dan setiap satu mempunyai pemilik berbeza. Menukar kelima-lima tetapan sekali gus menjamin anda tidak belajar apa-apa daripada hasilnya.
Catat identiti yang dibentangkan, identiti yang dijangka, pengeluar dan nombor siri sijil serta nama dasar yang berkaitan, sambil menyimpan kunci peribadi dan rahsia profil di luar catatan itu. Setelah pengesahan berjaya, uji perkhidmatan persendirian dan balasannya, kerana peruntukan alamat, pemilih, DNS dan dasar akses masih perlu berfungsi selepas pertukaran IKE selesai.