L2TP NO_PROPOSAL_CHOSEN: fasa manakah yang sebenarnya gagal?

NO_PROPOSAL_CHOSEN tiba sebelum sebarang nama pengguna PPP diperiksa, yang merupakan fakta berguna dan juga sebab mesej itu mengelirukan. Ia melaporkan bahawa satu pihak menolak satu cadangan; ia tidak melaporkan parameter mana yang tidak sepadan dan tidak menyatakan apa-apa tentang sama ada penolakan berlaku semasa membina persatuan IKE atau kemudian semasa berunding tentang perlindungan trafik. Di sebalik dua kemungkinan itu ada dua pembetulan berbeza, dan hanya satu daripadanya melibatkan kotak semak PFS yang mula dituju orang.

Satu mesej, dua set cadangan

Susunan IKEv1 L2TP/IPsec mempunyai dua rundingan berturutan. Fasa 1 membina persatuan keselamatan IKE daripada algoritma penyulitan, algoritma integriti dan kumpulan Diffie-Hellman. Fasa 2 kemudian merundingkan cara trafik dilindungi, dan keperluan PFS tergolong dalam perbualan kedua itu.

Kerana fasanya berturutan, kedudukan kegagalan memberitahu anda senarai mana yang perlu dibandingkan. Di situlah seluruh nilai diagnostik mesej itu, dan ia wajar dikeluarkan sebelum menyentuh mana-mana tetapan.

Mengapa kotak semak PFS tidak dapat membaiki fasa 1

Mematikan PFS mengubah sifat fasa 2. Jika kedua-dua pihak tidak pernah bersetuju tentang fasa 1, perbualan ESP tidak pernah berlaku, jadi kotak semak itu tidak memberi kesan sama sekali pada penolakan, dan itulah sebabnya menukarnya menghasilkan ralat yang sama dengan cap masa berbeza.

Kesilapan sebaliknya sama lazimnya. Persatuan IKE yang berjaya tidak membuktikan cadangan ESP boleh diterima, dan sama sekali tidak membuktikan kumpulan fasa 2 sepadan. Anggap terowong pengurusan yang sudah terbentuk sebagai bukti tentang fasa 1 sahaja. Orang membaca baris hijau sebagai «terowong hidup», kemudian menghabiskan sejam pada fasa yang salah kerana tiada apa-apa memberitahu mereka bahawa rundingan kedua belum bermula.

Baca log sebelum memilih algoritma

Kumpulkan mesej sebelum penolakan daripada backend yang benar-benar mengendalikan sambungan itu, dan kaitkan dengan percubaan yang sama. Tanpa kaitan itu anda sedang membaca sejarah sambungan lain dan membuat kesimpulan daripadanya.

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

Daripada baris itu, jawab dua soalan: adakah persatuan fasa 1 terbentuk, dan pertukaran mana yang gagal. Kedua-dua jawapan itu menyempitkan pencarian kepada satu senarai atribut. Pemberitahuan kosong tanpa konteks di sekelilingnya tidak dapat berbuat demikian, sesukar mana pun untuk mencuba cadangan daripada benang forum. Menyalin rentetan yang berfungsi daripada mesin dengan backend lain biasanya menggantikan satu penolakan dengan yang lain, sedikit lebih lewat.

Sintaks backend tidak berpindah

Catat versi NetworkManager-l2tp dan versi backend IPsec sebelum membandingkan apa-apa. Libreswan dan strongSwan tidak berkongsi sintaks cadangan atau set algoritma yang serupa, jadi rentetan yang berfungsi dalam satu ialah ralat sintaks dalam yang lain. Backend yang dipasang juga mungkin menolak IKEv1 mengikut dasar, dan ketika itu tiada cadangan akan pernah diterima.

README projek mendokumenkan perbezaan backend itu dan mengekalkan medan fasa 1 dan fasa 2 secara berasingan. Bacalah sebagai dokumentasi struktur, bukan sebagai jemputan untuk mengaktifkan setiap sifer sejarah dan kumpulan lemah, kerana sambungan yang hanya berjaya dengan cara itu bukan sambungan yang diminta anda bina.

Sepakati suit itu, kemudian sahkan peringkatnya

Tanya pengendali get laluan suit IKE dan ESP mana yang disokong dan diluluskan, kemudian bandingkan jawapan itu dengan cadangan berkesan klien dan bukan dengan fail konfigurasinya. Jika perselisihan khusus tentang PFS fasa 2, tetapkan kumpulan yang disokong atau dasar tanpa PFS yang diluluskan secara jelas. Jangan membuat kesimpulan dasar itu daripada nama ralat.

Apabila satu-satunya pertindihan memerlukan kriptografi yang tidak lagi diterima organisasi, keputusannya milik get laluan atau pemindahan protokol. Melebarkan rentetan klien sehingga sesuatu berunding ialah cara menghantar kelemahan yang sudah diketahui dengan tanda semak hijau di sisinya.

Selepas membetulkan ketidaksesuaian sebenar, sahkan pembentukan IPsec sebelum menyiasat L2TP dan PPP, dan anggap sebarang penolakan pengesahan kemudian sebagai milik peringkat seterusnya. Kemudian uji pembaharuan dalam proses ujian yang diluluskan, kerana pembentukan persatuan pertama tidak mengatakan apa-apa tentang baki hayatnya.