Mengapa tunnel IPsec Anda bertahan sampai pergantian kunci CHILD SA pertama

Tunnel terangkat, ping menjawab, dan semua orang menandatangani. Empat jam kemudian sesi putus, kedua peer mencatat galat proposal atau pertukaran kunci, dan dugaan pertama adalah ada yang berubah di jaringan. Tidak ada yang berubah. Tunnel yang membawa lalu lintas membuktikan bahwa kedua peer sepakat soal cara mengautentikasi dan cara melindungi asosiasi anak pertama, dan tidak membuktikan apa pun soal pertukaran kunci yang akan mereka tuntut saat pembaruan. Ketidakcocokan itu berada di celah antara kedua peristiwa tersebut.

Terhubung tidak berarti setelan PFS cocok

Dengan IKEv2, asosiasi anak pertama dibuat selama pertukaran autentikasi, dan kuncinya diturunkan dari materi yang sudah dihasilkan asosiasi IKE. Tidak ada pertukaran Diffie-Hellman terpisah untuk anak itu, jadi kebijakan yang menuntutnya saat pembaruan tidak diuji saat pengangkatan.

Pembaruan adalah pertukaran yang berbeda. Saat kunci asosiasi anak diperbarui, kedua peer dapat melakukan pertukaran kunci baru dengan grup yang disebut dalam proposal mereka, dan itulah momen pertama setelan grup dibandingkan. Karena itu dua peer yang tidak sepakat bisa mengautentikasi, memasang asosiasi anak, dan melewatkan lalu lintas, lalu gagal pada pembaruan.

Di mana ketidakcocokan bersembunyi di string proposal

Di strongSwan grup ditambahkan ke proposal anak, itulah sebabnya string seperti aes256gcm16-prfsha256-ecp256 terlihat seperti pilihan enkripsi tetapi juga membawa syarat pertukaran kunci. Peer yang hanya menawarkan aes256gcm16-prfsha256 tidak punya syarat seperti itu, dan kedua daftar beririsan pada enkripsi tetapi berbeda pada pertukaran.

Baca proposal anak dan proposal IKE sebagai daftar terpisah. Grup yang muncul di daftar IKE tidak mengatakan apa pun tentang daftar anak, dan menyunting yang satu sambil membaca yang lain adalah cara biasa hal ini terlewat.

Baca kegagalannya, bukan berkas yang Anda sunting

Temukan notify yang mengakhiri pertukaran. Pembaruan kunci anak yang mengembalikan «tidak ada proposal yang dapat diterima» menunjuk ke daftar proposal; permintaan pembaruan yang tidak pernah mendapat balasan menunjuk ke jalur atau ke peer yang berhenti mendengarkan. Keduanya butuh perbaikan berbeda, dan susunan kata pada baris log memisahkannya.

Pastikan konfigurasi yang berjalan, bukan yang ada di disk. Berkas yang disimpan tetapi tidak dimuat, atau koneksi yang dibaca ulang dari include lain, akan menghasilkan ketidakcocokan yang tidak bisa diperbaiki oleh sebanyak apa pun penyuntingan berkas yang terlihat.

Tiga peristiwa yang semuanya disebut pergantian kunci

Pergantian kunci asosiasi IKE, autentikasi ulang IKE, dan pergantian kunci asosiasi anak adalah operasi terpisah dengan aturan proposal terpisah. Kegagalan yang dilaporkan pada salah satunya tidak langsung mengatakan apa pun tentang yang lain, dan log yang mencampurnya terbaca seperti satu kerusakan berulang padahal ada tiga.

Perhatikan peristiwa mana yang disebut peer, lalu periksa proposal hanya untuk peristiwa itu. Ubah satu daftar, muat ulang, dan paksa peristiwa yang sama sekali lagi. Jika log menyebut autentikasi ulang, proposal IKE-lah yang harus dibaca. Jika menyebut pergantian kunci anak, proposal anak membawa grup yang penting.

Mematikan pembaruan bukan perbaikan

Menyetel waktu pergantian kunci ke nol menekan pertukaran yang gagal, dan tunnel lalu bertahan sampai dibongkar atau peer dimulai ulang. Yang Anda beli adalah kunci berumur lebih panjang dan ketidakcocokan yang akan menemui Anda lagi saat migrasi, audit, atau pembaruan dari vendor. Hal yang sama berlaku untuk masa berlaku yang direntangkan jauh melampaui kebijakan yang diharapkan sisi lain.

Selaraskan proposalnya. Pilih grup yang diterapkan kedua peer, taruh di proposal anak pada kedua ujung, dan jaga kebijakan pembaruan di dalam rentang yang benar-benar dibutuhkan organisasi.

Buktikan dengan pertukaran yang gagal

Perpendek waktu pergantian kunci anak dalam jendela pemeliharaan agar peristiwanya datang dalam hitungan menit, bukan jam, atau picu pergantian kunci anak secara manual. Lalu pantau pembaruan yang berhasil dan pastikan lalu lintas terus melewatinya, karena jabat tangan baru yang memasang asosiasi anak tetapi menjatuhkan aliran aplikasi adalah cacat yang berbeda.

Setelah itu pulihkan masa berlaku normal dan simpan kedua catatan peristiwa, yang gagal dan yang berhasil. Bukti yang Anda inginkan adalah koneksi bertahan melewati siklus hidupnya sendiri, bukan bahwa ia bertahan melewati ping.