IKEv2 alamat server vs identitas: apa yang sebenarnya diperiksa oleh klien

Gerbang yang mengubah alamat dapat tetap berfungsi sementara gerbang yang sama di belakang sertifikat baru berhenti, dan hal sebaliknya juga terjadi. Alamat tersebut memberitahu klien ke mana harus mengirim paket; identitas yang diautentikasi memberi tahu klien apakah rekan yang menjawab adalah yang harus dipercaya. IKEv2 menyimpannya sebagai dua bidang terpisah, yang berguna setelah Anda berhenti memperlakukannya sebagai satu string. Mereka juga dikonfigurasikan di tempat yang berbeda, sehingga yang satu bisa benar sementara yang lain salah.

Periksa mereka dalam urutan ini dan berhenti pada ketidakcocokan pertama, karena pemeriksaan selanjutnya menganggap pemeriksaan sebelumnya telah lulus.

Pertama, nilai mana yang merupakan alamatnya

Alamat koneksi adalah apa pun yang dihubungi klien: IP, nama DNS yang ditetapkan menjadi satu, atau front end dengan beban seimbang. Itu adalah informasi transportasi dan tidak lebih. Identitas tersebut berada dalam payload ID IKEv2 dan kemudian dicocokkan dengan sertifikat rekan. Nama DNS di kotak alamat tidak menjadi identitas yang diharapkan, dan IP mentah tidak menjadi identitas hanya karena soket terhubung dengannya.

Dalam istilah strongSwan, alamatnya adalah right atau left, dan identitas yang diharapkan adalah rightid atau leftid, dan itulah yang dijelaskan dalam dokumentasi konfigurasi IKEv2. Jika Anda hanya pernah mengedit alamatnya, Anda telah mengkonfigurasi setengah dari pasangan.

Kedua, apa yang dapat dibuktikan oleh sertifikat tersebut

Identitas memiliki tipe, dan sertifikat harus memiliki nama yang cocok. Identitas DNS dipenuhi oleh entri dNSName dalam ekstensi nama alternatif subjek; identitas IP memerlukan entri iPAddress. Sertifikat yang diterbitkan untuk vpn.example.com tidak membuktikan apa pun tentang alamat literal 203.0.113.10, dan sertifikat yang diterbitkan untuk alamat tersebut tidak membuktikan apa pun tentang nama. Oleh karena itu, penerbitan ulang untuk nama yang berbeda bukanlah pengganti drop-in, bahkan ketika kunci dan CA yang sama digunakan kembali.

Klien modern mengabaikan nama umum ketika ada nama alternatif subjek, dan banyak yang mengabaikannya sepenuhnya. Jika daftar SAN tidak berisi nilai yang diperiksa klien, jabat tangan gagal setelah sertifikat diterima sebagai dapat dipercaya, itulah sebabnya log terbaca seperti kesalahan identitas daripada kesalahan kepercayaan.

Ketiga, bagaimana setiap klien menyatakan harapannya

Windows mengambil nama atau alamat server yang Anda ketikkan dan memerlukan sertifikat untuk mencocokkannya, sehingga mengetikkan IP akan menciptakan ekspektasi IP. Klien Android IKEv2 berperilaku dengan cara yang sama, dan keduanya menolak sertifikat yang valid dan dipercaya secara publik yang menamai host berbeda. Profil bisa mulai gagal hanya karena seseorang mengganti nama host dengan alamatnya selama migrasi. Lihatlah apa yang diminta klien sebelum Anda melihat isi sertifikat.

Pada strongSwan ekspektasinya jelas: setel rightid ke identitas yang sebenarnya dihadirkan oleh server, yang mungkin berbeda dari yang sebenarnya. Menyetelnya ke %any menerima apa pun yang ditawarkan rekannya dan menghapus cek yang ingin Anda pertahankan.

Keempat, pisahkan login pengguna dari identitas rekan

Otentikasi EAP dan identitas server menjawab pertanyaan yang berbeda. Identitas EAP seperti [email protected] menyatakan siapa penggunanya, setelah klien memutuskan bahwa server adalah yang tepat. Memutar kata sandi tersebut tidak dapat memperbaiki ketidakcocokan identitas rekan, karena koneksi tidak pernah mencapai tahap login pengguna.

Laporan yang sudah dibersihkan harus menyebutkan keduanya: identitas yang diharapkan klien, identitas yang disajikan server, dan entri SAN sertifikat.

Kelima, mengubahnya melalui saluran yang terverifikasi

Ketika gateway berpindah secara sah, perbarui alamatnya terlebih dahulu dan biarkan identitasnya saja, karena kasus tersebut IKEv2 dapat ditangani dengan baik. Ketika identitas itu sendiri berubah, perlakukan itu sebagai peristiwa kepercayaan dan dapatkan nilai baru dari sumber yang sudah Anda percayai, bukan dari titik akhir yang saat ini gagal. Pesan yang dikirimkan melalui koneksi yang Anda coba validasi bukanlah bukti tentang koneksi tersebut.

Catat alamat akhir, identitas dan daftar SAN bersama-sama di catatan profil. Orang berikutnya yang menyentuh sertifikat tersebut kemudian akan melihat siapa di antara ketiganya yang boleh berpindah.