เมตริกเส้นทาง OpenVPN: ทำไมเส้นทางที่เลือกยังแพ้อยู่

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

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

อ่านบรรทัดเส้นทางตามลำดับฟิลด์

ไคลเอนต์ Community OpenVPN 2.6 รับสี่ฟิลด์ในบรรทัด route สำหรับ IPv4 ได้แก่ เครือข่าย เน็ตมาสก์ เกตเวย์ และเมตริกแบบไม่บังคับ ตำแหน่งเกตเวย์คือที่ที่คำสำคัญพิเศษ vpn_gateway อยู่ มันหมายถึงฮอปถัดไปฝั่ง VPN สำหรับการเชื่อมต่อนี้ ไม่ใช่หมายเลขตารางเส้นทางและไม่ใช่เราเตอร์จริงของคุณ ถ้าพลาดจุดนี้ ส่วนที่เหลือของบรรทัดจะถูกอ่านด้วยความเข้าใจผิดว่ามันทำอะไร เอกสารอ้างอิงตัวเลือกเครือข่าย อธิบายทั้งสี่ฟิลด์

สำหรับปลายทางส่วนตัว บรรทัดอาจเป็นแบบนี้:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

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

route-metric เป็นค่าเริ่มต้น ไม่ใช่การจัดอันดับ

route-metric กำหนดค่าสำรองสำหรับเส้นทางที่ไม่มีตัวเลขของตัวเอง มันไม่ดันเส้นทางให้อยู่เหนือสิ่งอื่นใด และไม่จัดลำดับเส้นทางที่ติดตั้งด้วยเมตริกที่ระบุชัดเจนใหม่

ความต่างนี้สำคัญเมื่อโปรไฟล์ผสมทั้งสองรูปแบบ บรรทัด route-metric เพียงบรรทัดเดียวใกล้ด้านบนดูเหมือนมีอำนาจและง่ายที่จะโทษ แต่เส้นทางที่รับทราฟฟิกจริงอาจมีเมตริกของตัวเองอยู่สามบรรทัดถัดลงมา

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

ตรวจดูว่าไคลเอนต์ติดตั้งอะไรไว้

เมื่อการเชื่อมต่อใหม่เสร็จสิ้น ให้ถามเคอร์เนล ไม่ใช่โปรไฟล์

ip route show แสดงรายการเส้นทางที่ไคลเอนต์เพิ่ม และ ip route get 172.20.5.10 ตอบคำถามที่มีประโยชน์กว่า คือปลายทางนี้จะใช้เส้นทางใดจริง ๆ และด้วยแอดเดรสต้นทางใด หากไม่มีปลายทางในตาราง แสดงว่าไคลเอนต์ไม่ได้ติดตั้งมัน

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

ทำไมเมตริกที่เล็กกว่าจึงยังแพ้

เมตริกเปรียบเทียบเส้นทางที่ไปยังปลายทางเดียวกัน มันไม่ได้ทำให้พรีฟิกซ์กว้าง ๆ เจาะจงขึ้น เมื่อใช้ redirect-gateway def1 ไคลเอนต์จะติดตั้ง 0.0.0.0/1 และ 128.0.0.0/1 และสองพรีฟิกซ์นั้นครอบคลุมพื้นที่ IPv4 ทั้งหมดอย่างเจาะจงกว่า 0.0.0.0/0 เมตริก 1 บนเส้นทางเริ่มต้นไม่ได้เหนือกว่าพวกมัน

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

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

กฎนโยบายทำงานก่อนตาราง

บน Linux ip rule ตัดสินว่าตารางเส้นทางใดจะถูกตรวจสอบ กฎถูกประเมินตามลำดับความสำคัญ ตารางที่มาก่อนจึงคืนเส้นทางได้ก่อนที่ตารางหลักจะถูกอ่านด้วยซ้ำ เมตริกใน main ไม่สามารถเหนือกว่าการจับคู่ในตารางที่ถูกตรวจก่อน

ใช้ ip rule show แล้วถามตารางที่เจาะจง เช่น ip route show table 100 เพื่อดูว่ากฎนั้นจะคืนอะไร หากไคลเอนต์ VPN หรือรันไทม์คอนเทนเนอร์เพิ่มกฎไว้ คำตอบอาจอยู่ที่นั่นแทนที่จะอยู่ในตารางที่คุณอ่านอยู่ แอดเดรสต้นทางก็สำคัญเช่นกัน เพราะกฎอาจจับคู่กับต้นทางและแก้ปลายทางเดียวกันต่างกันสำหรับทราฟฟิกอุโมงค์และทราฟฟิก LAN

ตรวจปลายทาง ไม่ใช่การจัดอันดับ

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

กัน IPv6 และ DNS ออกจากการตรวจนี้ เพราะมันถูกกำหนดด้วยไดเรกทีฟอื่นและแก้ด้วยกลไกอื่น และเส้นทาง IPv4 ที่ใช้งานได้ไม่ได้บอกอะไรเกี่ยวกับทั้งสองอย่าง เปลี่ยนทีละชั้นแล้วรันคำสั่งสอบถามอีกครั้ง