Mengapa terowongan IPsec yang sibuk mengganti kunci lebih awal: batas waktu versus volume

Kira-kira setiap lima puluh menit, terowongan pada tautan yang sibuk putus selama beberapa detik, dan tersangka pertama adalah jam. Asosiasi dapat berakhir pada batas waktu atau pada jumlah byte, dan batas mana pun yang datang lebih dulu itulah yang memensiunkan mereka. Pada tautan yang membawa lalu lintas nyata, batas volume dapat terpicu jauh sebelum jam yang dikonfigurasi berakhir. Jadi «terlalu awal» adalah pernyataan tentang jam, bukan tentang asosiasi.

Hitung apa yang dihitung asosiasi, bukan antarmuka

Total byte antarmuka, throughput gabungan dasbor, dan penghitung asosiasi itu sendiri adalah tiga angka terpisah, dan hanya satu yang dibandingkan dengan batas. Catat asosiasi masuk dan keluar secara terpisah dengan pengidentifikasinya, sehingga penggantian kunci yang menyentuh satu arah muncul sebagai peristiwa terarah alih-alih misteri. Penghitung asosiasi juga mulai lagi saat penggantian kunci, itulah sebabnya total yang diambil dari antarmuka bertambah sementara nilai yang penting diatur ulang.

Perhitungannya layak dilakukan sekali agar urutan besarnya berhenti terasa sembarangan. Anggaran terhitung satu gibibyte yang terkuras pada laju tetap 128 mebibyte per menit habis dalam delapan menit, dan itu konversi satuan, bukan pengukuran terowongan Anda. Jika angka yang dihasilkan jauh di bawah batas waktu, volume adalah mekanismenya dan tidak ada pengamatan jam yang akan menjelaskan intervalnya. Jika jauh di atasnya, batas byte bukan pemicu Anda dan pencariannya ada di tempat lain.

Ambang lunak dan keras adalah dua peristiwa berbeda

Ambang lunak meminta penggantian jauh sebelum batas keras mengakhiri asosiasi, dan implementasi menambahkan margin serta pengacakan mereka sendiri di atas apa pun yang Anda konfigurasikan. Itulah sebabnya interval yang diamati hampir tidak pernah berupa angka bulat. arsitektur IPsec menjelaskan masa pakai yang dinyatakan dalam waktu dan jumlah byte dengan dua jenis ambang, dan kedaluwarsa yang lebih awal yang berlaku. Perlakukan satu masa pakai tercetak sebagai jadwal dan Anda akan salah sebesar marginnya.

Baca kebijakan efektif dari status berjalan alih-alih menyimpulkannya dari angka di berkas, karena margin itu milik implementasi, bukan niat Anda. Tahan dorongan untuk meregangkan batas ke maksimumnya demi membungkam gejalanya: terowongan yang mengganti kunci sesuai jadwal berperilaku sebagaimana dirancang, dan masa pakai yang lebih panjang hanya menunda peristiwa sambil menjaga kunci yang telah disusupi tetap bisa dipakai lebih lama. Ketika penggantiannya sendiri gagal, batas itu adalah pembawa pesan, bukan kesalahannya.

Baca masa pakai efektif dari status berjalan

Di strongSwan, swanctl --list-sas mencetak ringkasan asosiasi beserta waktu penggantian kunci dan masa pakainya, sehingga nilai yang hendak diberlakukan daemon terlihat tanpa menebak. Pada host Linux tanpa tampilan daemon, ip xfrm state melaporkan batas byte dan paket lunak serta keras yang dikonfigurasi di samping penghitung saat ini. Kedua pembacaan itu menjawab pertanyaan berbeda dan keduanya layak disimpan di tiket.

swanctl --list-sas
ip -s xfrm state

Bandingkan ambang lunak yang tercetak dengan interval yang Anda ukur, karena penggantian yang mulai dengan margin di bawah batas keras itu normal dan yang tidak pernah mulai tidak normal. Jika daemon menunjukkan satu masa pakai dan status kernel menunjukkan yang lain, Anda sedang melihat dua lapisan yang tidak sepakat, dan itu sendiri adalah temuannya.

Awasi pertukaran yang menggantikan SA

Pisahkan tiga pembaruan, karena keduanya gagal dengan cara berbeda: penggantian kunci IKE SA membangun asosiasi kendali baru, penggantian kunci CHILD SA menggantikan asosiasi data, dan autentikasi ulang mengulang pertukaran identitas. Dalam IKEv2 setiap rekan memutuskan masa pakainya sendiri alih-alih menegosiasikan satu nilai bersama, jadi pertukaran yang tidak Anda mulai adalah hal biasa. Ketidakcocokan perfect forward secrecy adalah penyebab sering matinya child SA baru tepat pada interval penggantian kunci, dan tampilannya persis seperti kesalahan pengatur waktu sampai seseorang membaca proposalnya.

Bandingkan asosiasi lama dengan penerusnya dan dengan pertukaran yang menghasilkannya. Hilangnya pengidentifikasi adalah penggantian rutin; proposal yang ditolak, respons yang hilang, atau tidak adanya status penerus yang dapat dipakai adalah peristiwa lain dengan pemilik lain. Simpan bukti itu sebelum mengubah apa pun, karena catatan khusus versi, proposal rekan, dan masa pakai yang dinegosiasikan itulah yang membuat kasus tetap terbaca seminggu kemudian, setelah log berotasi.

Buktikan pembaruan alih-alih menyembunyikannya

Terima penerapan dengan melewati pembaruan yang Anda rencanakan, bukan pembaruan yang terjadi pada Anda. Paksa satu penggantian kunci di dalam jendela pemeliharaan, lalu pastikan kedua arah membawa data sesudahnya dan hasil aplikasi tidak berubah, bukan sekadar indikator terowongan hijau. Catat batas mana yang terpicu dan pertukaran mana yang terlibat.

Kesimpulan dengan bentuk seperti itu bertahan dalam pengujian, sedangkan nilai pengatur waktu yang diubah sehingga koneksi tampak tenang selama satu sore tidak. Jika hanya pengatur waktunya yang bergeser, buktinya ikut bergeser.