iOS menolak tunnel strongSwan Anda: bandingkan proposal IKE

Tidak ada apa pun pada sertifikat atau alamat yang menjelaskan mengapa iPhone yang tahun lalu terhubung ke strongSwan kini gagal. Tidak ada yang harus berubah pada alamat, kunci yang dibagikan sebelumnya, atau identitas klien. Yang bergeser adalah daftar transformasi yang bersedia dinegosiasikan oleh klien bawaan ponsel, dan begitu daftar itu berhenti bertumpang tindih dengan daftar server, pertukaran berakhir sebelum identitas siapa pun diperiksa.

Baris log yang menentukan

Naikkan tingkat log untuk koneksi itu dan temukan dua entri yang menentukan hasilnya: apa yang ditawarkan ponsel dan apa yang dipilih server. Jika log berakhir tanpa proposal terpilih dan melaporkan bahwa tidak ada yang cocok, autentikasi tidak pernah dicoba. Sertifikat baru dan kata sandi baru tidak mengubah apa pun pada titik itu, karena keduanya dipakai pada tahap yang lebih akhir. Keduanya tidak dapat memengaruhi hasil yang sudah diputuskan sebelum identitas diperiksa.

Pisahkan kedua bentuk kegagalan sebelum menyunting apa pun. Tidak ada penyuntingan transformasi yang menyelamatkan kredensial yang ditolak, dan tidak ada perbaikan kredensial yang menyelamatkan transformasi yang ditolak. Entri log yang menyebut proposal terpilih memberi tahu Anda yang mana dari keduanya. Tanpa entri itu, Anda menebak.

Baris terpilih menyebut proposal berdasarkan himpunan transformasinya, bukan label yang ramah. Bandingkan bidang enkripsi, integritas, dan grup pada baris itu dengan daftar yang dikirim ponsel, karena ketidakcocokan pada satu bidang saja sudah cukup untuk kalah.

Apa yang berubah di ponsel

Satu rilis iOS memangkas algoritme yang bersedia dipakai kliennya. Hash integritas yang lemah, grup Diffie-Hellman kecil, dan proposal yang mencantumkan opsi lama lebih dulu tidak lagi dapat diterima.

Daftar yang lebih panjang tidak lebih aman di sini. Pemilihan mengikuti himpunan yang diterima ponsel dan urutan preferensinya sendiri, jadi server yang mengumumkan katalog luas tetap bisa kalah dalam negosiasi ketika entri modern bukan yang dipilih. Utamakan daftar pendek dengan entri modern di depan. Daftar panjang yang dibuka dengan opsi lama mengundang persis kegagalan yang ingin Anda hindari. Himpunan yang diterima adalah batasan luar yang bergeser setiap kali klien diperbarui, jadi konfigurasi yang berhasil kemarin adalah bukti tentang kemarin.

Satu pasangan yang masih bernegosiasi

Untuk ponsel saat ini satu kombinasi modern sudah cukup. Satu pasangan yang bernegosiasi tampak seperti ini:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

Baris ike membawa enkripsi, integritas, dan grup Diffie-Hellman yang dipakai selama pertukaran kunci berlangsung. Baris esp hanya mencakup kanal data, karena grup sudah ditetapkan sebelum baris itu berlaku. Muat ulang koneksi atau jalankan ulang daemon, lalu sambungkan ponsel lagi. Pertahankan nilai grup itu hanya jika setiap klien yang Anda layani masih menerimanya, dan jangan memperluas proposal untuk semua orang hanya karena satu peer lama membutuhkan lebih banyak.

Tiga tempat memperbaikinya, satu biasanya tertutup

• Satu proposal modern untuk setiap peer. Benar bila semua klien adalah ponsel dan desktop terkini. Ini menghapus transformasi lama alih-alih bernegosiasi di sekitarnya.
• Definisi koneksi kedua untuk klien Apple. Menjaga satu peer lama tetap hidup sambil memberi ponsel proposal yang diterimanya. Ini memerlukan satu blok koneksi lagi dan membuat pengecualian terlihat.
• Mengganti klien. Jarang terbuka bagi Anda: ketika sistem manajemen atau aplikasi memasok profil, tidak ada editor proposal yang bisa disentuh, dan klien bawaan tidak mengekspos satu pun.

Pilih opsi kedua ketika perangkat di luar kendali Anda tidak dapat diperbarui. Pilih yang pertama ketika Anda dapat memensiunkan peer lama dan lebih suka membawa satu kebijakan.

Apa pun pilihannya, pilihan itu terlihat dalam konfigurasi, dan itulah intinya. Fallback senyap yang bernegosiasi turun ke transformasi lama lebih buruk daripada blok eksplisit, karena tidak ada tinjauan yang akan pernah memunculkannya.

Buktikan, lalu catat

Sambungkan ulang dan periksa tiga fakta terpisah di server: proposal dipilih, koneksi tampil sebagai established, dan klien menerima alamat. Jabat tangan yang established tanpa alamat jarak jauh menunjuk ke pool atau pemilih lalu lintas, dan itu termasuk perubahan tersendiri. Menangani keduanya bersama-sama membuat negosiasi yang sudah selesai tampak belum selesai.

Catat himpunan transformasi yang diterima, kapan Anda mengubahnya, dan build klien mana yang Anda verifikasi. Pembaruan berikutnya dapat menggeser persyaratan lagi, dan nilai yang berhasil adalah hal pertama yang Anda inginkan di samping nilai baru.