SA ลูกของ IPsec ทำงานอยู่ แต่ตัวนับแพ็กเก็ตยังเป็นศูนย์

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

ตัวนับศูนย์พิสูจน์อะไรได้จริง

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

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

ส่งโฟลว์ที่คุณอธิบายได้ก่อนจะส่ง

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

ที่อยู่ต้นทางคือค่าที่คนมักข้ามไป และเป็นตัวที่ทำลายการทดสอบบ่อยที่สุด แล็ปท็อปที่มีที่อยู่แบบมีสาย ที่อยู่ Wi-Fi และที่อยู่ของอุโมงค์สามารถผูกที่อยู่ใดก็ได้ในนั้นขึ้นกับการค้นหาเส้นทาง และมีเพียงที่เดียวเท่านั้นที่อาจอยู่ในช่วงที่เจรจาไว้ ใช้เครื่องมือที่ให้คุณปักหมุดต้นทาง เช่น ping -I 10.1.0.5 10.2.0.9 หรือ curl --interface 10.1.0.5 เพื่อให้แพ็กเก็ตเลือกที่อยู่อื่นอย่างเงียบ ๆ ไม่ได้ เมื่อการรันที่ปักหมุดขยับตัวนับและการรันที่ไม่ได้ปักหมุดไม่ขยับ คุณพบปัญหาเส้นทางไม่ใช่ปัญหา IPsec

จะอ่านตัวเลขใด และมันอยู่ที่ไหน

บน Linux ip -s xfrm state พิมพ์แต่ละความสัมพันธ์พร้อมบรรทัด lifetime current: ที่ยอดรวมไบต์และยอดรวมแพ็กเก็ตเป็นของ SA นั้นเท่านั้น ตามด้วยบรรทัด stats: สำหรับการนับเล่นซ้ำและข้อผิดพลาด บนฝ่าย strongSwan swanctl --list-sas พิมพ์บรรทัด in หนึ่งบรรทัดและบรรทัด out หนึ่งบรรทัดต่อลูกที่ติดตั้งไว้ แต่ละบรรทัดลงท้ายด้วยจำนวนไบต์และจำนวนแพ็กเก็ต เครื่องมือ stroke รุ่นเก่าเรียกคู่นั้นว่า bytes_i และ bytes_o อ่านสองทิศทางแยกกัน เพราะทิศที่ยังแบนอยู่คือสิ่งที่พบ การบวกเข้าด้วยกันจะซ่อนความไม่สมมาตรที่คุณกำลังมองหาพอดี

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

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

เส้นทาง ตัวเลือก และที่ที่แพ็กเก็ตถือกำเนิด

เปรียบเทียบสามสิ่งเคียงกัน: เส้นทางที่เคอร์เนลเลือกสำหรับปลายทางของคุณ นโยบายที่พาทราฟฟิกเข้าอุโมงค์ และคู่ตัวเลือกที่ลูกเจรจาไว้ ip route get 10.2.0.9 from 10.1.0.5 ระบุอินเทอร์เฟซและต้นทางที่เคอร์เนลจะใช้ ซึ่งมักไม่ใช่คู่ที่คุณสันนิษฐาน ip xfrm policy แสดงเทมเพลตและตัวเลือกที่ติดตั้งไว้ในเครื่อง ขณะที่ swanctl --list-sas แสดงสิ่งที่ฝ่ายตรงข้ามตกลง การค้นหาที่ส่งแพ็กเก็ตออกทางอินเทอร์เฟซจริงไม่เคยไปถึงนโยบายเลย ตัวนับจึงขยับไม่ได้

ความไม่ตรงกันมาในหลายรูปแบบที่ดูเหมือนกันเมื่อมองจากตัวนับ ปลายทาง IPv6 ที่อยู่นอกตัวเลือก IPv4 ที่อยู่ต้นทางจากซับเน็ตผิด และนโยบายที่แคบกว่าลูก ล้วนให้ศูนย์เหมือนกัน แก้สาเหตุที่แคบที่สุดก่อน เพราะการขยายตัวเลือกเพียงเพื่อเลื่อนตัวเลขจะเปลี่ยนสิ่งที่อุโมงค์ปกป้อง

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

การเปลี่ยนแปลงเดียวที่ย้อนกลับได้และรายงานที่ผ่านการตรวจทาน

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

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