ทำไม net.ipv4.conf.default.forwarding ไม่แตะ tun0

คุณตั้งค่า net.ipv4.conf.default.forwarding=1 แล้วรีสตาร์ต VPN แต่ทันเนลยังคงทิ้งแพ็กเก็ตที่เกตเวย์ควรกำหนดเส้นทาง การตั้งค่าในไฟล์ดูถูกต้อง และอินเทอร์เฟซยังรายงานว่าการส่งต่อถูกปิดอยู่ ไม่มีอะไรเสีย: คุณเปลี่ยนค่าที่อินเทอร์เฟซในอนาคตจะสืบทอด ไม่ใช่ค่าที่ทันเนลที่ทำงานอยู่ใช้

ตรวจสอบเรื่องนี้บนโฮสต์ที่เป็นเจ้าของทันเนล ใน namespace เครือข่ายที่ทันเนลมีอยู่จริง คอนเทนเนอร์หรือ namespace เครือข่ายอาจถืออินเทอร์เฟซไว้ขณะที่โฮสต์แสดงตัวเลขอื่น

อ่านค่าทั้งสามพร้อมกัน

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

ผลลัพธ์ที่พบบ่อยคือ ip_forward = 0, default.forwarding = 1 และ tun0.forwarding = 0 สองค่าแรกไม่ตรงกันเรื่องบทบาทของโฮสต์ และค่าที่สามแสดงว่าอินเทอร์เฟซทำอะไรจริง ๆ การผสมแบบนี้สอดคล้องกับโฮสต์ที่ไม่เคยถูกกำหนดค่าเป็นเราเตอร์ แต่ได้รับเพียงค่าเทมเพลต ตัวเลขทั้งสามไม่ได้ขัดแย้งกัน พวกมันตอบคำถามที่ต่างกันสามข้อ การเขียนค่าเทมเพลตก็ไม่ได้ตัดสินบทบาทของโฮสต์เช่นกัน

ทำไมสวิตช์ส่วนกลางจึงเป็นตัวที่ขยับ

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

เอกสารของเคอร์เนลระบุว่า ip_forward เป็นกรณีพิเศษด้วยเหตุผลที่เกี่ยวข้อง: การเปลี่ยนค่านี้จะรีเซ็ตพารามิเตอร์ IPv4 อื่น ๆ จำนวนหนึ่งกลับเป็นค่าเริ่มต้นสำหรับโฮสต์หรือเราเตอร์ ทำให้มันเป็นเครื่องมือที่ทื่อ การตั้งค่าหนึ่งครั้งในฐานะส่วนหนึ่งของการสร้างบทบาทเกตเวย์เป็นเรื่องที่โอเค แต่การสลับไปมาซ้ำ ๆ เป็นเทคนิคแก้จุดบกพร่องอาจเขียนทับการกำหนดค่าที่คุณใช้เวลาเคี่ยวกรำอย่างเงียบ ๆ

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

ทำให้การตั้งค่าคงอยู่ถาวรในที่ที่ถูกต้อง

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

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

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

อย่าซ่อมสิ่งนี้ด้วยเครื่องมือผิด

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

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

แยกกรณี IPv6 ไว้ต่างหาก

ทุกอย่างที่นี่คือ IPv4 การส่งต่อ IPv6 การประกาศเราเตอร์ และพฤติกรรม accept_ra มีการควบคุมของตัวเอง และการคัดลอกเส้นทาง ipv4 ไปยังการตั้งค่า ipv6 ให้ไฟล์ที่ดูสมเหตุสมผลแต่ไม่ได้ทำอะไรที่มีประโยชน์ เกตเวย์แบบ dual-stack ต้องกำหนดค่าทั้งสองชุดอย่างตั้งใจ

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