Check Point VSX VPN: การเลือกเส้นทางเชื่อมหรือความไม่ตรงกันของเพียร์?

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

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

สามเงื่อนไขที่แยกสองกรณีออกจากกัน

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

หากเงื่อนไขแรกไม่ผ่าน คุณมีปัญหาเรื่องเส้นทางหรือการแปล หากเงื่อนไขที่สองไม่ผ่าน คุณมีปัญหาเรื่องสัญญากับเพียร์ หากเงื่อนไขที่สามไม่ทราบ ให้หยุดกำหนดค่า

สร้างบันทึกของเพียร์ภายนอกก่อน

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

เก็บคำนำหน้าที่ได้รับการป้องกันภายในไว้ในส่วนแยกของบันทึกนั้น การเปลี่ยนต้นทางภายนอกกับการเปลี่ยนที่อยู่ LAN ที่ได้รับการป้องกันเป็นสองปฏิบัติการที่ต่างกันซึ่งบังเอิญอยู่ในนโยบายเดียวกัน

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

อ่านว่าการเลือกเส้นทางเชื่อมแยกอะไรจริง ๆ

คู่มือการเลือกเส้นทางเชื่อมใน R81.20ของ Check Point แยกสามสิ่งที่ผู้คนมักรวมเป็นหนึ่ง: วิธีที่เพียร์ระยะไกลแปลงที่อยู่เกตเวย์ เส้นทางใดรับส่งทราฟฟิกขาออก และใช้ IP ต้นทางใด แต่ละข้อตอบคำถามคนละข้อ ไม่มีข้อใดเปลี่ยนตัวตนที่เพียร์พิสูจน์

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

RFC 7296 ลากเส้นแบ่งเดียวกันสำหรับ IKE เอง: เพย์โหลดการระบุตัวตนไม่ใช่ที่อยู่รับส่ง ผู้ผลิตนำการแยกนี้ไปใช้งาน ไม่ได้นิยามใหม่

ตัดสินด้วยหลักฐาน ไม่ใช่หน้าจอตั้งค่า

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

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

ทำให้ปลายทั้งสองตรงกันและเก็บบันทึกไว้

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

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