IPsec หลายซับเน็ตทำทราฟฟิกขากลับหาย? นับ reqid

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

แยกอาการก่อนเปลี่ยนแปลงสิ่งใด

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

อย่าเริ่มที่ MTU MTU ที่ผิดทำให้เกิดการหยุดชะงักและอาการแตกกระจาย ไม่ใช่การแยกทิศทางที่สะอาดพร้อมตัวนับขาออกที่เพิ่มขึ้น

อ่านฐานข้อมูลนโยบายและฐานข้อมูลสถานะ

บน Linux รายการนโยบายเป็นตัวตัดสินการเข้ารหัส ดังนั้น นโยบายที่ตรงกัน ไม่ใช่เส้นทาง คือสิ่งที่นำแพ็กเก็ตเข้าอุโมงค์ รัน ip xfrm policy เพื่อดูตัวเลือก ทิศทาง ลำดับความสำคัญ และเทมเพลตของแต่ละรายการ และ ip xfrm state เพื่อดูสมาคมที่สร้างขึ้นพร้อม reqid ของมัน นโยบายและสมาคมเชื่อมกันด้วย reqid นั้น

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

ความไม่สมมาตรแบบคลาสสิก: reqid เดียวสำหรับหลายซับเน็ต

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

การแก้ไขคือการเปลี่ยนการกำหนดค่า ไม่ใช่กฎไฟร์วอลล์: generate_policy unique; ให้แต่ละนโยบายมี reqid ของตัวเอง สมาคมต่อนโยบายของคู่ค้าจึงมีคู่ที่ตรงกัน ใช้มัน เจรจากันใหม่ และนับ reqid ที่แตกต่างสำหรับซับเน็ตที่คาดหวังก่อนประกาศความสำเร็จ

ถ้าสองซับเน็ตยังใช้ reqid เดียวกันขณะที่อีกฝั่งคาดหวังสอง คุณพบความไม่สมมาตรแล้ว บันทึกการแมปไว้ เพราะมันคือหลักฐานว่าการเปลี่ยนแปลงครั้งต่อไปแก้ไขหรือรักษาไว้

ตัวเลือกมาจากการเจรจา ไม่ใช่จากการกำหนดค่าของคุณ

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

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

ตรวจสอบตามลำดับนี้ และรู้วิธีถอยกลับ

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

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