Bagaimana autentikasi hibrida IKEv1 beralih ke autentikasi pengguna IKEv2

Setiap profil VPN lama yang meminta sertifikat server lalu nama pengguna membawa dua peristiwa autentikasi dalam satu pertukaran, dan bentuk itu bertahan lebih lama daripada protokol yang memperkenalkannya. Mode hibrida IKEv1 dibuat persis untuk ini: gateway membuktikan dirinya dengan kunci publik sementara pengguna membuktikan dirinya kemudian melalui XAuth. IKEv2 menyatakan gagasan dua langkah yang sama dengan mekanisme berbeda, dan pada perbedaan itulah migrasi gagal. Tidak ada nomor versi yang mengubah yang satu menjadi yang lain, dan menyalin nama opsi lama ke profil baru menghasilkan klien yang bernegosiasi lalu tidak mengautentikasi apa pun.

Apa yang dilakukan mode hibrida di dalam IKEv1

Dalam profil hibrida, pihak penjawab menandatangani pertukaran fase satu dengan sertifikatnya sementara pemrakarsa sengaja tidak menyajikan sertifikat apa pun. Bukti identitas karena itu asimetris, dan itulah yang memungkinkan gateway mempertahankan PKI yang ada sementara pengguna mempertahankan kata sandi direktori mereka. Setelah fase satu selesai, XAuth berjalan sebagai permintaan dan jawaban yang membawa atribut nama pengguna dan kata sandi di dalam kanal ISAKMP yang kini terenkripsi.

Perhatikan ke mana kepercayaan itu mendarat. Sertifikat menjawab gateway mana yang dicapai klien; XAuth menjawab pengguna mana yang ingin akses. Tidak ada yang menggantikan yang lain, dan klien yang disetel menerima sertifikat server apa pun telah diam-diam membuang jawaban pertama. Label hibrida juga dipakai untuk mode agresif dengan kunci yang dibagi sebelumnya plus XAuth, susunan lain dengan pengalaman pengguna yang sama, jadi bacalah profilnya dan bukan namanya. Kedua varian berasal dari draf yang tidak pernah menjadi standar, dan karena itu dua vendor dapat mengimplementasikan mode hibrida dan tidak berinteroperasi dengan siapa pun.

Bagaimana IKEv2 mencapai dua bukti yang sama

IKEv2 membagi pekerjaan antara IKE_SA_INIT dan IKE_AUTH. Pertukaran pertama menyepakati usulan dan kunci tanpa identitas apa pun; yang kedua membawa IDi, IDr, dan muatan AUTH. Di bawah EAP, muatan AUTH pertama pemrakarsa keluar kosong, penjawab mengautentikasi dirinya lebih dulu dengan sertifikat dan tanda tangannya, lalu percakapan EAP berjalan di dalam pesan IKE_AUTH.

Mekanisme yang membuat ini aman adalah materi kunci. Metode EAP yang berhasil mengekspor kunci sesi, dan muatan AUTH terakhir pemrakarsa dihitung darinya, sehingga bukti pengguna dan kunci terowongan terikat bersama. XAuth tidak punya padanan: atributnya tiba setelah fase satu dan tidak menyumbang apa pun pada kunci. Celah itulah yang dirancang ditutup oleh kerangka IKEv2, dan karena itu login IKEv2 yang berfungsi memvalidasi sertifikat server sebelum meminta apa pun.

Urutan ini juga diagnostik yang berguna. Ketika klien mengeluh soal kredensial sebelum menunjukkan sertifikat kepada Anda, ia sama sekali tidak melakukan pertukaran EAP IKEv2.

Jaga tiga identitas tetap terpisah

Migrasi menjadi salah ketika tiga identitas runtuh ke satu bidang. Ada identitas gateway yang divalidasi klien, biasanya nama DNS di subject atau SAN sertifikat. Ada identitas pengguna yang disajikan dalam EAP, mungkin login domain, alamat, atau string identitas EAP eksplisit. Dan ada sumber otorisasi yang memetakan pengguna itu ke jaringan dan rute.

Sintaks swanctl strongSwan membuat pemisahan itu terlihat: koneksi menetapkan remote { auth = pubkey } untuk gateway dan local { auth = eap-mschapv2 } untuk pengguna, dengan identitas EAP dibawa terpisah.

Ketika identitas pengguna di profil baru berbeda dari atribut XAuth lama, misalnya UPN alih-alih nama pendek, server autentikasi melihat pengguna tak dikenal dan kegagalannya tampak seperti kata sandi salah. Periksa string identitas sebelum memeriksa kredensial.

Petakan opsi lalu perkirakan jebakannya

Pemetaannya singkat dan setiap baris punya jebakan yang hanya muncul saat autentikasi.

Tidak ada baris yang sekadar berganti nama. Muatan konfigurasi mengirimkan alamat dan resolver melalui daftar atribut bertipe, sementara ruang atribut XAuth adalah penemuannya sendiri; memperlakukannya sebagai dapat dipertukarkan adalah cara sebuah profil akhirnya meminta pengaturan yang tidak akan pernah dikirim gateway.

Pemilih lalu lintas pantas mendapat peringatan sendiri. IKEv1 menyatakan lalu lintas menarik melalui ID proxy yang terikat pada pertukaran quick mode, sedangkan IKEv2 menegosiasikan pemilih selama IKE_AUTH dan penjawab dapat mempersempitnya. Ketidakcocokan menghasilkan IKE SA yang terbentuk tanpa child SA, yang beberapa klien dengan senang menampilkannya sebagai tersambung.

Perlakukan koneksi lama sebagai batas

RFC 9395 menyatakan IKEv1 usang, jadi koneksi hibrida lama adalah batas kompatibilitas bertanggal, bukan fondasi. Jalankan kedua profil berdampingan selama perubahan, karena ujian yang penting bukan apakah profil baru menyala, melainkan apakah pengguna yang sama pada perangkat yang sama mencapai sumber daya yang sama.

Pertahankan validasi sertifikat tetap ketat sepanjang jalan. Begitu klien berhenti menyajikan sertifikatnya sendiri, godaan muncul untuk melonggarkan pemeriksaan server sampai jabat tangan selesai, dan itu menukar satu-satunya bukti yang tersisa dengan ikon hijau.

Tuliskan empat hal sebelum memensiunkan profil lama: metode EAP, string identitas, sumber otorisasi, dan tanggal dukungan berakhir.