VPN สองไคลเอนต์พร้อมกัน: ใครชนะเส้นทางเริ่มต้น?

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

ตารางเส้นทางเลือกผู้ชนะเพียงรายเดียว

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

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

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

ip rule show

Windows ตัดสินด้วยเมตริก

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

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

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

ผู้สังเกตสองราย สองมุมมองที่ต่างกัน

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

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

DNS และ IPv6 คือจุดที่ห่วงโซ่รั่ว

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

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

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