IKEv2 pada Windows dan FortiGate: tiga tetapan yang orang gabungkan
Pertukaran kunci IKE, perlindungan CHILD SA dan pengesahan rakan sebaya ialah tiga baris berasingan. Nombor kumpulan yang sama dalam dua dialog tidak menggabungkannya.
Persetujuan IKEv2 antara klien Windows dan gateway FortiGate terus gagal, dan pencarian nombor yang tidak sepadan menghasilkan senarai nombor yang lebih panjang. Senarai itu hanya menjadi terurus apabila dipecahkan kepada tiga baris yang gagal secara bebas: pertukaran kunci yang melindungi IKE, perlindungan yang digunakan pada CHILD SA, dan pengesahan yang membuktikan siapa setiap pihak. Nombor kumpulan muncul dalam dua daripada baris itu dan membawa maksud berbeza.
Tiga baris yang gagal secara bebas
Baris pertama ialah pertukaran kunci di dalam IKE sendiri, yang menghasilkan kunci yang melindungi rundingan. Baris kedua ialah cadangan untuk CHILD SA, yang melindungi trafik yang dibawa oleh terowong. Baris ketiga ialah pengesahan, yang menentukan apa yang dikemukakan oleh setiap pihak dan bagaimana pihak lain mengesahkannya.
Kegagalan berlaku di tempat yang berbeza. Kegagalan pertukaran menghentikan rundingan sebelum ada terowong. Kegagalan CHILD SA berlaku selepas pengesahan berjaya, kadangkala hanya semasa pembaharuan kunci. Kegagalan pengesahan mungkin kelihatan seperti kegagalan pertukaran dalam log jika anda hanya membaca ralat pertama.
Mengasingkan baris bukan perakaunan. Ia mengubah tetapan mana yang wajar diubah, dan ia menghalang langkah paling mahal dalam seluruh bidang ini, iaitu menjana semula sijil yang berfungsi untuk membetulkan ketidakpadanan cadangan. Perubahan satu baris tidak sepatutnya memaksa dua yang lain berubah bersamanya. Kebebasan itulah seluruh tujuan menulisnya secara berasingan.
Apa yang dikawal oleh dua medan Windows
Windows menyimpan dua medan secara berasingan: DHGroup mengkonfigurasi pertukaran IKE itu sendiri, manakala PfsGroup mengkonfigurasi dasar IPsec yang melindungi trafik dalam terowong. Kedua-duanya tergolong dalam fasa yang berbeza. Membandingkan medan IKE Windows dengan nilai fasa 2 FortiGate menguji pasangan yang salah, dan nombornya mungkin sepadan sedangkan pertukaran di bawahnya masih gagal.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAPerintah kedua dan ketiga melaporkan persatuan keselamatan yang benar-benar wujud, dan itulah perkara paling hampir dengan jawapan yang boleh diberikan oleh klien kepada anda. Persatuan mod utama tanpa persatuan mod pantas ialah masalah CHILD SA, dan ia adalah tanda ketidakpadanan fasa 2 dan bukan masalah sijil.
Catat apa yang ditawarkan dan apa yang dipilih dalam satu percubaan. Senarai tawaran yang mengandungi cadangan boleh diterima dan cadangan dipilih yang tidak sepadan dengan dasar gateway ialah perselisihan konfigurasi, bukan misteri interoperabiliti.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Kumpulan lengkung eliptik tidak memilih kunci tandatangan anda
Kesimpulan salah yang paling berterusan dalam bidang ini ialah memilih kumpulan DH lengkung eliptik memerlukan sijil lengkung eliptik. Kumpulan DH membekalkan bahan pertukaran kunci; algoritma tandatangan dirundingkan oleh rangka pengesahan, dan kedua-duanya ialah keputusan berasingan dalam IKEv2.
RFC 7427 wujud kerana keputusan itu dahulunya terjalin, dan ia mentakrifkan bagaimana algoritma tandatangan diumumkan dan dipilih secara bebas daripada pertukaran kunci. Gateway boleh menyokong kumpulan lengkung dan pilihan skema tandatangan pada masa yang sama.
Jadi apabila rundingan gagal selepas perubahan kumpulan, lihat kaedah pengesahan sebelum melihat jenis kunci sijil. Menukar sijil ialah operasi yang lambat dan berisiko yang jarang menjadi jawapannya, dan melakukannya dahulu memusnahkan keupayaan anda untuk mengetahui perubahan mana yang benar-benar membantu. Baca baris pengesahan sebelum menyentuh stor sijil.
Simpan kedua-duanya dalam baris berasingan pada helaian persetujuan dan kesilapan itu berhenti menggoda. Satu baris menyenaraikan kumpulan, yang lain menyenaraikan skema tandatangan dan identiti, dan tidak satu pun menjadi bukti tentang yang lain.
Letakkan setiap kunci peribadi bersama pemilik sebenarnya
Gateway yang mengemukakan sijilnya sendiri memerlukan kunci peribadi yang sepadan dengannya. Rakan sebaya yang mengesahkan rantai memerlukan sijil CA, dan secara khusus tidak memerlukan kunci tandatangan CA. Mengelirukan ketiga-tiga artifak itu ialah cara orang akhirnya mengimport kunci peribadi CA ke dalam peranti VPN untuk membuat sijil muncul dalam kategori lain.
Pada FortiOS peranannya berbeza: sijil tempatan dengan kuncinya, sijil jauh yang digunakan untuk mengenal pasti rakan sebaya, dan entri CA jauh yang menetapkan kepercayaan pada sijil yang ditandatangani oleh CA itu. Entri CA jauh tanpa kunci peribadi tidaklah lengkap; ia betul untuk tujuannya.
Kunci tandatangan CA yang diimport meluaskan kuasa sesiapa yang boleh membaca peranti itu. Ia juga tidak menyelesaikan pengesahan rakan sebaya biasa, kerana pengesahan memerlukan sijil awam dan keputusan kepercayaan, bukan keupayaan mengeluarkan sijil baharu.
Simpan kunci tandatangan CA pada proses pengeluar itu sendiri, dan catat peranti mana memegang kunci mana. Jadual pemilik yang pendek lebih bernilai daripada jadual algoritma yang lebih panjang apabila audit bertanya siapa boleh menyamar sebagai siapa. Tiada siapa mengimport kunci yang diketahuinya hanya untuk inventori. Tulis inventori sebelum insiden, bukan selepasnya.