ทำไมซับเน็ตหนึ่งยังคงเลี่ยงเส้นทางเริ่มต้นของ VPN

คุณเปลี่ยน VPN เป็นทันเนลแบบเต็ม ทราฟฟิกส่วนใหญ่ออกตาม แล้วที่อยู่อย่างหนึ่งก็ตอบกลับตรงๆ — เครื่องพิมพ์, NAS, jump host บน 10.x การอ่านที่ชัดเจนคือทันเนลรั่ว ดังนั้นคุณจึงลด metric ของเส้นทางเริ่มต้นลง แต่ก็ไม่มีอะไรเปลี่ยนแปลง ความพยายามที่ล้มเหลวนั้นคือเบาะแส เส้นทางเริ่มต้นเป็นตัวสำรอง ไม่ใช่คำตัดสิน การค้นหาเส้นทาง จะใช้คำนำหน้าที่ตรงกันยาวที่สุดก่อนที่จะเปรียบเทียบ metric ด้วยซ้ำ ดังนั้น /24 จึงยังชนะ /0 ไม่ว่าคุณจะแนบตัวเลขอะไรกับตัวใดตัวหนึ่ง เมื่อลำดับนั้นชัดเจน การรั่วมักเป็นเส้นทางที่มีคนติดตั้งไว้โดยเจตนา หรือคำนำหน้าที่ไคลเอนต์ไม่เคยตั้งใจจะครอบคลุม

เส้นทางเริ่มต้นสัญญาอะไรจริงๆ

0.0.0.0/0 ตรงกับทุกปลายทาง IPv4 ด้วยบิตเฉพาะเจาะจงศูนย์ มันมีอยู่เพื่อให้โฮสต์เข้าถึงทุกสิ่งที่ตารางของมันอธิบายได้ไม่ดีกว่า เส้นทางไปยัง 192.168.1.0/24 พา 24 บิตที่ตรงกัน ดังนั้นสำหรับ 192.168.1.40 มันชนะก่อนที่ใครจะเปรียบเทียบ metric ระยะทางเชิงบริหาร หรือสิ่งที่ไคลเอนต์เรียกฟิลด์ลำดับความสำคัญ กฎเดียวกันใช้ใน FIB ของ Linux ตารางเส้นทางของ Windows และสแตก BSD เบื้องหลัง macOS

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

half-default หรือทำไมรายการเริ่มต้นอาจดูไม่ถูกแตะต้อง

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

wg-quick ของ WireGuard บรรลุผลเดียวกันผ่านการกำหนดเส้นทางตามนโยบาย เมื่อ AllowedIPs ครอบคลุม 0.0.0.0/0 มันจะสร้างตารางของตัวเอง ส่งแพ็กเก็ตที่ทำเครื่องหมายไปที่นั่น และเพิ่มกฎที่เพิกเฉยต่อคำนำหน้าความยาวศูนย์ของตารางหลัก ตารางหลักเก็บรายการเริ่มต้นไว้ และกฎตัดสินว่าตารางทันเนลถูกถามก่อนสำหรับทราฟฟิกที่อินเทอร์เฟซเป็นเจ้าของ

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

metric ตัดสินเสมอ คำนำหน้าตัดสินผู้ชนะ

metric ถูกเปรียบเทียบเฉพาะในหมู่ผู้สมัครที่ตรงกับปลายทางเท่าๆ กัน บน Linux ip route get 10.20.5.9 พิมพ์ผู้ชนะพร้อมตารางของมัน และ ip route show table all แสดงรายชื่อผู้สมัคร รวมถึง half-default ใดๆ และตารางใดๆ ที่กฎชี้ไป บน Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 ส่งคืนเส้นทางที่เลือกและที่อยู่ต้นทาง ขณะที่ Get-NetRoute แสดงตารางดิบ — แต่ต้นทุนที่แท้จริงคือ metric ของเส้นทางบวก metric ของอินเทอร์เฟซ ดังนั้นอะแดปเตอร์ที่ช้าอาจแพ้เสมอที่ดูเหมือนชนะ

สามกรณีครอบคลุมส่วนใหญ่ของสิ่งที่คุณจะเห็น:

• ปลายทางเดียวกัน /24 กับ /0: /24 ชนะด้วยความยาวคำนำหน้า ไม่ว่า metric จะว่าอย่างไร
• ปลายทางเดียวกัน สอง /24 ที่มี metric ต่างกัน: metric ที่มีผลต่ำกว่าชนะ
• ปลายทางเดียวกัน สองตาราง หนึ่งถูกเลือกโดยกฎนโยบาย: กฎเลือกตารางก่อน และการเปรียบเทียบคำนำหน้าเกิดขึ้นภายใน

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

ใครมักเป็นเจ้าของการเลี่ยงนี้

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

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

จากนั้นตรวจสอบ IPv6 แยกต่างหาก ip -6 route และ Get-NetRoute -AddressFamily IPv6 เก็บสถานะแยก ค่าเริ่มต้นแยก และพฤติกรรมไคลเอนต์แยก การตรวจสอบเฉพาะ IPv4 ไม่ได้บอกอะไรเกี่ยวกับโฮสต์ dual-stack ที่ชอบเส้นทาง IPv6 แบบเนทีฟอย่างเงียบๆ และเพียงเท่านั้นก็ทำให้ไคลเอนต์ดูเหมือน split-tunnel ได้

ยืนยันด้วยโฟลว์ของแอปพลิเคชันเอง

บันทึกปลายทางที่แอปใช้จริง จากนั้นถามระบบเกี่ยวกับเส้นทางที่จะใช้จากที่อยู่ต้นทางที่แอปนั้นผูกอยู่ ip route get 10.20.5.9 from 192.168.1.40 ตอบสิ่งนั้นบน Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 บวกที่อยู่ภายในทำสิ่งนั้นบน Windows เปรียบเทียบผลลัพธ์กับสิ่งที่โปรไฟล์อ้าง หน้า IP สาธารณะของเบราว์เซอร์ทดสอบปลายทางหนึ่งบนโปรโตคอลหนึ่ง และไม่ได้บอกอะไรเกี่ยวกับที่อยู่ส่วนตัวที่เริ่มการร้องเรียน

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

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

• ระบุปลายทางและที่อยู่ต้นทางที่แอปใช้จริง
• พิมพ์เส้นทางที่ชนะด้วย ip route get หรือ Find-NetRoute.
• ตรวจสอบว่าคู่ /1 หรือตารางนโยบายเป็นเจ้าของเส้นทางอินเทอร์เน็ต
• แสดงรายการทุกคำนำหน้าที่ยาวกว่า /0 ที่ตรงกับปลายทาง
• ทำซ้ำการตรวจสอบ IPv6 แยกต่างหาก
• ติดตามเส้นทางที่เหลือกลับไปยังไฟล์ โปรไฟล์ หรือตัวกรองที่ติดตั้งมัน
• เชื่อมต่อใหม่และเรียกใช้คำถามอีกครั้งก่อนจะเรียกว่าซ่อมแล้ว

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