NO_PROPOSAL_CHOSEN pada L2TP? Pindai gateway lebih dulu

Klien L2TP/IPsec yang gagal sebelum prompt nama pengguna tidak pernah menyepakati fase 1. Pindai kumpulan proposal gateway alih-alih menempelkan string cipher.

Prompt nama pengguna tidak pernah muncul, dan klien melaporkan NO_PROPOSAL_CHOSEN. Kredensial dan kunci yang dibagikan sebelumnya tidak relevan pada titik itu, karena kedua ujung belum menyepakati cara melindungi fase 1. Kebanyakan orang menanggapinya dengan menempelkan string cipher yang mereka temukan online. Pemindaian gateway menjawab pertanyaan yang sama dengan bukti dan memakan waktu kurang lebih sama.

Apa yang dikesampingkan pesan ini

Penolakan terjadi dalam mode utama, sebelum pertukaran L2TP atau PPP apa pun, sehingga terowongan dan basis data pengguna belum ditanyai. Fase 1 menegosiasikan enkripsi, integritas, dan grup Diffie-Hellman. Fase 2 menegosiasikan proposal ESP untuk data. Kegagalan fase 1 tidak bisa diperbaiki dengan mengubah pengaturan PFS fase 2, dan asosiasi IKE yang selesai tidak membuktikan bahwa proposal ESP cocok.

Catat backend sebelum menyunting sintaksis: ipsec --version. libreswan dan strongSwan menerima ejaan proposal yang berbeda untuk algoritme yang sama.

Lalu 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.

Pindai gateway untuk kumpulan transformasinya

Pemindai bertanya langsung kepada gateway transformasi mana yang akan dinegosiasikannya. Hentikan dulu layanan IPsec lokal agar pemeriksaan tidak bersaing dengan klien Anda sendiri, lalu baca baris SA. Perlakukan daftar itu sebagai bukti tentang lawan, bukan sebagai menu untuk diaktifkan seluruhnya.

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

Perangkat lama sering menawarkan 3DES, SHA1, dan MODP1024, karena itulah default saat produk dikirim dan tidak ada yang meninjaunya kembali. Simpan keluaran mentah pemindaian, karena itulah satu-satunya catatan tentang apa yang ditawarkan lawan pada hari itu. Jika itu tumpang tindih terkuat yang tersedia, eskalasi yang tepat adalah kepada pemilik gateway, bukan kepada konfigurasi klien yang mengaktifkan kembali kriptografi lemah bagi semua orang.

Cocokkan tumpang tindih tanpa mematikan keamanan

Masukkan hanya transformasi yang muncul di pemindaian dan kebijakan Anda. Contoh di bawah mencerminkan gateway yang menawarkan 3DES, SHA1, dan MODP1024 pada fase 1. Perhatikan catatan backend: libreswan 4.x tidak mengompilasi grup modp1024, jadi ini berlaku untuk strongSwan atau build libreswan dengan dukungan DH2. Verifikasi versinya sebelum menyimpulkan klien rusak.

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

Tanda seru di akhir menyematkan satu proposal. Gunakan untuk mengisolasi pengujian, lalu hapus agar gateway dapat menegosiasikan sesuatu yang lebih kuat nanti.

Periksa daemon dan port sebelum mencoba lagi

NetworkManager-l2tp memulai instans xl2tpd-nya sendiri. Jika layanan sistem sudah memiliki UDP 1701, klien beralih ke port sumber sementara, yang diizinkan RFC 3193 dan diam-diam dibuang oleh sebagian server. Periksa pemilik soket sebelum percobaan berikutnya.

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

Rahasia hasil pembangkitan yang basi adalah penyebab senyap lainnya. Berkas di bawah /etc/ipsec.d/ yang dinamai untuk koneksi lama bisa bertahan lebih lama daripada profil yang membuatnya, jadi hapus yang tidak dirujuk oleh apa pun dan coba lagi.

Terakhir, periksa dari mana saran itu berasal. Sebuah ipsec.conf yang ditulis untuk IKEv1 XAuth menjelaskan jenis VPN yang berbeda, dan proposalnya bukan satu-satunya baris yang akan salah dalam profil L2TP. Catat kumpulan transformasi yang Anda masukkan di samping profil, agar orang berikutnya tidak mengulang pemeriksaan.

Artikel terkait