IKEv2 bukan satu jabat tangan: IKE SA, autentikasi, lalu CHILD SA

Anda mungkin mengira koneksi IKEv2 adalah satu pertukaran yang berakhir dengan lalu lintas Anda terenkripsi. Setidaknya ada dua, dan yang pertama tidak mengautentikasi siapa pun. Kedua pihak mulai dengan pesan kontrol, menyepakati parameter kriptografis, membuktikan identitas, dan baru setelah itu menegosiasikan keadaan yang membawa paket aplikasi. Urutan itulah yang menjelaskan ketidaksesuaian yang sering dilaporkan orang: gateway menjawab, klien bilang terhubung, tetapi aplikasi privat tetap kehabisan waktu. Berikut apa yang sebenarnya dilakukan tiap tahap, dan apa yang harus benar setelahnya.

Mitos: jika gateway menjawab, Anda terhubung

Jawaban atas pesan pertama membuktikan endpoint dapat dijangkau dan bersedia berbicara. Itu tidak membuktikan akun diterima, rantai sertifikat tervalidasi, atau kebijakan data apa pun terpasang.

Kegagalan itu terjadi kemudian, dan gejalanya berbeda. Penolakan sertifikat atau kegagalan EAP datang setelah pertukaran pertama berhasil, karena itu ping ke UDP 500 dan ikon klien hijau begitu sedikit memberi tahu Anda.

IKE_SA_INIT: sepakati parameter, bukan identitas

Pertukaran pertama membawa proposal untuk asosiasi keamanan IKE: algoritma enkripsi dan integritas, fungsi pseudorandom, dan grup Diffie-Hellman. Kedua pihak juga bertukar nonce, dan tiap sisi menurunkan materi kunci untuk IKE SA dari rahasia bersama yang dihasilkan nilai-nilai itu. Tidak ada apa pun dalam pertukaran ini yang menetapkan siapa pihak lain. Yang ditetapkan adalah bahwa kedua sisi dapat menghitung kunci yang sama dan menyetujui satu proposal. Penanggap yang tidak menyukai satu pun proposal menolak pertukaran di sini, karena itu ketidakcocokan versi atau algoritma tampak seperti server yang mati.

IKE SA yang dibuat pada titik ini melindungi semua pertukaran manajemen berikutnya. Itu tugasnya, dan itu tugas yang berbeda dari melindungi paket Anda.

IKE_AUTH: buktikan identitas, lalu bangun CHILD SA pertama

Pertukaran kedua membawa identitas. Dengan sertifikat, tiap pihak menandatangani dengan kunci privatnya dan menyajikan rantai yang harus divalidasi pihak lain; dengan EAP, penanggap menantang inisiator melalui metode yang dipilih. Di sinilah nama server yang salah, sertifikat kedaluwarsa, atau kata sandi yang ditolak akhirnya muncul.

Dalam kasus normal IKE_AUTH juga menegosiasikan CHILD SA pertama, sehingga perlindungan data disepakati dalam perjalanan pulang-pergi yang sama. Inisiator mengusulkan pemilih lalu lintas, penanggap mempersempit atau menolaknya, dan kunci untuk jalur data diturunkan dari IKE SA. Artinya satu pertukaran bisa gagal di dua tempat yang sangat berbeda: identitas atau kebijakan. Bacalah muatan notifikasi atau galatnya, bukan kegagalan jabat tangan generik, karena perbaikan untuk yang satu adalah sertifikat dan untuk yang lain adalah ketidakcocokan subnet.

Dua SA, dua tugas

Memisahkan keduanya menjelaskan dua perilaku yang tampak seperti bug. Tunnel bisa tampak terbentuk sementara pembaruan kunci gagal di latar belakang, dan CHILD SA dapat diganti tanpa klien kehilangan koneksi.

Di strongSwan, referensi konfigurasi IKEv2 dan swanctl --list-sas menunjukkan kedua tingkat, dan ip xfrm state plus ip xfrm policy menunjukkan apa yang sebenarnya dipasang kernel. Membandingkan kedua tampilan itu adalah cara tercepat untuk melihat apakah negosiasi selesai atau hanya tampak selesai. Jika daemon mencantumkan CHILD SA yang tidak memiliki status di kernel, pemasangan gagal secara diam-diam. Jika kernel menyimpan status yang tidak diketahui daemon, Anda melihat sisa percobaan sebelumnya.

Apa yang masih harus benar setelah tunnel menyala

Pemilih lalu lintas menentukan alamat mana yang tercakup. Jika klien mengusulkan satu subnet dan server mengharapkan yang lain, CHILD SA terpasang tetapi tidak membawa apa pun yang berguna, dan galatnya muncul sebagai masalah perutean, bukan masalah negosiasi. Lalu tumpukan lokal harus bekerja sama: penerusan diaktifkan di tempat host merutekan, rute menunjuk ke tunnel, aturan firewall yang mengizinkan paket terdekapsulasi, dan resolver internal jika ada nama privat. Masing-masing gagal secara terpisah dan tidak ada yang diperbaiki dengan memulai ulang daemon IKE.

Biarkan log terlihat saat Anda mendiagnosis: pertukaran awal, lalu validasi identitas, lalu autentikasi pengguna bila berlaku, lalu pemasangan CHILD, lalu lalu lintas aplikasi. Tahap yang berhenti adalah tahap yang harus diperbaiki, dan kegagalan perutean di kemudian hari tidak pernah menjadi alasan melonggarkan pemeriksaan identitas yang sudah lolos.