การส่งซ้ำของ TCP เทียบกับการทิ้งการเล่นซ้ำของ IPsec: อ่านแต่ละชั้น

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

สามตัวนับที่ไม่เคยวัดเหตุการณ์เดียวกัน

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

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

ตัววิเคราะห์เห็นอะไรและไม่เห็นอะไร

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

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

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

ตัวนับ ESP อาศัยอยู่ในสถานะเคอร์เนล

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

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

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

จุดสังเกตเปลี่ยนคำตอบตรงไหน

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

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

อ่านตัวเลขตามลำดับที่ถูกต้อง

เริ่มที่ชั้นที่ถามคำถาม คำเตือน TCP ตอบจากแคปเจอร์ TCP และการทิ้ง ESP ตอบจากตัวนับสมาคมความปลอดภัยบนเกตเวย์ จากนั้นจึงถามว่าสองมุมมองอธิบายแพ็กเก็ตเดียวกันหรือไม่ ข้อสรุปที่ต้องใช้ทั้งสองชั้นควรระบุทั้งสอง เพราะข้ออ้างเรื่องอุโมงค์ที่อาศัยเพียงเครื่องหมาย TCP เป็นการเดา

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