การตรวจจับเพียร์ที่ตายของ IKEv2 ไม่ได้ทดสอบแอปของคุณ

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

อ่านหลักฐานสองประเภทแยกกันก่อนเปลี่ยนตัวจับเวลา

การตรวจสอบความมีชีวิตถามอะไรจริง ๆ

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

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

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

อ่านสมาคมความปลอดภัยก่อนเบราว์เซอร์

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

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

ความล้มเหลวของเส้นทางดูเหมือนเพียร์ที่ตายแล้วทุกประการ

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

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

เก็บตัวจับเวลาไว้นอกการวินิจฉัย

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

การรีเฟรชแมปปิง NAT อยู่ในหมวดเดียวกัน มันทำให้เส้นทางที่แปลแล้วใช้งานได้ และไม่ใช่หลักฐานว่าแอปปลายทางทำงาน

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