Cara membaca pertukaran IKEv2 pertama dalam tangkapan paket

Tangkapan yang diambil di tengah sesi adalah alasan biasa sebuah jejak IKEv2 tampak seperti derau, karena kedua pihak sudah memperbarui kunci atau bertukar muatan terenkripsi saat perekaman dimulai. Mulailah dari percobaan koneksi baru saja, sehingga pesan pertama dalam berkas adalah pesan yang membuka negosiasi. Urutan pembacaan di bawah ini mengasumsikan hal itu dan menandai titik ketika sebuah paket berhenti membuktikan apa pun tentang ujung jauh. Melewati langkah itu adalah cara terowongan yang berfungsi didiagnosis sebagai port yang diblokir.

Pastikan Anda melihat pertukaran pembuka

Negosiasi IKEv2 dimulai dengan IKE_SA_INIT, tipe pertukaran 34, ID pesan 0. Inisiator memilih SPI bukan nol, dan SPI responder bernilai nol pada permintaan pertama itu serta bukan nol pada balasannya. Tiga fakta itu memisahkan percobaan baru dari pembaruan kunci atau dari pesan IKE_AUTH yang kebetulan berada di puncak sebuah tangkapan.

Bidang tajuk dapat dibaca, begitu pula muatan proposal, pertukaran kunci, dan nonce. Dapat dibaca bukan berarti terautentikasi: belum ada pihak yang membuktikan identitas pada titik ini, dan nilai privat Diffie-Hellman tidak pernah muncul di kabel.

Cetak bidang-bidang itu sebagai tabel alih-alih menggulir panel dekode, karena pengiriman ulang dan SPI yang tidak cocok menjadi jelas dalam kolom.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Baca keluarannya berpasangan. Permintaan dengan ID pesan 0 yang diikuti balasan dengan ID sama dan SPI responder bukan nol adalah satu pertukaran, bahkan ketika muncul tiga kali karena permintaan dikirim ulang. Tiga permintaan identik bukan tiga login, dan memperlakukannya begitu adalah cara orang menyimpulkan klien berputar-putar padahal hanya sabar. Urutkan menurut ID pesan, lalu menurut cap waktu, dan seluruh percakapan menyusut menjadi daftar percobaan yang pendek.

Baca penolakan sebelum membaca keberhasilan

Balasan tidak otomatis berarti kemajuan. Responder dapat menjawab dengan notifikasi cookie dan mengharapkan inisiator mencoba lagi, atau dengan INVALID_KE_PAYLOAD yang menyebut grup yang lebih mau ia terima. Keduanya datang sebagai pesan IKE yang terbentuk baik, dan keduanya tampak seperti pertukaran yang selesai bagi filter yang hanya menghitung paket.

Buka muatan notifikasi dan baca tipenya sebelum apa pun. Tantangan cookie berarti responder mempertahankan diri dari alamat sumber palsu, dan klien harus mengirim ulang dengan cookie dilampirkan. Grup yang tidak valid berarti kedua proposal tidak sepakat, yang tidak akan berubah oleh berapa kali pun percobaan ulang sampai konfigurasi salah satu pihak bergeser.

Hanya IKE_AUTH, pertukaran kedua, yang membawa identitas terenkripsi dan muatan autentikasi. Pertukaran IKE_SA_INIT yang selesai karena itu memberi tahu Anda bahwa kedua pihak sepakat soal algoritme dan kunci turunan, dan sama sekali tidak memberi tahu apakah kredensial akan diterima. Perkirakan juga dua pesan di sana, dan perkirakan keduanya tidak transparan tanpa kunci sesi.

Port 4500 bukan satu protokol

UDP 500 biasanya membawa pertukaran pembuka. Setelah deteksi NAT berjalan, IKE pindah ke 4500 dan memberi awalan penanda nol empat bita non-ESP pada setiap pesan. ESP yang dienkapsulasi pada port yang sama justru dimulai dengan SPI ESP bukan nol, dan keepalive NAT satu bita adalah bentuk ketiga yang muncul ketika tidak ada hal lain yang terjadi.

Filter yang hanya mencocokkan port mencampur ketiganya, dan itulah sebabnya "ada lalu lintas di 4500" begitu sedikit menyelesaikan. Pisahkan tampilan menurut protokol sebelum menyimpulkan apa pun tentang ujung jauh.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Kesenyapan menggambarkan titik pengamatan

Permintaan tanpa balasan menetapkan tepat satu hal: pada titik tangkapan itu tidak ada balasan yang muncul. Penyaringan, rute yang mengirim jawaban ke tempat lain, responder yang tak terjangkau, atau responder yang tidak menyukai proposal semuanya menghasilkan hasil kosong yang sama, dan probe UDP generik tidak akan memisahkannya.

ICMP tak terjangkau adalah bukti jenis lain. Baca paket yang dikutip di dalamnya dan kenali perangkat mana yang memancarkannya, karena penolakan administratif sebuah router bukan galat terautentikasi dari ujung jauh.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Korelasikan percobaan yang sama dengan log sisi server di tempat Anda diizinkan membacanya. Apakah permintaan sampai, apakah layanan menjawab, dan di mana jawaban berhenti? Ketiga jawaban itu mengarahkan Anda ke masalah jalur atau masalah kebijakan, dan biayanya lebih murah daripada memutar kredensial untuk keempat kalinya.