โหมด trap ของ strongSwan: ทำไมอุโมงค์ IPsec จึงรอทราฟฟิก

ไม่มี CHILD SA ปรากฏในเอาต์พุตสถานะ อุโมงค์ดูเหมือนตาย แล้ว ping ไปยังซับเน็ตระยะไกลก็ทำให้มันขึ้นมา ในการตั้งค่า IPsec แบบ on-demand ลำดับนั้นคือการออกแบบ ไม่ใช่ความผิดพลาด นโยบาย trap ติดตั้งตัวเลือกและรอ และแพ็กเก็ตแรกที่ตรงกับมันคือสิ่งที่เริ่ม IKE และการเจรจา CHILD SA

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

อุโมงค์ on-demand ที่ไม่ได้ใช้งานไม่มี CHILD SA ให้แสดง

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

ลำดับนั้นทำให้บันทึกอ่านได้ ก่อนอื่น acquisition มาถึง จากนั้น IKE_SA_INIT และ IKE_AUTH จากนั้น CHILD SA ถ้าบันทึกจบลงทันทีหลัง acquisition ทริกเกอร์ทำงานแล้ว การเจรจาล้มเหลว และคำถามถัดไปเกี่ยวกับข้อมูลรับรอง ข้อเสนอ หรือการเข้าถึง ไม่ใช่เกี่ยวกับ trap

ด้วย backend ของเคอร์เนล Linux คุณเห็นนโยบายได้ก่อนที่ SA ใดจะเกิดขึ้น รัน ip xfrm policy แล้วมองหาตัวเลือกที่มีทิศทาง out และแม่แบบที่ชี้ไปที่การเชื่อมต่อ รายการนั้นคือสถานะ on-demand และการมีอยู่ของมันคือสิ่งแรกที่ต้องยืนยัน

start_action ตัดสินว่ามีอะไรจะรอหรือไม่

ทุก child ใน swanctl.conf มี start_action. start เริ่มทำงานเมื่อโหลดการกำหนดค่า trap ติดตั้งนโยบายและรอ และ none ปล่อยการเริ่มต้นให้อย่างอื่น เฉพาะ trap เท่านั้นที่สร้างพฤติกรรม “ping แล้วมันขึ้น” ที่อธิบายข้างต้น

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

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

นี่คือ เอกสารอ้างอิง swanctl.conf ที่แสดงค่าที่ยอมรับ พร้อมการดำเนินการ close และ DPD แยกต่างหากซึ่งควบคุมสิ่งที่เกิดขึ้นเมื่อมี SA แล้ว

ค้นหาว่าทริกเกอร์ถูกกระตุ้นหรือไม่

เริ่มด้วย swanctl --list-conns และยืนยันว่า child ถูกโหลดด้วยการกระทำที่ตั้งใจ จากนั้นส่งแพ็กเก็ตหนึ่งจากโฮสต์ภายใน local_ts ไปยังที่อยู่ภายใน remote_ts และเฝ้าดู swanctl --list-sas หากเอาต์พุตไม่เปลี่ยน ไม่มี acquisition ไปถึงเดมอน

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

ทิศทางก็สำคัญ: trap ที่ติดตั้งสำหรับทราฟฟิกขาออกไม่เริ่มบนแพ็กเก็ตขาเข้า ถ้าฝั่งไกลต้องยกอุโมงค์ขึ้น มันต้องมี trap ของตัวเอง หรือฝั่งนี้ต้องมี start.

การรอแพ็กเก็ตแรกไม่ใช่การแลกเปลี่ยนที่ถูกต้องเสมอ

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

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

นโยบายที่ติดตั้งไว้ก็ไม่ใช่การรับประกันว่ากันการรั่วไหล หากข้อกำหนดคือ fail-closed ไฟร์วอลล์ต้องทิ้งทราฟฟิกที่ไม่มี SA และกฎนั้นอยู่นอกนิยาม child

จดสามบรรทัดที่จะจบการโต้แย้งครั้งถัดไป

เขียนตัวเลือก การกระทำตอนเริ่ม และเอาต์พุตคำสั่งที่แสดงว่านโยบายมีอยู่โดยไม่มี SA สามบรรทัดนั้นแยก “on-demand และไม่ได้ใช้งาน” ออกจาก “ไม่โหลด” ในครั้งถัดไปที่มีคนรายงานว่าอุโมงค์ล่ม การจดใช้เวลาหนึ่งนาที หากไม่มีมัน การสอบสวนเดิมก็เริ่มจากศูนย์

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