iOS IKEv2 ke strongSwan: tiada cadangan dipilih, betulkan senarai

iPhone mengangkat terowong, gateway menjawab dengan kosong, dan telefon memaparkan kegagalan umum. Log strongSwan lebih khusus: no proposal chosen. Mesej itu bermaksud dua senarai suite sifer yang boleh diterima tidak pernah bertindih, jadi pertukaran berakhir sebelum pengesahan bermula. Ini masalah pemadanan, dan penyelesaiannya ialah membuat senarai itu bersilang.

Di mana gateway menyatakan dasarnya

strongSwan menulis dasarnya dalam konfigurasi, dan tanda seru di hujung menentukan cara dasar itu dibaca. Dengan tanda itu senarai bersifat menyeluruh: entri itu sahaja diterima dan tiada yang lain. Tanpanya, baris yang sama ialah susunan keutamaan, dan daemon boleh memilih sesuatu yang tidak anda maksudkan. Tanya bentuk mana yang digunakan sebelum menterjemah apa-apa, kerana kedua-duanya berkelakuan berbeza terhadap klien yang sama. Rekodkan baris tepat itu, termasuk tanda, dan uji terhadapnya.

Klien yang menawarkan senarai lebih luas masih boleh menyambung ke gateway yang dipin, asalkan satu kombinasi muncul pada kedua-dua belah. Yang tidak boleh berlaku ialah rundingan di luar set yang dipin.

Itulah sebabnya profil yang disalin daripada aplikasi VPN lain boleh berfungsi di tempat profil anda gagal: aplikasi lain menghantar senarai yang berbeza.

Nama mesti sepadan, bukan menjadi lebih baik

Dua terjemahan memerangkap orang yang memindahkan nilai daripada strongSwan ke iOS. Algoritma integriti yang ditulis SHA1 dalam cadangan IKE bergerak dalam bentuk terpangkasnya, yang dipanggil iOS .SHA96. Kumpulan Diffie-Hellman yang ditulis modp1024 ialah kumpulan 2, yang dipanggil iOS .group2. Menggantikan dengan SHA-256 atau kumpulan 14 tidak akan berunding dengan gateway yang hanya menerima pasangan lama. Klien mesti menerangkan algoritma yang sama, bukan yang lebih kuat.

Tetapkan nilai itu secara eksplisit dalam NEVPNProtocolIKEv2. Nilai lalai mungkin lebih luas atau lebih sempit daripada profil yang anda ganti, dan perbezaannya hanya muncul apabila jabat tangan gagal.

Cadangan anak gagal lebih lewat dan lebih senyap

Konfigurasikan juga persatuan keselamatan anak, bukan hanya yang IKE. Apabila hanya parameter IKE sepadan, terowong mengesahkan diri dan kemudian tidak membawa trafik, iaitu kegagalan yang jauh lebih senyap daripada penolakan. Tetapkan penyulitan, integriti, kumpulan dan jangka hayat anak dalam langkah yang sama. Kekalkan jangka hayat klien pada atau di bawah nilai gateway, kerana berdegil mahu lebih panjang menghasilkan mesej no proposal chosen yang sama daripada punca berbeza. Ketidakpadanan di situ kelihatan sama seperti ketidakpadanan IKE dalam log.

Semak sama ada profil mengesahkan dengan sijil atau rahsia kongsi semasa anda dalam konfigurasi. Penolakan cadangan dan penolakan pengesahan muncul pada baris berbeza, dan membetulkan yang salah menelan sehari. Uji dengan sambungan baharu selepas setiap perubahan, satu pemboleh ubah pada satu masa, kerana keadaan cache menyembunyikan parameter mana yang bergerak.

Biarkan suite lama hanya selagi ia diperlukan

Menyemat SHA-1 dengan kumpulan 1024 bit ialah jambatan, bukan destinasi. Kedua-duanya sudah usang, dan klien lebih baharu mungkin menolaknya terus, yang bermaksud profil akan gagal pada peranti seterusnya tanpa sebarang perubahan di pihak anda. Anggap penyematan itu sementara dan nyatakan demikian dalam rekod.

Jika strongSwan milik anda, tambah cadangan moden dan biarkan kedua-dua hujung berunding ke atas sementara entri lama kekal untuk peranti lama. Baca output status daemon untuk melihat suite mana yang sebenarnya digunakan oleh setiap sambungan. Kemudian buang penyematan di sebelah klien setelah pasangan moden disahkan. Terowong yang naik tidak cukup bukti, kerana ia boleh naik pada suite yang anda cuba persarakan. Dokumentasi IKEv2 strongSwan menerangkan sintaks cadangan dan penanda strict.