วิธีอ่านการแลกเปลี่ยน IKEv2 ครั้งแรกในการดักจับแพ็กเก็ต

การดักจับที่เริ่มกลางเซสชันเป็นสาเหตุปกติที่ทำให้ร่องรอย IKEv2 ดูเหมือนสัญญาณรบกวน เพราะคู่สนทนากำลังต่ออายุคีย์หรือแลกเปลี่ยนเพย์โหลดที่เข้ารหัสอยู่แล้วเมื่อเริ่มบันทึก เริ่มจากการพยายามเชื่อมต่อใหม่แทน เพื่อให้ข้อความแรกในไฟล์เป็นข้อความที่เปิดการเจรจา ลำดับการอ่านด้านล่างถือว่าอย่างนั้น และทำเครื่องหมายจุดที่แพ็กเก็ตหยุดพิสูจน์สิ่งใดเกี่ยวกับปลายทางไกล การข้ามขั้นตอนนั้นคือเหตุที่อุโมงค์ที่ทำงานอยู่ถูกวินิจฉัยว่าเป็นพอร์ตที่ถูกบล็อก

ยืนยันว่าคุณกำลังดูการแลกเปลี่ยนครั้งแรก

การเจรจา IKEv2 เริ่มด้วย IKE_SA_INIT ชนิดการแลกเปลี่ยน 34 ID ข้อความ 0 ผู้เริ่มจะเลือก SPI ที่ไม่เป็นศูนย์ และ SPI ของผู้ตอบเป็นศูนย์ในคำขอแรกนั้นและไม่เป็นศูนย์ในคำตอบ สามข้อเท็จจริงนี้แยกการพยายามใหม่จากการต่ออายุคีย์หรือจากข้อความ IKE_AUTH ที่บังเอิญอยู่บนสุดของการดักจับ

ฟิลด์ส่วนหัวอ่านได้ และเพย์โหลดข้อเสนอ การแลกเปลี่ยนคีย์ และ nonce ก็อ่านได้เช่นกัน การอ่านได้ไม่ใช่การยืนยันตัวตน: ยังไม่มีฝ่ายใดพิสูจน์ตัวตน ณ จุดนี้ และค่าส่วนตัวของ Diffie-Hellman ไม่เคยปรากฏบนสาย

พิมพ์ฟิลด์เป็นตารางแทนการเลื่อนแผงถอดรหัส เพราะการส่งซ้ำและ SPI ที่ไม่ตรงกันจะเห็นชัดในคอลัมน์

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

อ่านผลลัพธ์เป็นคู่ คำขอที่มี ID ข้อความ 0 ตามด้วยคำตอบที่พก ID เดียวกันและ SPI ของผู้ตอบที่ไม่เป็นศูนย์คือการแลกเปลี่ยนหนึ่งครั้ง แม้จะปรากฏสามครั้งเพราะคำขอถูกส่งซ้ำ คำขอที่เหมือนกันสามรายการไม่ใช่การล็อกอินสามครั้ง และการตีความเช่นนั้นคือเหตุที่ผู้คนสรุปว่าไคลเอนต์วนลูปทั้งที่เพียงแค่อดทน เรียงตาม ID ข้อความ แล้วตามเวลาที่บันทึก และบทสนทนาทั้งหมดจะย่อเหลือรายการการพยายามสั้น ๆ

อ่านการปฏิเสธก่อนอ่านความสำเร็จ

คำตอบไม่ใช่ความคืบหน้าโดยอัตโนมัติ ผู้ตอบอาจตอบด้วยการแจ้งเตือน cookie และคาดว่าผู้เริ่มจะลองใหม่ หรือด้วย INVALID_KE_PAYLOAD ที่ระบุกลุ่มที่ยอมรับแทน ทั้งสองมาในรูปข้อความ IKE ที่ถูกต้อง และทั้งสองดูเหมือนการแลกเปลี่ยนที่เสร็จแล้วสำหรับตัวกรองที่นับแพ็กเก็ตเท่านั้น

