Apakah yang terkandung dalam cadangan IPsec? Medan IKE dan ESP

IKE bermula, kedua-dua rakan mengumumkan AES, dan terowong masih gagal dengan NO_PROPOSAL_CHOSEN. Log menamakan cadangan tetapi bukan medan yang tidak sepadan. Cadangan ialah satu tawaran lengkap, dan satu medan tidak serasi membatalkan seluruh gabungan, bukan hanya baris itu. Membacanya sebagai beg pilihan algoritma bebas ialah sebab biasa ketakpadanan itu kekal tidak kelihatan.

Dua rundingan dengan senarai cadangan berasingan

IKEv2 membina dua persatuan keselamatan. Yang pertama ialah IKE SA, yang melindungi pertukaran kawalan itu sendiri, dan yang kedua ialah CHILD SA, yang membawa trafik anda melalui ESP. Setiap satu mempunyai senarai cadangan sendiri, dan rakan boleh menerima satu dan menolak yang lain.

Pemisahan itu menjelaskan kekeliruan biasa: IKE SA yang berfungsi hanya membuktikan bahawa algoritma saluran kawalan sepadan. Jika cadangan CHILD gagal, terowong tidak membawa satu paket pun walaupun fasa pertama selesai dan log kelihatan sihat di bahagian atas.

Urutan dalam setiap senarai juga penting. Responden memilih daripada tawaran tersusun pemula, jadi memindahkan entri yang luas serasi ke atas entri sempit mengubah suite mana yang dipasang tanpa mengubah satu nama algoritma pun. Pin urutan itu dalam konfigurasi daripada bergantung pada nilai lalai. Urutan yang stabil juga menjadikan perbandingan log antara tapak bermakna.

Medan mana milik cadangan mana

Set medan itu kecil, tetapi ia tidak serupa dalam kedua-dua rundingan. Baca jadual baris demi baris, kerana medan dalam satu lajur mungkin tiada dalam lajur yang lain. Sintaks berbeza mengikut pelaksanaan; dokumentasi cadangan strongSwan ialah satu rujukan konkrit.

Medan penyulitan menamakan sifer dan, dalam kebanyakan sintaks, panjang kuncinya. Medan integriti menamakan hash yang digunakan untuk mengesahkan teks sifer, dan PRF menamakan fungsi yang memperoleh bahan kunci untuk IKE SA. Kumpulan DH menetapkan bahan rahsia bersama yang baharu, sebab itulah ia muncul di kedua-dua belah tetapi untuk tujuan berbeza.

Nombor jujukan lanjutan hanya milik laluan data. Ia meluaskan ruang jujukan dan dirundingkan sebagai sebahagian daripada cadangan CHILD, jadi ketakpadanan di situ menolak tawaran CHILD sementara IKE SA kekal tidak tersentuh.

Bagaimana satu tawaran lengkap dipilih

Setiap cadangan ialah satu set, dan responden mencari set yang setiap medan wajib boleh diterima. Dua senarai boleh kedua-duanya mengandungi AES dan SHA-256 dan masih tiada entri serasi, kerana panjang kunci, PRF atau kumpulan DH berbeza. Perbandingan berlaku setiap cadangan, bukan setiap algoritma.

Apabila tiada yang sepadan, responden menghantar NO_PROPOSAL_CHOSEN dengan jenis SA yang gagal. Baca senarai cadangan mana yang dirujuk oleh pemberitahuan sebelum mengedit konfigurasi; menukar algoritma ESP apabila cadangan IKE ditolak membazirkan satu kitaran penyahpepijatan.

Tingkah laku pemilihan wajar diketahui apabila anda menala profil. Sesetengah pelaksanaan mengutamakan urutan pemula, yang lain menyusun semula mengikut dasar tempatan, jadi suite yang berfungsi antara dua vendor boleh hilang apabila anda membalikkan pihak mana yang memulakan sambungan.

AEAD membuang satu medan dan bukan menambahnya

AES-GCM dan ChaCha20-Poly1305 mengesahkan dan menyulitkan dalam satu operasi. Apabila salah satu dipilih untuk ESP, algoritma integriti tidak dirundingkan secara berasingan, kerana binaan AEAD sudah meliputinya. Oleh itu cadangan yang memasangkan AES-GCM dengan SHA-256 paling baik berlebihan dan paling buruk ditolak.

PRF masih berasingan di sebelah IKE, kerana ia memperoleh kunci untuk saluran kawalan dan bukan melindungi muatan. Itulah sebabnya cadangan IKE boleh menggabungkan sifer AEAD dengan PRF dan kumpulan DH secara sah, manakala cadangan ESP yang sepadan hanya menyenaraikan sifer AEAD dan kumpulan PFS pilihan.

Panjang kunci ialah sebahagian daripada token penyulitan, jadi AES-128-GCM dan AES-256-GCM ialah tawaran berbeza. Profil yang disalin daripada panduan yang menganggap kunci 256-bit tidak akan sepadan dengan titik akhir yang dikonfigurasikan untuk 128-bit, walaupun kedua-dua baris menyebut AES-GCM. Dua rakan boleh bersetuju tentang keluarga sifer dan masih menolak satu sama lain kerana nombor selepas sengkang.

Baca SA yang dipasang, bukan konfigurasi

Senarai cadangan yang dikonfigurasikan ialah tawaran; SA yang dipasang ialah hasilnya. Pada strongSwan dan kernel Linux, kedua-dua paparan tersedia:

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

swanctl --list-sas mencetak algoritma yang dirundingkan bagi setiap SA, termasuk sama ada CHILD menggunakan AEAD. ip xfrm state menunjukkan apa yang sebenarnya dipasang oleh kernel, dan di situlah anda mengesahkan bahawa pembaharuan kunci tidak jatuh kembali kepada suite yang berbeza daripada yang anda dokumentasikan.

Simpan keluaran itu di sebelah konfigurasi selepas pembetulan. Apabila kemas kini klien mengubah nilai lalainya, suite yang direkodkan memberi anda garis dasar untuk perbandingan, dan perbandingan menunjuk kepada medan yang bergerak dan bukan memulakan siasatan dari awal.