Apa saja isi proposal IPsec? Bidang IKE dan ESP

IKE dimulai, kedua peer mengumumkan AES, dan terowongan tetap gagal dengan NO_PROPOSAL_CHOSEN. Log menyebut proposalnya tetapi tidak menyebut bidang yang tidak cocok. Proposal adalah satu tawaran utuh, dan satu bidang yang tidak kompatibel membatalkan seluruh kombinasi, bukan hanya baris itu. Membacanya sebagai sekantong pilihan algoritme yang mandiri adalah alasan biasa mengapa ketidakcocokan tetap tak terlihat.

Dua negosiasi dengan daftar proposal terpisah

IKEv2 membangun dua asosiasi keamanan. Yang pertama adalah IKE SA, yang melindungi pertukaran kontrol itu sendiri, dan yang kedua adalah CHILD SA, yang membawa lalu lintas Anda melalui ESP. Masing-masing punya daftar proposal sendiri, dan satu peer bisa menerima yang satu dan menolak yang lain.

Pemisahan itu menjelaskan kebingungan yang umum: IKE SA yang berfungsi hanya membuktikan bahwa algoritme kanal kontrol cocok. Jika proposal CHILD gagal, terowongan tidak membawa satu paket pun meskipun fase pertama selesai dan log terlihat sehat di bagian atas.

Urutan di dalam tiap daftar juga penting. Responder memilih dari tawaran terurut milik inisiator, jadi memindahkan entri yang luas kompatibel di atas entri sempit mengubah kumpulan mana yang dipasang tanpa mengubah satu pun nama algoritme. Patok urutan itu di konfigurasi daripada mengandalkan nilai bawaan. Urutan yang stabil juga membuat perbandingan log antarsitus bermakna.

Bidang mana milik proposal mana

Himpunan bidangnya kecil, tetapi tidak identik pada kedua negosiasi. Baca tabel baris demi baris, karena bidang di satu kolom bisa tidak ada di kolom lain. Sintaksnya berbeda menurut implementasi; dokumentasi proposal strongSwan adalah satu rujukan konkret.

Bidang enkripsi menyebut cipher dan, pada sebagian besar sintaks, panjang kuncinya. Bidang integritas menyebut hash yang dipakai untuk mengautentikasi teks tersandi, dan PRF menyebut fungsi yang menurunkan materi kunci bagi IKE SA. Grup DH menetapkan materi rahasia bersama yang baru, karena itulah ia muncul di kedua sisi tetapi untuk tujuan berbeda.

Nomor urut yang diperluas hanya milik jalur data. Nomor itu memperlebar ruang urut dan dinegosiasikan sebagai bagian dari proposal CHILD, jadi ketidakcocokan di sana menolak tawaran CHILD sementara IKE SA tetap utuh.

Bagaimana satu tawaran utuh dipilih

Setiap proposal adalah himpunan, dan responder mencari himpunan yang setiap bidang wajibnya dapat diterima. Dua daftar bisa sama-sama memuat AES dan SHA-256 dan tetap tidak punya entri yang kompatibel, karena panjang kunci, PRF, atau grup DH berbeda. Perbandingan terjadi per proposal, bukan per algoritme.

Bila tidak ada yang cocok, responder mengirim NO_PROPOSAL_CHOSEN dengan tipe SA yang gagal. Baca daftar proposal mana yang dirujuk pemberitahuan itu sebelum menyunting konfigurasi; mengubah algoritme ESP ketika proposal IKE ditolak membuang satu siklus penelusuran masalah.

Perilaku pemilihan perlu diketahui saat menyetel profil. Sebagian implementasi mengutamakan urutan inisiator, yang lain menyusun ulang menurut kebijakan lokal, jadi kumpulan yang berfungsi antara dua vendor bisa hilang ketika Anda membalik sisi mana yang memulai koneksi.

AEAD menghapus satu bidang, bukan menambahkannya

AES-GCM dan ChaCha20-Poly1305 mengautentikasi dan menyandi dalam satu operasi. Ketika salah satunya dipilih untuk ESP, algoritme integritas tidak dinegosiasikan terpisah, karena konstruksi AEAD sudah mencakupnya. Karena itu proposal yang memasangkan AES-GCM dengan SHA-256 paling banter mubazir dan paling buruk ditolak.

PRF tetap terpisah di sisi IKE, karena ia menurunkan kunci untuk kanal kontrol, bukan melindungi muatan. Itulah sebabnya proposal IKE dapat secara sah memadukan cipher AEAD dengan PRF dan grup DH, sedangkan proposal ESP yang sepadan hanya mencantumkan cipher AEAD dan grup PFS opsional.

Panjang kunci adalah bagian dari token enkripsi, jadi AES-128-GCM dan AES-256-GCM adalah tawaran berbeda. Profil yang disalin dari panduan yang mengasumsikan kunci 256-bit tidak akan cocok dengan titik akhir yang dikonfigurasi untuk 128-bit, meskipun kedua baris menyebut AES-GCM. Dua peer bisa sepakat soal keluarga cipher dan tetap saling menolak karena angka setelah tanda hubung.

Baca SA yang terpasang, bukan konfigurasinya

Daftar proposal yang dikonfigurasi adalah tawaran; SA yang terpasang adalah hasilnya. Di strongSwan dan kernel Linux, kedua tampilan tersedia:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas mencetak algoritme yang dinegosiasikan per SA, termasuk apakah CHILD memakai AEAD. ip xfrm state menunjukkan apa yang benar-benar dipasang kernel, dan di situlah Anda memastikan bahwa pembaruan kunci tidak jatuh kembali ke kumpulan yang berbeda dari yang Anda dokumentasikan.

Simpan keluaran itu di samping konfigurasi setelah perbaikan. Ketika pembaruan klien mengubah nilai bawaannya, kumpulan yang tercatat memberi Anda garis dasar untuk dibandingkan, dan perbandingan menunjuk bidang yang bergeser alih-alih memulai penyelidikan dari awal.