strongSwan ยังคงล่มหลังรีบูต peer: กู้คืนอุโมงค์หนึ่งเส้น

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

เลิกใช้การรีสตาร์ตแบบทั้งระบบ แต่เก็บหลักฐานไว้

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

อ่านการเชื่อมต่อที่โหลดไว้และสมาคมที่ใช้งานอยู่ก่อนแก้อะไร เพื่อให้มีภาพก่อนหน้าไว้เทียบเมื่อ peer กลับมา

swanctl --list-conns
swanctl --list-sas

วางการเริ่มต้นและการลองใหม่บนการเชื่อมต่อที่ต้องกลับมา

ในการติดตั้งแบบ swanctl.conf ค่าเหล่านี้อยู่ที่ระดับการเชื่อมต่อและ child ไม่ใช่ในนโยบายทั้งระบบ ตัวอย่างด้านล่างเป็นฝั่งผู้เริ่ม ซึ่งสมมติว่าข้อเสนอ การพิสูจน์ตัวตน และตัวเลือกนั้นถูกต้องอยู่แล้ว

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action ตัดสินว่าเกิดอะไรขึ้นเมื่อโหลด child: start เริ่มทันที ส่วน trap ติดตั้งนโยบายที่กระตุ้นการเริ่มเมื่อมีทราฟฟิกที่ตรงกันปรากฏขึ้น การเขียน trap|start ต้องใช้ strongSwan 5.9.6 หรือใหม่กว่า ดังนั้นตรวจสอบเวอร์ชันก่อนคัดลอกบรรทัด dpd_action=restart ขอเจรจาใหม่เมื่อ peer ถูกประกาศว่าตายแล้ว และ keyingtries=0 ที่ระดับการเชื่อมต่ออนุญาตให้ลองเพิ่มจนสำเร็จหรือเจอข้อผิดพลาดถาวร ภายใต้ IKEv2 ค่า dpd_timeout ไม่มีผลเลย เพราะการส่งซ้ำปกติเป็นตัวตัดสินว่าเมื่อใด peer ไม่ตอบสนอง

ความหน่วงในตัวอย่างนั้นเป็นจุดเริ่มต้น ไม่ใช่กำหนดเวลาสากล เลือกมันจากระยะเวลาที่ peer ใช้รีบูตและ ปริมาณการส่งซ้ำที่คุณยอมทน.

รู้ว่าคุณกำลังกู้คืนจากเหตุการณ์ใด

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

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

ตรวจสอบด้วยชื่อ ไม่ใช่สถานะเดมอน

อ่านการเชื่อมต่อและ child ของมันด้วยชื่อขณะ peer ยังล่มอยู่ แล้วอ่านอีกครั้งเมื่อมันกลับมา ความต่างระหว่างผลลัพธ์สองครั้งนั้นคือหลักฐาน

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

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

ถ้า child ไม่เริ่มเลย ให้ตรวจสอบว่าทราฟฟิกทดสอบตรงกับตัวเลือกที่ตั้งไว้อย่างแม่นยำ รวมถึงโปรโตคอลและพอร์ต ถ้ามันเริ่มแล้วล้มเหลว ให้อ่านข้อผิดพลาดการพิสูจน์ตัวตนหรือข้อเสนอ แทนที่จะซ่อนไว้หลังลูปไม่สิ้นสุด เพราะ keyingtries=0 จะทำการปฏิเสธถาวรซ้ำไปตลอด

โหลดการเปลี่ยนแปลงในหน้าต่างซ่อมและทดสอบซ้ำ

reload ปลอดภัยกว่าการรีสตาร์ตเดมอน และก็ยังไม่ฟรี: การแทนที่หรือถอด child อาจปิดสมาคมที่เริ่มแล้วหรือทำ trap ของมันหลุด

โหลดระหว่างหน้าต่างบำรุงรักษา เก็บไฟล์ก่อนหน้าไว้ และยืนยันว่าการเชื่อมต่อปรากฏด้วยค่าที่คุณตั้งใจ ไม่ใช่ค่าเริ่มต้น

swanctl --load-conns
swanctl --list-conns

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