L2TP: isyarat maut 15, NO_PROPOSAL_CHOSEN dan modp1024 yang hilang

Sambungan anda tergantung, klien keluar, dan baris terakhir pada skrin ialah death_handler: Fatal signal 15 received. Baris itu melaporkan penghentian, bukan punca. Satu baris lebih awal dalam log IPsec hampir selalu ada NO_PROPOSAL_CHOSEN, dan pasangan itu menunjuk ke fasa 2 pertukaran, tempat kedua-dua pihak membandingkan pilihan penyulitan dan cincang lalu berhenti apabila tiada yang sama. Kredensial belum dihantar pada peringkat itu, jadi menaip semula kata laluan tidak boleh mengubah hasilnya.

Biasanya dua perkara mengosongkan persilangan itu pada klien Linux. Daemon tempatan mungkin tidak lagi melaksanakan kumpulan Diffie-Hellman yang diminta profil, atau profil membawa cadangan fasa 1 dalam medan fasa 2. Kedua-duanya meninggalkan jejak dalam log, dan tiada satu pun masalah akaun.

Apa yang sebenarnya dikatakan kedua-dua mesej itu

IKE berunding dalam beberapa pusingan. Fasa 1 membina saluran terlindung dan memilih algoritmanya sendiri; fasa 2, SA anak, membawa trafik di bawah set berasingan. NO_PROPOSAL_CHOSEN ialah pemberitahuan yang dikembalikan penjawab apabila tiada kombinasi yang ditawarkan boleh diterima, dan ia muncul sebagai [ HASH N(NO_PROP) ] di dalam pertukaran INFORMATIONAL.

Isyarat 15 ialah peristiwa lain: sesuatu memberitahu proses tempatan supaya berhenti dan pengendali merekodkannya. Apabila kedua-dua baris muncul bersama, urutannya bersebab, penolakan dahulu kemudian pemadaman.

Baca rundingan sebelum menyentuh kredensial

Naikkan tahap log di tempat daemon menulis, kemudian sambung semula sambil memerhati output. Pada hos NetworkManager, pemalam L2TP menyalurkan tahap itu kepada backend, dan mesej masuk ke jurnal atau fail syslog klasik bergantung pada edaran. Mana-mana satu daripadanya akan menunjukkan pertukaran: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' atau tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Baris yang menamakan pluto datang dari libreswan, charon dari strongSwan, dan kedua-duanya menerangkan keadaan yang sama dengan perkataan berbeza. Bentuk yang berbaloi dicari ialah yang menamakan kumpulan yang hilang, contohnya algorithm 'modp1024' is not supported, kerana ia menukar kegagalan kabur kepada yang khusus.

Ke mana modp1024 pergi

Kumpulan 2 Diffie-Hellman cukup lemah sehingga beberapa edaran berhenti menyusunnya ke dalam libreswan mulai 3.30. Profil yang ditulis bertahun-tahun lalu, atau diambil daripada panduan gateway yang hanya menyenaraikan aes128-sha1-modp1024, kemudian meminta daemon tempatan melakukan sesuatu yang langsung tidak mampu dilakukannya. Binaan NetworkManager-l2tp yang lebih baharu menjadikan hasil itu lebih mungkin: sejak 1.2.16 mereka menggantikan set dengan cadangan bergaya Windows 10 dan iOS serta menggugurkan modp1024 sebaik libreswan dikesan. Hujung bertentangan selalunya tidak bersalah dan masih menawarkan tepat kumpulan yang anda konfigurasikan.

Asimetri itulah yang membuat kegagalan terasa rawak. Klien lama bersambung, profil yang sama pada komputer riba yang dikemas kini tidak, dan konfigurasi pelayan tidak pernah bergerak. Kerosakan berpunca daripada hanyutan versi.

Dua pembaikan dengan kesan berbeza

Pembaikan murah ialah berhenti mengekod algoritma secara keras. Kosongkan kedua-dua medan cadangan dalam editor dan biarkan pemalam memilih set yang diterima hujung jauh; jika gateway menyokong kumpulan moden, rundingan selesai tanpa kerja tambahan.

Pembaikan kedua mengekalkan gateway lama boleh dicapai dengan memasang strongSwan, yang pakejnya masih melaksanakan kumpulan 2 pada kebanyakan edaran. Itu pertukaran daemon, jadi ada kosnya: sahkan sama ada terowong lain pada hos bergantung pada konfigurasi libreswan sebelum menanggalkannya, dan jangkakan penolakan SELinux antara NetworkManager dan pemalam strongSwan pada Fedora. Penolakan itu muncul dalam log audit, bukan dalam surih IKE, sebab itulah terowong boleh kelihatan rosak sejurus selepas pemasangan yang berjaya. Urutan yang berkesan ialah dnf install strongswan dahulu, kemudian rpm -e libreswan.

Rentetan cadangan yang sepadan, dan perangkap di sekelilingnya

Apabila medan perlu diisi dengan tangan, fasa 1 dan fasa 2 mengambil nilai berbeza. Pasangan yang diketahui berkesan terhadap hujung bergaya Meraki menawarkan aes128-sha1-modp1024 dalam fasa 1 dengan 3des-sha1-modp1024 di belakangnya, kedua-duanya ditutup dengan tanda seru yang menjadikan set itu ketat, jadi hanya cadangan itu yang pernah dihantar.

Fasa 2 kemudian menyempit kepada aes128-sha1 dan 3des-sha1 dengan penanda ketat yang sama dan tanpa akhiran Diffie-Hellman sama sekali. Baris fasa 2 yang membawa -modp1024 ialah nilai fasa 1 dalam medan yang salah, dan penjawab menolaknya pada setiap cubaan semula. Salin baris itu ke profil kedua dan profil kedua gagal dengan cara yang sama, dan begitulah satu salah taip menjadi insiden seluruh armada.

Kerosakan lain memakai tetingkap timbul yang sama tanpa merupakan ketidakpadanan cadangan. Pada KDE jenis L2TP boleh tersenarai dengan pemalam dipasang sementara setiap sambungan mati serta-merta, kerana editor sambungan dan pembantu masa jalan dihantar sebagai pakej berasingan. Hos tanpa skrin boleh menggunakan semula profil daripada desktop yang berfungsi: salin daripada /etc/NetworkManager/system-connections/, tetapkan mod kepada 600, kemudian jalankan nmcli con reload. Naikkannya dengan nmcli con up id work-l2tp, kerana bentuk telanjang mahukan UUID, dan buang sebarang entri ifname yang usang, jika tidak pengurus menjawab Could not find source connection sedangkan semua yang lain betul.

Kunci yang dikongsi terlebih dahulu boleh disimpan sebagai teks biasa atau sebagai 0s diikuti base64; kedua-dua bentuk berfungsi, tetapi nilainya mesti sepadan dengan gateway bait demi bait, termasuk ruang di hujung yang anda salin bersamanya.