IKEv2 di Windows dan FortiGate: tiga pengaturan yang orang gabungkan
Pertukaran kunci IKE, perlindungan CHILD SA, dan autentikasi peer adalah tiga baris terpisah. Nomor grup yang sama di dua dialog tidak menggabungkannya.
Kesepakatan IKEv2 antara klien Windows dan gateway FortiGate terus gagal, dan pencarian nomor yang tidak cocok menghasilkan daftar nomor yang lebih panjang. Daftar itu baru bisa dikelola ketika dipecah menjadi tiga baris yang gagal secara independen: pertukaran kunci yang melindungi IKE, perlindungan yang diterapkan pada CHILD SA, dan autentikasi yang membuktikan siapa setiap pihak. Nomor grup muncul di dua dari baris tersebut dan berarti hal yang berbeda.
Tiga baris yang gagal secara independen
Baris pertama adalah pertukaran kunci di dalam IKE itu sendiri, yang menghasilkan kunci yang melindungi negosiasi. Baris kedua adalah proposal untuk CHILD SA, yang melindungi lalu lintas yang dibawa terowongan. Baris ketiga adalah autentikasi, yang memutuskan apa yang disajikan setiap pihak dan bagaimana pihak lain memvalidasinya.
Kegagalan terjadi di tempat yang berbeda. Kegagalan pertukaran menghentikan negosiasi sebelum ada terowongan. Kegagalan CHILD SA terjadi setelah autentikasi berhasil, kadang hanya saat pembaruan kunci. Kegagalan autentikasi bisa terlihat seperti kegagalan pertukaran di log jika Anda hanya membaca kesalahan pertama.
Memisahkan baris bukanlah pembukuan. Ini mengubah pengaturan mana yang layak diubah, dan mencegah langkah termahal di seluruh bidang ini, yaitu membuat ulang sertifikat yang berfungsi untuk memperbaiki ketidakcocokan proposal. Perubahan satu baris tidak boleh memaksa dua baris lainnya ikut berubah. Kemandirian itulah seluruh alasan menulisnya terpisah.
Apa yang dikendalikan dua bidang Windows
Windows memisahkan dua bidang: DHGroup mengonfigurasi pertukaran IKE itu sendiri, sedangkan PfsGroup mengonfigurasi kebijakan IPsec yang melindungi lalu lintas di terowongan. Keduanya milik fase yang berbeda. Membandingkan bidang IKE Windows dengan nilai fase 2 FortiGate menguji pasangan yang salah, dan nomornya bisa cocok sementara pertukaran yang mendasarinya tetap gagal.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAPerintah kedua dan ketiga melaporkan asosiasi keamanan yang benar-benar ada, dan itu adalah hal terdekat dengan jawaban yang bisa diberikan klien kepada Anda. Asosiasi mode utama tanpa asosiasi mode cepat adalah masalah CHILD SA, dan itu adalah tanda ketidakcocokan fase 2, bukan masalah sertifikat.
Catat apa yang ditawarkan dan apa yang dipilih dalam satu percobaan. Daftar yang ditawarkan berisi proposal yang dapat diterima dan proposal yang dipilih tidak cocok dengan kebijakan gateway adalah perselisihan konfigurasi, bukan misteri interoperabilitas.
| 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 |
Grup kurva eliptik tidak memilih kunci tanda tangan Anda
Kesimpulan keliru yang paling bertahan di bidang ini adalah bahwa memilih grup DH kurva eliptik memerlukan sertifikat kurva eliptik. Grup DH menyediakan materi pertukaran kunci; algoritme tanda tangan dinegosiasikan oleh kerangka autentikasi, dan keduanya adalah keputusan terpisah di IKEv2.
RFC 7427 ada justru karena keputusan itu sebelumnya terjalin, dan mendefinisikan bagaimana algoritme tanda tangan diumumkan dan dipilih secara independen dari pertukaran kunci. Gateway dapat mendukung grup kurva dan pilihan skema tanda tangan pada saat yang sama.
Jadi ketika negosiasi gagal setelah perubahan grup, lihat metode autentikasi sebelum melihat jenis kunci sertifikat. Mengganti sertifikat adalah operasi lambat dan berisiko yang jarang menjadi jawabannya, dan melakukannya lebih dulu menghancurkan kemampuan Anda untuk mengetahui perubahan mana yang benar-benar membantu. Baca baris autentikasi sebelum menyentuh penyimpanan sertifikat.
Simpan keduanya di baris terpisah pada lembar kesepakatan dan kesalahan itu berhenti menggoda. Satu baris mencantumkan grup, yang lain mencantumkan skema tanda tangan dan identitas, dan tidak satu pun menjadi bukti tentang yang lain.
Tempatkan setiap kunci privat bersama pemilik sebenarnya
Gateway yang menyajikan sertifikatnya sendiri memerlukan kunci privat yang cocok dengannya. Peer yang memvalidasi rantai memerlukan sertifikat CA, dan secara khusus tidak memerlukan kunci tanda tangan CA. Mencampur ketiga artefak itu adalah cara orang berakhir mengimpor kunci privat CA ke perangkat VPN agar sertifikat muncul di kategori lain.
Di FortiOS perannya berbeda: sertifikat lokal dengan kuncinya, sertifikat jarak jauh yang digunakan untuk mengidentifikasi peer, dan entri CA jarak jauh yang membangun kepercayaan pada sertifikat yang ditandatangani CA tersebut. Entri CA jarak jauh tanpa kunci privat tidaklah tidak lengkap; itu benar untuk tujuannya.
Kunci tanda tangan CA yang diimpor memperluas wewenang siapa pun yang dapat membaca perangkat itu. Kunci itu juga tidak menyelesaikan validasi peer biasa, karena validasi membutuhkan sertifikat publik dan keputusan kepercayaan, bukan kemampuan menerbitkan sertifikat baru.
Simpan kunci tanda tangan CA pada proses penerbit itu sendiri, dan catat perangkat mana memegang kunci mana. Tabel pemilik yang singkat lebih bernilai daripada tabel algoritme yang lebih panjang ketika audit bertanya siapa yang bisa menyamar sebagai siapa. Tidak ada yang mengimpor kunci yang diketahui hanya untuk inventaris. Tulis inventaris sebelum insiden, bukan sesudahnya.