Apakah peningkatan Ubuntu merusak L2TP/IPsec? Bandingkan proposal IKEv1
Profil dan kata sandi tidak berubah, tetapi fase 1 kini gagal. Proposal yang dapat diterima klien telah bergeser, dan server masih menawarkan apa yang selalu ditawarkannya.
Koneksi berfungsi pada Kamis, peningkatan dijalankan pada Jumat, dan pada Senin klien berputar di “connecting” lalu menyerah. Laptop yang sama, server yang sama, akun yang sama, kunci yang dibagikan sebelumnya yang sama. Tidak ada yang diedit di profil, itulah sebabnya tersangka yang jelas, kata sandi dan firewall, membuang-buang waktu Anda.
Yang berubah adalah daftar transformasi yang bersedia ditawarkan mesin Anda. Kedua tumpukan IPsec yang digunakan di Ubuntu, strongSwan dan Libreswan, memangkas algoritme yang tidak lagi mereka anggap aman, dan plugin NetworkManager yang berada di depan keduanya memiliki daftarnya sendiri, yang bergerak menurut jadwal berbeda. Server yang dipatok ke 3DES, SHA1, dan grup Diffie-Hellman 1024 bit bisa akhirnya tidak mendengar apa pun yang diterimanya.
Apa yang sebenarnya diubah oleh peningkatan itu
Dua lapisan memberi masukan pada proposal IKEv1. Daemon membawa set proposal bawaan yang dikompilasi, dan plugin L2TP entah mengandalkannya atau menyediakan daftarnya sendiri. Sebelum NetworkManager-l2tp 1.2.16 plugin mengandalkannya, jadi proposal Anda adalah apa pun yang dianggap wajar oleh daemon yang terpasang. Sejak 1.2.16 plugin mengirim daftar terdokumentasi yang dimodelkan pada klien Windows dan Apple, dan daftar itu lebih luas daripada bawaan lama tetapi tidak lagi memuat setiap kombinasi warisan di depan antrean.
Pemisahan itu menjelaskan mode kegagalan yang dianggap membingungkan orang: dua mesin pada rilis Ubuntu yang sama dapat berperilaku berbeda karena yang satu memiliki paket distribusi dan yang lain memiliki backport, dan versi daemon pada keduanya tampak identik dalam laporan bug. Periksa versi plugin, bukan hanya versi daemon, sebelum menyimpulkan bahwa peningkatan tidak mengubah apa pun yang relevan.
Ada jebakan yang lebih kecil di area yang sama. Kedua daemon menulis grup Diffie-Hellman kurva eliptik secara berbeda, yang satu menulis ecp384 dan yang lain ecp_384. Tempelkan ejaan yang salah ke dialog Advanced dan daemon akan menolak setelan itu sebagai tidak dapat diurai, yang muncul di log sebagai masalah negosiasi, bukan salah ketik dalam konfigurasi.
Baca kegagalannya sebelum mengubah apa pun
Mulai dari backend mana yang Anda jalankan, karena jawabannya menentukan sintaks dan lokasi log.
ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec
Lalu baca pertukaran itu sendiri. Pada strongSwan daemon menulis ke journal pada rilis terkini dan ke /var/log/syslog pada rilis lama, dan bagian yang menarik adalah proposal yang dikirimnya, bukan baris terakhir. Anda mencari frasa tentang tidak ada proposal yang cocok, yang merupakan masalah algoritme; kegagalan autentikasi, yang menunjuk ke kunci atau akun; atau timeout biasa, yang menunjuk ke keterjangkauan.
Ketiga hasil ini terlalu sering diperlakukan sebagai satu gejala. Timeout dengan log daemon kosong berarti paket tidak sampai. Penolakan proposal berarti paket sampai dan ditolak. Jika log Anda sunyi, naikkan tingkat debug plugin untuk satu percobaan lalu turunkan setelahnya, karena keluaran bertele-tele cepat mengisi journal.
Fase 1 dan fase 2 adalah taruhan terpisah
IKEv1 bernegosiasi dua kali. Mode utama membangun asosiasi keamanan IKE dari algoritme enkripsi, algoritme integritas, grup Diffie-Hellman, dan metode autentikasi. Mode cepat kemudian membangun asosiasi ESP yang akan membawa L2TP. Server bebas menerima yang pertama dan menolak yang kedua, jadi profil yang setengah benar gagal lebih lambat dari yang Anda harapkan dan tampak seperti bug lain.
Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!
Tanda seru adalah sintaks strongSwan untuk entri ketat: tawarkan kombinasi ini saja dan tidak yang lain. Tanpanya entri bergabung dengan daftar cadangan, yang baik ketika rekan modern dan kontraproduktif ketika perangkat dengan satu kebijakan berkode keras. Anggap pasangan di atas sebagai ilustrasi bentuk, bukan rekomendasi untuk apa pun yang Anda bangun hari ini.
Ubah satu bidang, lalu ulangi pengujian
Pada plugin terkini, uji pertama tercepat adalah mengosongkan kedua bidang proposal sepenuhnya dan menyambung ulang, karena daftar bawaan yang dikirim sudah mencakup kombinasi Windows dan Apple yang umum. Pada plugin lama, mengosongkannya mengembalikan kendali ke daemon yang mungkin telah membuang algoritme yang dipaksakan server Anda, dan kegagalannya menjadi lebih buruk.
Jika pengosongan tidak membantu, setel pasangan ketat yang didokumentasikan server Anda, satu fase setiap kali. Ubah fase 1, sambungkan ulang, dan baca log sebelum menyentuh fase 2. Ketika kombinasi akhirnya berhasil, catat di samping model server dan versi plugin, karena bawaan akan bergeser lagi dan catatan itulah yang menjadikan peningkatan berikutnya sebagai pemeriksaan lima menit.