ตาราง VPN ว่างเปล่าไม่ได้ปิดกั้นอะไรด้วยตัวเอง
ตารางนโยบายที่ไม่มีการจับคู่เส้นทางไม่ได้ทิ้งแพ็กเก็ต การค้นหายังคงดำเนินต่อไป เพิ่มการกระทำสุดท้าย แล้วทดสอบทั้งสองสถานะความล้มเหลว
กฎนโยบายส่งแพ็กเก็ตที่ถูกทำเครื่องหมายไปยังตารางเฉพาะ และความคาดหวังปกติคือการสูญเสียเส้นทาง VPN จะปิดกั้นแพ็กเก็ตเหล่านั้น กลไกกลับทำอย่างอื่น เมื่อตารางไม่มีเส้นทางที่ตรงกัน การค้นหายังคงดำเนินต่อไปยังกฎถัดไป แทนที่จะหยุด และตาราง main ยังคงมีเส้นทางค่าเริ่มต้นปกติสำหรับ uplink ผลลัพธ์คือการกำหนดค่าที่ดูเหมือน fail-closed แต่ทำงานเป็น fail-open
ไม่มีอะไรเสียหาย นี่คือวิธีที่การกำหนดเส้นทางตามนโยบายถูกกำหนดไว้
การค้นหาดำเนินต่อไปเมื่อตารางไม่มีอะไร
100: from all fwmark 0x36 lookup 42 110: from all fwmark 0x36 lookup default 32766: from all lookup main
ลองชุดกฎนี้ การค้นหาที่ทำเครื่องหมายไปยังตาราง 42 และกฎถัดมาส่งเครื่องหมายเดียวกันไปยังตารางชื่อ default ตราบใดที่ตาราง 42 ยังมีเส้นทางค่าเริ่มต้นที่ใช้ได้ การค้นหาครั้งแรกจะให้เส้นทาง เมื่อเส้นทางนั้นหายไปและไม่มีสิ่งอื่นในตาราง 42 ตรงกัน การค้นหาจะไม่กลายเป็นการทิ้ง การประมวลผลจะไปยังกฎถัดไป และเมื่อกฎนั้นก็ไม่พบอะไร มันจะไปถึงตาราง main ไม่มีสิ่งใดในลำดับนั้นรายงานว่า กฎใดให้คำตอบสุดท้าย ดังนั้นการเชื่อมต่อที่ทำงานได้จึงดูเหมือนนโยบายที่ทำงานได้
ตาราง 253 ซึ่งปกติเรียกว่า default เป็นตารางเส้นทางธรรมดาและมักว่างเปล่า ชื่อของมันไม่ใช่คำสั่งให้ทิ้งแพ็กเก็ต และไม่ใช่สิ่งเดียวกับเส้นทางปลายทางค่าเริ่มต้นภายในตาราง
การกระทำสุดท้ายสิ้นสุดการค้นหา
100: from all fwmark 0x36 lookup 42 110: from all fwmark 0x36 prohibit 32766: from all lookup main
กฎสุดท้ายสามารถตามหลังการค้นหา VPN แทนการค้นหาในตารางว่าง ด้วยเครื่องหมายเดียวกัน การกระทำ prohibit ที่วางไว้หลังกฎของตาราง 42 จะสิ้นสุดการค้นหาเมื่อตารางนั้นไม่ให้อะไร และคืนการปฏิเสธเชิงบริหารแทนการให้โอกาสตาราง main อีกครั้ง unreachable และ blackhole ก็เป็นกฎสุดท้ายเช่นกัน โดยมีพฤติกรรมข้อผิดพลาดที่ต่างกันสำหรับผู้ส่ง
เส้นทางชนิด throw ต่างออกไป ภายในตารางนั้นมันทำงานราวกับไม่มีสิ่งใดตรงกัน ดังนั้นกฎถัดไปจึงยังได้ลำดับของตน สิ่งนี้ทำให้ throw มีประโยชน์สำหรับการถอยกลับโดยเจตนาและผิดเมื่อใช้เป็นบล็อกสุดท้าย
ตรวจสอบด้วยเครื่องหมายและอินเทอร์เฟซจริง
ip -4 rule show ip -4 route show table 42 ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36
ตรวจดูกฎและตารางจริงแทนแผนภาพ จากนั้นสอบถามโฟลว์ด้วยบริบทของต้นทาง เครื่องหมาย และอินพุตที่มันมีจริง การค้นหาแบบอ่านอย่างเดียวที่มุ่งไปยังปลายทางซึ่งระบุที่อยู่ต้นทาง อินเทอร์เฟซ และเครื่องหมาย จะรายงานเส้นทางที่เคอร์เนลจะเลือกโดยไม่มีแพ็กเก็ตออกไป การระบุเครื่องหมายในคำสั่งสอบถามไม่ได้พิสูจน์ว่าไฟร์วอลล์ทำเครื่องหมายทราฟฟิกจริง นั่นเป็นการตรวจสอบกฎการทำเครื่องหมายแยกต่างหาก ยืนยันค่าด้วยตัวนับหรือบันทึกก่อนสรุปจากคำสั่งสอบถาม
คำขอที่สร้างขึ้นในเครื่องต้องการบริบทของตัวเอง เพราะเส้นทางการทำเครื่องหมายมักต่างจากทราฟฟิกที่ถูกส่งต่อ ตรวจสอบด้วยอินเทอร์เฟซขาออกที่แอปพลิเคชันจะใช้จริง
สองสถานะความล้มเหลว ไม่ใช่หนึ่ง
สถานะความล้มเหลวหนึ่งคือเส้นทาง VPN หายไปและทราฟฟิกร่วงลงไปที่ uplink อุโมงค์ที่ตายแล้วแต่ยังมีเส้นทางติดตั้งอยู่เป็นอีกสถานะหนึ่ง แพ็กเก็ตยังคงถูกส่งเข้าเส้นทางที่ใช้ไม่ได้แทนที่จะร่วงลง และอาการคือการสูญเสียอย่างเงียบ ๆ ไม่ใช่การเชื่อมต่อตรงที่มองเห็นได้ ทดสอบทั้งสอง และทดสอบพฤติกรรมตอนเริ่มต้น การเชื่อมต่อใหม่ และการหยุดบริการด้วย
กฎเช่นนี้ช่วยได้เพียงตราบเท่าที่มันยังมีอยู่และแพ็กเก็ตยังคงพาเครื่องหมายที่เลือกมันไว้ สคริปต์ปิดเครื่องที่ลบกฎ หรือเส้นทางที่ถอดเครื่องหมายออก จะคืนพฤติกรรมแบบเปิด การเปลี่ยนผ่านเหล่านั้นคุ้มค่าที่จะฝึกซ้อม
ใช้นโยบายกับ IPv6 แยกต่างหาก และเก็บข้อยกเว้นปลายทางที่ได้รับอนุมัติให้ชัดเจนแทนที่จะเป็นนัย