มาร์กของ nftables และการกำหนดเส้นทาง VPN: กฎใดชนะจริง

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

ตรวจสอบ 1: อ่านกฎที่เคอร์เนลจับคู่

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

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

สองคำสั่งตัดสินเรื่องนี้: รายการกฎ และการค้นหาเส้นทางไปยังปลายทางในตารางนั้น

ตรวจสอบ 2: มาร์กของแพ็กเก็ตหรือมาร์กของคอนเน็กชัน

nftables ตั้งมาร์กบนแพ็กเก็ตและมาร์กบนรายการติดตามคอนเน็กชันได้ และทั้งสองเป็นออบเจ็กต์ที่ต่างกัน มาร์กแพ็กเก็ตอยู่ตลอดรอบการประมวลผลของแพ็กเก็ต ส่วนมาร์กคอนเน็กชันคงอยู่ตลอดโฟลว์และต้องคัดลอกอย่างตั้งใจ การตั้งอย่างหนึ่งแล้วคาดหวังอีกอย่างเป็นการแก้แบบครึ่งๆ กลางๆ ที่พบบ่อย

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

ตัดสินว่าออบเจ็กต์ใดเป็นเจ้าของสัญญาณการกำหนดเส้นทาง แล้วตั้งค่า ณ จุดที่มีการตัดสินใจกำหนดเส้นทาง

ตรวจสอบ 3: ใครอีกที่เขียนมาร์กนั้น

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

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

ระบุรายชื่อผู้เขียนก่อนเพิ่มอีกราย

ตรวจสอบ 4: มาสก์เป็นตัวกำหนดว่าคุณเก็บอะไรไว้

มาร์กเป็นฟิลด์ 32 บิต และมาสก์คือวิธีที่เจ้าของหลายรายแบ่งปันฟิลด์นั้น การตั้งค่าด้วยมาสก์จะรักษาบิตที่คุณไม่ได้เป็นเจ้าของไว้ ส่วนการตั้งทั้งฟิลด์จะทำลายบิตของคนอื่นทั้งหมด อ่านมาสก์ในทุกกฎที่แตะฟิลด์ รวมถึงกฎที่คุณไม่ได้เขียน

บันทึกการจัดสรรบิตไว้ข้างชุดกฎ

มิฉะนั้นคนถัดไปจะนำค่าที่มีเจ้าของอยู่แล้วกลับมาใช้ซ้ำ และความขัดแย้งตรงนี้ดูเหมือนบั๊กการกำหนดเส้นทางทั้งที่เป็นบั๊กการกำหนดที่อยู่ เอกสารของ nftables เกี่ยวกับเมทาดาทาของแพ็กเก็ต อธิบายการดำเนินการกับมาร์กเอง

ตรวจสอบ 5: ตรวจสอบด้วยโฟลว์จริง ไม่ใช่การค้นหา

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

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

บันทึกมาร์ก มาสก์ และตารางไว้ในที่เดียว แล้วการแก้ไขครั้งถัดไปจะตรวจสอบได้