เปิดเพย์โหลดการแจ้งเตือนและอ่านชนิดก่อนสิ่งอื่นใด cookie challenge หมายความว่าผู้ตอบกำลังป้องกันตนเองจากที่อยู่ต้นทางปลอม และไคลเอนต์ต้องส่งใหม่พร้อมแนบ cookie กลุ่มที่ไม่ถูกต้องหมายความว่าข้อเสนอทั้งสองไม่ตรงกัน ซึ่งจะไม่เปลี่ยนไม่ว่าจะลองใหม่กี่ครั้งจนกว่าการตั้งค่าของฝ่ายใดฝ่ายหนึ่งจะเปลี่ยน

มีเพียง IKE_AUTH ซึ่งเป็นการแลกเปลี่ยนครั้งที่สองที่พาตัวตนที่เข้ารหัสและเพย์โหลดการยืนยันตัวตนมาด้วย ดังนั้น IKE_SA_INIT ที่เสร็จสมบูรณ์บอกคุณว่าทั้งสองฝ่ายเห็นพ้องเรื่องอัลกอริทึมและคีย์ที่ได้มา และไม่บอกอะไรเลยว่าข้อมูลรับรองจะได้รับการยอมรับหรือไม่ คาดว่าจะมีสองข้อความที่นั่นด้วย และคาดว่าทั้งคู่จะทึบแสงหากไม่มีคีย์เซสชัน

พอร์ต 4500 ไม่ใช่โปรโตคอลเดียว

โดยปกติ UDP 500 เป็นตัวพาการแลกเปลี่ยนครั้งแรก เมื่อตรวจพบ NAT แล้ว IKE จะย้ายไปที่ 4500 และใส่เครื่องหมายศูนย์สี่ไบต์ที่ไม่ใช่ ESP ไว้หน้าทุกข้อความ ESP ที่ห่อหุ้มบนพอร์ตเดียวกันกลับเริ่มด้วย ESP SPI ที่ไม่เป็นศูนย์ และ NAT keepalive หนึ่งไบต์เป็นรูปแบบที่สามที่ปรากฏเมื่อไม่มีสิ่งอื่นเกิดขึ้น

ตัวกรองที่จับคู่เฉพาะพอร์ตรวมทั้งสามอย่างเข้าด้วยกัน ดังนั้น "มีทราฟฟิกบน 4500" จึงตัดสินได้น้อยมาก แยกมุมมองตามโปรโตคอลก่อนสรุปสิ่งใดเกี่ยวกับปลายทางไกล

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

ความเงียบอธิบายจุดสังเกต

คำขอที่ไม่มีการตอบรับยืนยันเพียงสิ่งเดียว: ณ จุดดักจับนั้นไม่ปรากฏคำตอบใด การกรอง เส้นทางที่ส่งคำตอบไปที่อื่น ผู้ตอบที่เข้าถึงไม่ได้ หรือผู้ตอบที่ไม่ชอบข้อเสนอ ล้วนให้ผลว่างแบบเดียวกัน และการตรวจสอบ UDP ทั่วไปจะแยกสิ่งเหล่านี้ไม่ออก

ICMP ที่เข้าถึงไม่ได้เป็นหลักฐานอีกชนิดหนึ่ง อ่านแพ็กเก็ตที่อ้างอิงอยู่ภายในและระบุว่าอุปกรณ์ใดส่งออกมา เพราะการปฏิเสธเชิงบริหารของเราเตอร์ไม่ใช่ข้อผิดพลาดที่ยืนยันตัวตนได้จากปลายทางไกล

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

เชื่อมโยงการพยายามเดียวกันกับบันทึกฝั่งเซิร์ฟเวอร์ในที่ที่คุณได้รับอนุญาตให้อ่าน คำขอมาถึงหรือไม่ บริการตอบหรือไม่ และคำตอบหยุดที่ใด คำตอบสามข้อนั้นส่งคุณไปสู่ปัญหเส้นทางหรือปัญหานโยบาย และมีต้นทุนน้อยกว่าการหมุนเวียนข้อมูลรับรองเป็นครั้งที่สี่