IKEv2 NO_PROPOSAL_CHOSEN: peringkat mana yang menolak suite?

NO_PROPOSAL_CHOSEN dalam log menghantar orang kepada kunci yang dikongsi terlebih dahulu, dan ralat itu kekal walaupun selepas perubahan. Ia tidak pernah menjadi masalah kelayakan: rakan sebaya menolak setiap cadangan yang ditawarkan untuk pertukaran itu, yang merupakan kenyataan tentang algoritma dan bukan tentang identiti. Soalan berguna pertama bukanlah algoritma mana yang perlu diedit, tetapi pertukaran mana yang ditolak. Jawab itu sebelum membandingkan apa-apa. Kemudian bandingkan suite penuh yang ditawarkan dengan suite penuh yang dibenarkan oleh rakan sebaya.

Pertama: pertukaran mana yang ditolak

IKEv2 berunding dua jenis persatuan. IKE SA melindungi rundingan itu sendiri, dan CHILD SA melindungi trafik. Setiap satu mempunyai set cadangan sendiri, dan setiap satu boleh gagal dengan pemberitahuan yang sama. Penolakan semasa rundingan IKE awal dan penolakan semasa rundingan CHILD memerlukan pembaikan yang berbeza, dan log biasanya menamakan pertukaran itu satu atau dua baris di atas pemberitahuan. Baca kedua-dua baris itu bersama-sama, jika tidak anda akan mengedit senarai cadangan yang salah.

Pemberitahuan sahaja tidak mengenal pasti pertukaran. Baris di atasnya menamakan SA yang sedang dirunding, dan nama itu menunjuk kepada senarai cadangan yang perlu diperiksa.

Bandingkan suite penuh, bukan kata kunci tunggal

Cadangan ialah gabungan: algoritma penyulitan, integriti atau AEAD, kumpulan pertukaran kunci, dan sebarang fungsi pseudorawak. Membandingkan nama penyulitan sahaja ialah kesilapan biasa, kerana dua rakan sebaya boleh bersetuju tentang AES-256 dan masih tidak bersetuju tentang SHA-1 berbanding SHA-256. Tulis suite yang ditawarkan dan dibenarkan bersebelahan pada peringkat yang gagal, kemudian cari persilangan kosong.

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

Periksa juga bahawa kedua-dua pelaksanaan menyokong apa yang anda konfigurasikan. Nama yang disalin dari platform lain mungkin kelihatan biasa dari segi sintaksis manakala pemalam atau pelaksanaannya langsung tiada.

Suite IKE dan suite ESP ialah objek yang berbeza

Mengedit cadangan IKE tidak akan membaiki cadangan CHILD yang ditolak, dan sebaliknya juga benar. Dalam strongSwan ini ialah tetapan berasingan, kira-kira proposals = aes256-sha256-modp2048 untuk IKE SA dan senarai ESP berasingan untuk CHILD SA. Tukar senarai yang sepadan dengan pertukaran yang gagal, kemudian baca semula log dan jangan anggap pembaikan itu berjaya.

Untuk CHILD SA, tetapan yang berkaitan ialah senarai cadangan ESP, bukan senarai IKE. Menyalin baris IKE ke dalamnya menghasilkan konfigurasi yang dihuraikan tetapi merundingkan objek yang salah.

Terowong yang berfungsi tetapi gagal semasa pembaharuan kunci

Jika terowong berjalan selama satu jam dan kemudian gagal, rundingan awal bukanlah masalahnya. Pembaharuan kunci boleh menguji keadaan lain: kumpulan pertukaran kunci yang berbeza selepas pertukaran pertama, ketidakpadanan jangka hayat antara rakan sebaya, atau dasar responder yang berubah. Simpan cap masa pembaharuan dan pengecam persatuan dari kedua-dua pihak. Corak itu memerlukan perbandingan cadangan semasa pembaharuan, bukan tamat masa yang lebih panjang. Perubahan tamat masa menyembunyikan gejala dan membiarkan ketidakpadanan itu kekal.

ipsec statusall menunjukkan setiap persatuan dan algoritma yang sebenarnya dirundingkan. Output itu ialah cara terpantas untuk mengesahkan senarai mana yang digunakan, dan ia memisahkan ralat konfigurasi daripada terowong usang yang tidak pernah dirunding semula.

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

Pilih persilangan, kemudian sahkan kedua-dua fasa

Minta pentadbir memilih persilangan moden berdokumen yang disokong oleh kedua-dua rakan sebaya, dan tuliskannya. Jangan selesaikan ralat dengan mendayakan semua algoritma lama atau dengan melumpuhkan pengesahan identiti, kerana kedua-duanya tidak berpunca daripada penolakan. Selepas perubahan, wujudkan sambungan baharu dan kemudian paksa pembaharuan kunci. Sambungan pertama sahaja tidak membuktikan laluan pembaharuan berfungsi.

Simpan gabungan yang diterima bersama versi firmware. Jika ralat seterusnya melibatkan pemilih trafik, tangani secara berasingan, kerana persetujuan tentang kriptografi tidak mengatakan apa-apa tentang subnet mana yang dilindungi oleh terowong. dokumentasi cadangan strongSwan merangkumi sintaks untuk kedua-dua senarai.