เส้นทาง DHCP สามารถพาทราฟฟิกของคุณอ้อมอุโมงค์ VPN ได้หรือไม่?

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

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

สองวิธีที่เครือข่ายส่งผลต่อคุณได้

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

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

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

เส้นทางจะมาจากไหนได้ก่อนที่อุโมงค์จะมีอยู่

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

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

IPv6 สมควรได้รับการตรวจแยก เพราะการประกาศของเราเตอร์พาเส้นทางเริ่มต้นผ่านโค้ดที่ต่างจากตัวเลือก DHCPv4 การทดสอบที่ตรวจเพียงตาราง v4 ยังไม่ครอบคลุมสิ่งนั้น

ตรวจสอบเส้นทางที่เคอร์เนลเลือกจริง

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

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

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

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

ตัดสินใจว่าการบังคับใช้ควรอยู่ที่ไหน

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

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

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