การแยกทราฟฟิกของทันเนลแยกตัดสินว่าทราฟฟิกใดใช้ VPN อย่างไร

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

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

ไคลเอนต์ติดตั้งกฎ เคอร์เนลเป็นผู้เลือก

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

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

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

การผูกต่อแอปกับคำนำหน้าปลายทางเป็นเครื่องมือคนละอย่าง

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

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

DNS และสวิตช์ความปลอดภัยเป็นไปตามกฎของตัวเอง

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

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

ตรวจสอบการแยกจากทั้งสองด้าน

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

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

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

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