IKEv2 NO_PROPOSAL_CHOSEN: tahap mana yang menolak suite?

NO_PROPOSAL_CHOSEN di log mengirim orang ke kunci yang dibagikan sebelumnya, dan kesalahan itu tetap bertahan setelah perubahan. Ini tidak pernah menjadi masalah kredensial: peer menolak setiap proposal yang ditawarkan untuk pertukaran itu, yang merupakan pernyataan tentang algoritma dan bukan tentang identitas. Pertanyaan berguna pertama bukanlah algoritma mana yang harus diedit, melainkan pertukaran mana yang ditolak. Jawab itu sebelum membandingkan apa pun. Lalu bandingkan suite lengkap yang ditawarkan dengan suite lengkap yang diizinkan peer.

Pertama: pertukaran mana yang ditolak

IKEv2 menegosiasikan dua jenis asosiasi. IKE SA melindungi negosiasi itu sendiri, dan CHILD SA melindungi lalu lintas. Masing-masing memiliki kumpulan proposal sendiri, dan masing-masing dapat gagal dengan notifikasi yang sama. Penolakan selama negosiasi IKE awal dan penolakan selama negosiasi CHILD memerlukan perbaikan berbeda, dan log biasanya menyebut pertukaran itu satu atau dua baris di atas notifikasi. Baca kedua baris itu bersama-sama, atau Anda akan mengedit daftar proposal yang salah.

Notifikasi saja tidak mengidentifikasi pertukaran. Baris di atasnya menyebut SA yang sedang dinegosiasikan, dan nama itu menunjuk ke daftar proposal yang harus diperiksa.

Bandingkan suite lengkap, bukan kata kunci tunggal

Proposal adalah kombinasi: algoritma enkripsi, integritas atau AEAD, grup pertukaran kunci, dan fungsi acak semu apa pun. Membandingkan hanya nama enkripsi adalah kesalahan biasa, karena dua peer dapat menyetujui AES-256 dan tetap tidak setuju soal SHA-1 versus SHA-256. Tuliskan suite yang ditawarkan dan yang diizinkan berdampingan pada tahap yang gagal, lalu cari irisan kosong.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Periksa juga bahwa kedua implementasi mendukung apa yang Anda konfigurasi. Nama yang disalin dari platform lain bisa terlihat familier secara sintaksis sementara plugin atau implementasinya sama sekali tidak ada.

Suite IKE dan suite ESP adalah objek yang berbeda

Mengedit proposal IKE tidak akan memperbaiki proposal CHILD yang ditolak, dan sebaliknya juga berlaku. Di strongSwan ini adalah pengaturan terpisah, kira-kira proposals = aes256-sha256-modp2048 untuk IKE SA dan daftar ESP terpisah untuk CHILD SA. Ubah daftar yang sesuai dengan pertukaran yang gagal, lalu baca ulang log alih-alih menganggap perbaikannya berhasil.

Untuk CHILD SA, pengaturan yang relevan adalah daftar proposal ESP, bukan daftar IKE. Menyalin baris IKE ke dalamnya menghasilkan konfigurasi yang terurai tetapi menegosiasikan objek yang salah.

Tunnel yang berfungsi lalu gagal saat pembaruan kunci

Jika tunnel berjalan selama satu jam lalu gagal, negosiasi awal bukanlah masalahnya. Pembaruan kunci dapat menguji kondisi lain: grup pertukaran kunci yang berbeda setelah pertukaran pertama, ketidakcocokan masa berlaku antar peer, atau kebijakan responder yang berubah. Simpan stempel waktu pembaruan dan pengenal asosiasi dari kedua sisi. Pola itu memerlukan perbandingan proposal saat pembaruan, bukan batas waktu yang lebih panjang. Mengubah batas waktu menyembunyikan gejala dan membiarkan ketidakcocokan tetap ada.

ipsec statusall menampilkan setiap asosiasi dan algoritma yang benar-benar dinegosiasikan. Keluaran itu adalah cara tercepat untuk memastikan daftar mana yang digunakan, dan memisahkan kesalahan konfigurasi dari tunnel usang yang tidak pernah dinegosiasikan ulang.

ipsec statusall | grep -E "IKE:|ESP:"

Pilih irisan, lalu pastikan kedua fase

Minta administrator memilih irisan modern terdokumentasi yang didukung kedua peer, dan menuliskannya. Jangan selesaikan kesalahan dengan mengaktifkan semua algoritma lama atau dengan menonaktifkan verifikasi identitas, karena keduanya tidak mengikuti dari penolakan. Setelah perubahan, buat koneksi baru lalu paksa pembaruan kunci. Koneksi pertama saja tidak membuktikan jalur pembaruan berfungsi.

Simpan kombinasi yang diterima bersama versi firmware. Jika kesalahan berikutnya menyangkut pemilih lalu lintas, tangani secara terpisah, karena kesepakatan tentang kriptografi tidak mengatakan apa pun tentang subnet mana yang dilindungi tunnel. dokumentasi proposal strongSwan mencakup sintaks untuk kedua daftar.