NO_PROPOSAL_CHOSEN pada L2TP? Imbas gateway dahulu

Prompt nama pengguna tidak pernah muncul, dan klien melaporkan NO_PROPOSAL_CHOSEN. Pada ketika itu kelayakan dan kunci yang dikongsi terlebih dahulu tidak relevan, kerana kedua-dua hujung belum bersetuju cara melindungi fasa 1. Kebanyakan orang bertindak balas dengan menampal rentetan sifer yang mereka temui dalam talian. Imbasan gateway menjawab soalan yang sama dengan bukti dan mengambil masa lebih kurang sama.

Apa yang dikecualikan oleh mesej ini

Penolakan berlaku dalam mod utama, sebelum sebarang pertukaran L2TP atau PPP, jadi terowong dan pangkalan data pengguna belum ditanya. Fasa 1 merundingkan penyulitan, integriti dan kumpulan Diffie-Hellman. Fasa 2 merundingkan cadangan ESP untuk data. Kegagalan fasa 1 tidak boleh dibetulkan dengan menukar tetapan PFS fasa 2, dan persatuan IKE yang selesai tidak membuktikan cadangan ESP sesuai.

Catat backend sebelum menyunting sintaks: ipsec --version. libreswan dan strongSwan menerima ejaan cadangan yang berbeza untuk algoritma yang sama.

Kemudian baca penolakan itu dalam konteks dengan journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Imbas gateway untuk set transformasinya

Pengimbas bertanya terus kepada gateway transformasi mana yang akan dirundingkannya. Hentikan dahulu perkhidmatan IPsec tempatan supaya siasatan tidak bersaing dengan klien anda sendiri, kemudian baca baris SA. Anggap senarai itu sebagai bukti tentang rakan, bukan sebagai menu untuk diaktifkan sepenuhnya.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Perkakas lama sering menawarkan 3DES, SHA1 dan MODP1024, kerana itulah nilai lalai semasa produk dihantar dan tiada siapa menyemaknya semula. Simpan keluaran mentah imbasan, kerana itulah satu-satunya rekod tentang apa yang ditawarkan oleh rakan pada hari itu. Jika itulah pertindihan terkuat yang tersedia, eskalasi yang betul adalah kepada pemilik gateway, bukan kepada konfigurasi klien yang menghidupkan semula kriptografi lemah untuk semua orang.

Padankan pertindihan tanpa melumpuhkan keselamatan

Masukkan hanya transformasi yang muncul dalam imbasan dan dasar anda. Contoh di bawah mencerminkan gateway yang menawarkan 3DES, SHA1 dan MODP1024 dalam fasa 1. Perhatikan kaveat backend: libreswan 4.x tidak mengkompil kumpulan modp1024, jadi ini terpakai kepada strongSwan atau binaan libreswan dengan sokongan DH2. Sahkan versi sebelum membuat kesimpulan bahawa klien rosak.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Tanda seru di hujung menyematkan satu cadangan. Gunakannya untuk mengasingkan ujian, kemudian buangkannya supaya gateway boleh merundingkan sesuatu yang lebih kuat kemudian.

Periksa daemon dan port sebelum mencuba lagi

NetworkManager-l2tp memulakan instans xl2tpd sendiri. Jika perkhidmatan sistem sudah memiliki UDP 1701, klien beralih kepada port sumber sementara, yang dibenarkan oleh RFC 3193 dan dibuang secara senyap oleh sesetengah pelayan. Periksa pemilik soket sebelum percubaan seterusnya.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Rahsia terjana yang luput ialah punca senyap yang lain. Fail di bawah /etc/ipsec.d/ yang dinamakan sempena sambungan lama boleh bertahan lebih lama daripada profil yang menciptanya, jadi buang yang tiada apa merujuknya dan cuba lagi.

Akhir sekali, periksa dari mana nasihat itu datang. Satu ipsec.conf yang ditulis untuk IKEv1 XAuth menerangkan jenis VPN yang berbeza, dan cadangannya bukan satu-satunya baris yang akan salah dalam profil L2TP. Catat set transformasi yang anda masukkan di sebelah profil, supaya orang seterusnya tidak mengulangi siasatan itu.