ทำไม tcpdump จึงแสดงข้อความธรรมดาของ IPsec เพียงทิศทางเดียว

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

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

จุดดักจับเป็นตัวกำหนดสิ่งที่คุณเห็น

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

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

จับคู่ตัวกรองกับชั้นที่คุณหมายถึง

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

อย่าถือว่าจำนวน UDP 4500 เป็นจำนวนแพ็กเก็ต ESP เพราะ IKE ก็ใช้พอร์ตนั้นสำหรับข้อความคงสภาพ NAT-T และสำหรับการแลกเปลี่ยนที่ห่อหุ้มไว้ ตัวเลขจึงรวมทราฟฟิกที่ไม่ใช่ข้อมูลที่คุณต้องการวัด การแลกเปลี่ยน IKE เริ่มต้นบน UDP 500 ต้องมีตัวกรองของตัวเองหากนั่นคือคำถาม ตัวเลขที่ผสมทราฟฟิกควบคุมกับข้อมูลยังทำให้การประมาณแบนด์วิดท์ผิดพลาดด้วยอัตราที่ไม่ทราบ การนับแยกกันตอบคำถามแยกกัน

จดตัวกรองไว้ข้างคำถามที่มันตอบ «ESP ออกไปจากกล่องเท่าไร» กับ «คำขอเว็บออกจากกล่องหรือไม่» เป็นการวัดที่ต่างกันด้วยตัวกรองที่ต่างกัน และการดักจับครั้งเดียวตัดสินทั้งสองไม่ได้ หากไม่มีบันทึกนั้น สองคนจะเปรียบเทียบตัวเลขที่ไม่เคยนับสิ่งเดียวกัน

สังเกตก่อนการแปลง ไม่ใช่หลัง

หากต้องเห็นข้อความธรรมดาขาออก ให้ย้ายจุดสังเกตไปเร็วขึ้น ก่อนการประมวลผลขาออกของ IPsec NFLOG ให้ฮุกของ Netfilter ซึ่งกฎสามารถคัดลอกแพ็กเก็ตที่เลือกไปยังซ็อกเก็ตในพื้นที่ผู้ใช้ที่ tcpdump อ่านได้ คู่มือการดัมป์ทราฟฟิกของ strongSwan บันทึกวิธีนี้ไว้ด้วยเหตุผลนี้เอง

การจับคู่นโยบายจำกัดกฎไว้เฉพาะทราฟฟิกที่กำลังจะเข้าสู่อุโมงค์ -m policy --pol ipsec --dir out คือสิ่งที่ทำให้กฎเฉพาะเจาะจงแทนที่จะบันทึกทุกแพ็กเก็ตที่กล่องส่ง จากนั้นอ่านกลุ่มบันทึกด้วยการดักจับแบบจำกัด จำนวนสแนปช็อตน้อยและขีดจำกัดขนาดทำให้การวินิจฉัยไม่กลายเป็นคลังทราฟฟิก การดักจับแบบจำกัดยังส่งมอบให้ผู้ตรวจสอบได้ง่ายกว่าโดยไม่ลากเพย์โหลดที่ไม่เกี่ยวข้องมาด้วย ตัดสินจำนวนก่อนเริ่ม ไม่ใช่หลังจากเห็นว่ามาเท่าไร

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

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

การสังเกตพิสูจน์อะไร

NFLOG เป็นเป้าหมายการบันทึก ไม่ใช่การตัดสินใจยอมรับ แพ็กเก็ตที่ปรากฏที่นั่นแสดงว่ามันไปถึงฮุกและตรงกับกฎ มันไม่ได้แสดงว่าตัวกรองภายหลังอนุญาต อุปกรณ์ส่งมัน หรืออีกฝ่ายได้รับอะไร

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

กับดักอีกอย่าง «ข้อความธรรมดา» ในบริบทนี้หมายถึงภายนอกชั้นการเข้ารหัสของ IPsec เซสชัน HTTPS ภายในยังมี TLS ของตัวเอง การดักจับแพ็กเก็ตที่ถอดห่อไม่ได้ถอดรหัส TLS ของแอปพลิเคชัน และการเห็น HTTP ที่อ่านได้ที่นั่นหมายความว่าแอปพลิเคชันไม่เคยใช้ HTTPS

ทำความสะอาดและเปรียบเทียบทั้งสองปลาย

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

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

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