IKEv2: pembaruan kunci versus autentikasi ulang — mengapa koneksi putus belakangan

Tunnel muncul pagi hari dan bekerja berjam-jam. Lalu putus, tersambung lagi setelah satu percobaan, dan melakukan hal yang sama keesokan harinya. Tidak ada yang berubah di jaringan dan tidak ada yang menyentuh kata sandi. Sesi yang gagal di batas pembaruan biasanya melewati salah satu dari dua operasi berbeda, dan hanya satu di antaranya memeriksa ulang kredensial Anda. Membaca mana yang terpicu adalah keseluruhan diagnosisnya.

Dua operasi yang tampak mirip dari luar

Pembaruan kunci mengganti asosiasi keamanan atau materi kunci dalam pertukaran yang ditetapkan protokol. Autentikasi tidak diulang, jadi identitas yang diterima di awal sesi sekadar dibawa terus.

Autentikasi ulang melangkah lebih jauh: ia membangun hubungan terautentikasi yang baru, yang berarti kredensial dievaluasi ulang. Apa pun yang kedaluwarsa, dicabut, atau diubah di direktori menjadi terlihat pada saat itu.

Apa yang sebenarnya diganti oleh pembaruan kunci

IKEv2 menyimpan dua jenis asosiasi dengan siklus hidup terpisah. IKE SA melindungi kanal kendali, dan CHILD SA melindungi lalu lintas sebenarnya. Memperbarui salah satunya bukan sinonim dari menyambungkan ulang klien.

Pemisahan itu menjelaskan pola yang akrab: lalu lintas mengalir lancar, lalu sebuah CHILD SA diperbarui dan proposal tidak lagi cocok karena seseorang menyunting fase 2 di satu sisi berminggu-minggu sebelumnya. Perubahan itu tergeletak tanpa bahaya sampai pembaruan menjalankannya.

Ketidakcocokan masa berlaku berperilaku sama. Pihak mana pun yang mencapai batasnya lebih dulu memulai pertukaran, dan pihak lain harus menerimanya.

Apa yang dievaluasi ulang oleh autentikasi ulang

Dengan autentikasi ulang, sertifikat klien yang valid saat login bisa jadi sekarang sudah kedaluwarsa. Kredensial yang dicabut, kata sandi yang dirotasi, atau faktor kedua yang tidak tersedia semuanya muncul di sini, bukan pada waktu pembaruan.

Itulah sebabnya memperpanjang setiap masa berlaku terasa seperti perbaikan padahal bukan. Anda menunda pemeriksaan alih-alih melewatinya. Pembaruan berikutnya datang dengan cacat yang sama dan jendela gangguan yang lebih pendek untuk menyadarinya.

Sebagian implementasi menumpuk keadaan lama dan baru selama autentikasi ulang. Yang lain menghasilkan celah singkat. Karena itu, pengaturan identik pada dua vendor bisa memberi pengalaman pengguna berbeda. Uji perilakunya alih-alih menganggap standar menentukan hal itu.

Baca stempel waktu sebelum mengubah apa pun

Catat momen kegagalan bersama keadaan asosiasi sebelum dan sesudahnya. Jika asosiasi lama diganti tanpa pertukaran autentikasi, Anda berada di batas pembaruan. Jika pertukaran AUTH muncul tepat sebelum kegagalan, Anda berada di autentikasi ulang.

strongSwan memaparkan ini sebagai pengaturan terpisah: rekey mengendalikan pembaruan kunci, reauth mengendalikan apakah autentikasi baru terjadi, dan nilai margin menentukan seberapa jauh sebelum kedaluwarsa masing-masing dimulai. dokumentasi pembaruan kunci menjelaskan interaksinya, dan layak dibaca sebelum menyalin masa berlaku dari kiriman forum.

Bedakan semua ini dari kehilangan jaringan biasa. Kanal yang terputus menghasilkan peristiwa deteksi peer mati atau badai pengiriman ulang, bukan pertukaran bersih dengan proposal yang cocok.

Ubah hal yang gagal

Penolakan kredensial perlu memperbaiki masalah identitas: perbarui sertifikat, pulihkan akun, daftarkan ulang faktor. Ketidakcocokan proposal atau masa berlaku perlu membandingkan parameter di kedua sisi.

Memperpanjang masa berlaku untuk menghindari gejalanya adalah satu-satunya opsi yang selalu tampak berhasil dan tidak pernah berhasil.

Uji pembaruan yang terkendali

Paksa pembaruan alih-alih menunggu sehari untuknya. Lalu ulangi dengan autentikasi ulang jika penerapan mendukungnya, dan pantau kedua ujungnya.

Login awal yang berhasil tidak melatih satu pun dari ini. Siklus hidup setelahnya adalah tempat penerapan ini benar-benar rusak.