iOS IKEv2 ke strongSwan: tidak ada proposal yang dipilih, perbaiki daftarnya

iPhone mengangkat tunnel, gateway menjawab dengan kosong, dan ponsel menampilkan kegagalan generik. Log strongSwan lebih spesifik: no proposal chosen. Pesan itu berarti dua daftar suite cipher yang dapat diterima tidak pernah tumpang tindih, sehingga pertukaran berakhir sebelum autentikasi dimulai. Ini masalah pencocokan, dan solusinya adalah membuat kedua daftar beririsan.

Di mana gateway menyatakan kebijakannya

strongSwan menulis kebijakannya di konfigurasi, dan tanda seru di akhir menentukan cara kebijakan itu dibaca. Dengan tanda itu daftarnya lengkap: entri-entri itulah yang diterima dan tidak ada yang lain. Tanpanya, baris yang sama adalah urutan preferensi, dan daemon dapat memilih sesuatu yang tidak Anda maksud. Tanyakan bentuk mana yang dipakai sebelum menerjemahkan apa pun, karena keduanya berperilaku berbeda terhadap klien yang sama. Catat baris persisnya, termasuk tandanya, dan uji terhadap baris itu.

Klien yang menawarkan daftar lebih luas tetap dapat terhubung ke gateway yang dipatok, asalkan satu kombinasi muncul di kedua sisi. Yang tidak dapat terjadi adalah negosiasi di luar himpunan yang dipatok.

Itulah sebabnya profil yang disalin dari aplikasi VPN lain bisa berhasil di tempat profil Anda gagal: aplikasi lain mengirimkan daftar yang berbeda.

Namanya harus cocok, bukan lebih baik

Dua terjemahan menjebak orang yang memindahkan nilai dari strongSwan ke iOS. Algoritme integritas yang ditulis SHA1 dalam proposal IKE berjalan dalam bentuk terpotongnya, yang oleh iOS disebut .SHA96. Grup Diffie-Hellman yang ditulis modp1024 adalah grup 2, yang oleh iOS disebut .group2. Mengganti dengan SHA-256 atau grup 14 tidak akan bernegosiasi dengan gateway yang hanya menerima pasangan lama. Klien harus menjelaskan algoritme yang sama, bukan yang lebih kuat.

Atur nilai-nilai itu secara eksplisit di NEVPNProtocolIKEv2. Nilai bawaan bisa lebih lebar atau lebih sempit daripada profil yang Anda ganti, dan perbedaannya baru muncul saat handshake gagal.

Proposal anak gagal belakangan dan lebih senyap

Konfigurasikan juga security association anak, bukan hanya yang IKE. Bila hanya parameter IKE yang cocok, tunnel terautentikasi lalu tidak membawa lalu lintas, kegagalan yang jauh lebih senyap daripada penolakan. Atur enkripsi, integritas, grup, dan masa berlaku anak dalam satu langkah yang sama. Jaga masa berlaku klien pada atau di bawah nilai gateway, karena memaksa yang lebih panjang menghasilkan pesan no proposal chosen yang sama dari penyebab berbeda. Ketidakcocokan di sana terlihat identik dengan ketidakcocokan IKE di log.

Periksa apakah profil mengautentikasi dengan sertifikat atau rahasia bersama saat Anda berada di konfigurasi. Penolakan proposal dan penolakan autentikasi muncul di baris berbeda, dan memperbaiki yang salah menghabiskan satu hari. Uji dengan koneksi baru setelah setiap perubahan, satu variabel setiap kali, karena keadaan yang di-cache menyembunyikan parameter mana yang bergeser.

Biarkan suite lama hanya selama diperlukan

Memaku SHA-1 dengan grup 1024 bit adalah jembatan, bukan tujuan. Keduanya sudah usang, dan klien yang lebih baru dapat menolaknya sama sekali, yang berarti profil akan gagal di perangkat berikutnya tanpa perubahan apa pun di sisi Anda. Perlakukan pemakuan itu sebagai sementara dan tuliskan hal itu dalam catatan.

Jika strongSwan milik Anda, tambahkan proposal modern dan biarkan kedua ujung bernegosiasi ke atas sementara entri lama tetap ada untuk perangkat lama. Baca keluaran status daemon untuk melihat suite mana yang benar-benar dipakai setiap koneksi. Lalu hapus pemakuan di sisi klien setelah pasangan modern dikonfirmasi. Tunnel yang berhasil terangkat bukan bukti yang cukup, karena ia bisa terangkat pada suite yang ingin Anda pensiunkan. Dokumentasi IKEv2 strongSwan menjelaskan sintaks proposal dan penanda strict.