L2TP NO_PROPOSAL_CHOSEN: fase mana yang sebenarnya gagal?

NO_PROPOSAL_CHOSEN datang sebelum nama pengguna PPP mana pun diperiksa, yang merupakan fakta berguna dan sekaligus alasan pesan itu menyesatkan. Pesan itu melaporkan bahwa satu pihak menolak sebuah proposal; pesan itu tidak melaporkan parameter mana yang tidak cocok, dan tidak mengatakan apa pun tentang apakah penolakan terjadi saat membangun asosiasi IKE atau belakangan saat menegosiasikan perlindungan lalu lintas. Di balik dua kemungkinan itu ada dua perbaikan berbeda, dan hanya satu di antaranya melibatkan kotak centang PFS yang pertama kali dijangkau orang.

Satu pesan, dua himpunan proposal

Susunan IKEv1 L2TP/IPsec memiliki dua negosiasi berurutan. Fase 1 membangun asosiasi keamanan IKE dari algoritme enkripsi, algoritme integritas, dan grup Diffie-Hellman. Fase 2 lalu menegosiasikan bagaimana lalu lintas dilindungi, dan persyaratan PFS termasuk dalam percakapan kedua itu.

Karena fasenya berurutan, letak kegagalan memberi tahu Anda daftar mana yang harus dibandingkan. Itulah seluruh nilai diagnostik dalam pesan tersebut, dan layak diekstrak sebelum menyentuh pengaturan apa pun.

Mengapa kotak centang PFS tidak dapat memperbaiki fase 1

Menonaktifkan PFS mengubah properti fase 2. Jika kedua pihak tidak pernah sepakat soal fase 1, percakapan ESP tidak pernah terjadi, jadi kotak centang itu sama sekali tidak berpengaruh pada penolakan, dan itulah sebabnya mengubahnya menghasilkan galat yang sama dengan stempel waktu berbeda.

Kesalahan sebaliknya sama umumnya. Asosiasi IKE yang berhasil tidak membuktikan proposal ESP dapat diterima, dan jelas tidak membuktikan grup fase 2 cocok. Perlakukan terowongan manajemen yang sudah terbentuk sebagai bukti tentang fase 1 saja. Orang membaca garis hijau sebagai «terowongannya hidup», lalu menghabiskan satu jam pada fase yang salah karena tidak ada yang memberi tahu mereka bahwa negosiasi kedua belum dimulai.

Baca log sebelum memilih algoritme

Kumpulkan pesan tepat sebelum penolakan dari backend yang benar-benar menangani koneksi itu, dan korelasikan dengan percobaan yang sama. Tanpa korelasi itu Anda membaca riwayat koneksi lain dan menarik kesimpulan darinya.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Dari baris-baris itu, jawab dua pertanyaan: apakah asosiasi fase 1 terbentuk, dan pertukaran mana yang gagal. Kedua jawaban itu mempersempit pencarian ke satu daftar atribut. Notifikasi telanjang tanpa konteks di sekitarnya tidak dapat melakukan itu, semenarik apa pun mencoba proposal dari utas forum. Menyalin string yang berfungsi dari mesin dengan backend lain biasanya menggantikan satu penolakan dengan penolakan lain, sedikit lebih lambat.

Sintaksis backend tidak berpindah

Catat versi NetworkManager-l2tp dan versi backend IPsec sebelum membandingkan apa pun. Libreswan dan strongSwan tidak berbagi sintaksis proposal atau himpunan algoritme yang identik, sehingga string yang berfungsi di satu backend merupakan galat sintaksis di backend lain. Backend yang terpasang juga dapat menolak IKEv1 berdasarkan kebijakan, dan pada saat itu tidak ada proposal yang akan pernah diterima.

README proyek mendokumentasikan perbedaan backend itu dan menjaga bidang fase 1 dan fase 2 tetap terpisah. Bacalah sebagai dokumentasi struktur, bukan sebagai undangan untuk mengaktifkan setiap cipher historis dan grup lemah, karena koneksi yang hanya berhasil dengan cara itu bukan koneksi yang diminta untuk Anda bangun.

Sepakati suite, lalu verifikasi tahapannya

Tanyakan kepada operator gateway suite IKE dan ESP mana yang didukung dan disetujui, lalu bandingkan jawaban itu dengan proposal efektif klien, bukan dengan berkas konfigurasinya. Jika perselisihannya khusus soal PFS fase 2, sepakati grup yang didukung atau kebijakan tanpa PFS yang disetujui secara eksplisit. Jangan menyimpulkan kebijakan dari nama galat.

Ketika satu-satunya irisan menuntut kriptografi yang tidak lagi diterima organisasi, keputusannya ada pada gateway atau pada migrasi protokol. Melebarkan string klien sampai sesuatu bernegosiasi adalah cara mengirimkan kelemahan yang sudah diketahui dengan tanda centang hijau di sampingnya.

Setelah memperbaiki ketidakcocokan yang sebenarnya, konfirmasikan pembentukan IPsec sebelum menyelidiki L2TP dan PPP, dan perlakukan penolakan autentikasi berikutnya sebagai bagian dari tahap selanjutnya. Lalu uji pembaruan dalam proses pengujian yang disetujui, karena membentuk asosiasi pertama tidak mengatakan apa pun tentang sisa masa hidupnya.