ซับเน็ตปลายทางกับ VPN บนเดสก์ท็อป: ยกเว้นการส่งผ่าน ไม่ใช่แอป
การข้ามรายแอปจำแนกเฉพาะเอาต์พุตภายในเครื่อง อุปกรณ์ที่อยู่หลังเวิร์กสเตชันต้องมีนโยบายขาเข้า การส่งต่อ และเส้นทางกลับของตนเอง
เครื่องเดียว สองงาน ไฟร์วอลล์เดียว: ลิงก์อัป Wi-Fi ซับเน็ต Ethernet เล็กๆ ที่อยู่ด้านหลัง และไคลเอนต์ VPN บนเดสก์ท็อปที่ถือว่าทุกอย่างที่ออกจากเครื่องเป็นเรื่องภายใน แอปที่เปิดในเครื่องออกผ่านเส้นทางเอาต์พุตภายใน อุปกรณ์ที่อยู่หลังเวิร์กสเตชันมาถึงพอร์ต Ethernet และต้องการการตัดสินใจเรื่องการส่งต่อ การยกเว้นที่เขียนไว้สำหรับเส้นทางแรกไม่เคยเห็นเส้นทางที่สอง และนั่นคือเหตุผลที่เบราว์เซอร์ข้ามอุโมงค์ แต่อุปกรณ์ไม่ข้าม
สองเส้นทางของแพ็กเก็ต นโยบายเดียว
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
แถวแรกคือสิ่งที่คู่มือ split-tunneling ส่วนใหญ่อธิบาย แถวที่สองคือการตั้งค่าเราเตอร์ที่บังเอิญอยู่ในเครื่องเดียวกัน การหลอมทั้งสองเป็นแบบจำลองทางความคิดเดียวคือความผิดพลาด ทั้งสองใช้เคอร์เนลร่วมกัน แต่ไม่ใช่นโยบายร่วมกัน วาดทั้งสองเส้นทางก่อนแก้ไขกฎใดๆ และส่วนที่เหลือของการออกแบบจะตามมาจากเส้นทางที่ขาดหายไป
ตารางยังอธิบายด้วยว่าเหตุใดเครื่องเดียวจึงผ่านการทดสอบหนึ่งและล้มเหลวอีกอย่างหนึ่ง เบราว์เซอร์บนเวิร์กสเตชันพิสูจน์เส้นทางภายใน เครื่องแล็ปท็อปที่เสียบอยู่ในพอร์ต Ethernet พิสูจน์เส้นทางส่งต่อ ตรวจสอบการเปลี่ยนแปลงด้วยทั้งสองอย่าง ไม่เช่นนั้นอีกเส้นทางจะไม่ถูกทดสอบไม่ว่าจะรีเฟรชเบราว์เซอร์กี่ครั้ง
การยกเว้นรายแอปจำแนกอะไรจริงๆ
การยกเว้นรายแอปมักทำงานโดย ทำเครื่องหมายแพ็กเก็ตจากโปรเซสหรือผู้ใช้ แล้วจึงส่งเส้นทางทราฟฟิกที่ทำเครื่องหมายไว้ออกนอกอุโมงค์ นั่นคือโครงสร้างของเอาต์พุตภายใน แพ็กเก็ตจากอุปกรณ์ปลายทางไม่มีความเป็นโปรเซสภายใน จึงไม่ตรงกับตัวเลือก ไม่ว่าตัวเลือกจะเป็นอะไร
ไม่ว่าตัวเลือกจะเป็นอะไร รายการทั้งสองก็ไม่ใช่รายการเดียวกัน และนั่นคือประเด็นทั้งหมด คู่มือ Linux ของ Mullvad อธิบายเครื่องหมายที่ไฟร์วอลล์และนโยบายการกำหนดเส้นทางของมันใช้ และตัวอย่างของมันมุ่งเป้าไปที่เอาต์พุตภายใน ไม่ใช่คำอธิบายที่รองรับของเราเตอร์ปลายทาง การคัดลอกสิ่งเหล่านั้นให้เครื่องที่เชื่อว่าตนมีการยกเว้น ขณะที่ส่งทุกอย่างเข้าอุโมงค์
เขียนสัญญาการส่งผ่าน
ตั้งชื่อคำนำหน้าแหล่งที่มาปลายทางและอินเทอร์เฟซขาเข้าด้วยกัน แล้วจำกัดคำนำหน้านั้นที่ขาเข้า หากไม่มีข้อจำกัด อุปกรณ์ใดก็ตามที่เข้าถึงพอร์ตได้สามารถอ้างที่อยู่ที่ถูกยกเว้นและออกผ่านการข้ามได้ มองเป็นสองคำถาม: โฮสต์เหล่านี้ใช้ลิงก์อัปนี้ได้หรือไม่ และเข้าถึงเวิร์กสเตชันหรือช่วงส่วนตัวของอุโมงค์ได้หรือไม่ สิ่งเหล่านี้เป็นการอนุญาตเพิ่มเติม ไม่ใช่ผลข้างเคียงของการเลือกลิงก์
อนุญาตให้ส่งต่อ แล้วจึงกรอง Linux เกตเวย์ต้องเปิดใช้งานการส่งต่อ มีกฎที่อนุญาตทราฟฟิกที่ต้องการทั้งสองทิศทาง และมีเส้นทางกลับขึ้นบนหรือการแปลแหล่งที่มาที่จำกัดอย่างตั้งใจ NAT เพียงอย่างเดียวไม่เลือกลิงก์อัปและไม่อนุญาตให้ผ่านตัวกรอง มันเขียนที่อยู่ใหม่หลังจากการตัดสินใจเหล่านั้นเท่านั้น
การจำแนกสำหรับการส่งผ่านต้องเกิดขึ้นก่อนการตัดสินใจเส้นทางส่งต่อ ซึ่งหมายถึงขั้น prerouting ไม่ใช่ output กฎที่วางไว้หลังการตัดสินใจยังเปลี่ยนแพ็กเก็ตได้ แต่เปลี่ยนสถานที่ที่แพ็กเก็ตถูกส่งไปแล้วไม่ได้
เครื่องหมายเป็นของแอปที่เป็นเจ้าของ
ค่าของเครื่องหมาย หมายเลขตาราง และลำดับความสำคัญของเชนเป็นส่วนหนึ่งของนโยบายของแอป VPN ไม่ใช่ค่าคงที่ชั่วนิรันดร์ เครือข่ายที่ทนทานซึ่งพึ่งพิงการแทรกกฎในตารางที่โปรแกรมอื่นสร้างใหม่จะพังในการอัปเดตครั้งถัดไป โดยปกติระหว่างการเชื่อมต่อใหม่ ไม่ใช่ในเวลาที่สะดวก
การเพิ่มเชนพื้นฐานที่สองด้วยคำตัดสิน accept ไม่จำเป็นต้องเอาชนะ drop ของเชนที่มาทีหลัง เชนพื้นฐานมีฮุกและลำดับความสำคัญ และคำตัดสินแรกตามลำดับเป็นผู้ชนะ accept ในเชนหนึ่งไม่ยกเลิก drop ที่เชนอื่นไปถึงก่อน ดูชุดกฎทั้งหมดและลำดับของนโยบายการกำหนดเส้นทาง ไม่ใช่ตัวนับเดียวที่เพิ่มขึ้น ตัวนับพิสูจน์ว่ากฎทำงาน ไม่เคยพิสูจน์ว่าคำตัดสินของกฎนั้นคือสิ่งที่ถูกใช้
รวมเข้าด้วยกัน หรือย้ายซับเน็ต
การออกแบบทั้งสองต่างกันที่ใครเป็นเจ้าของการข้าม การออกแบบแบบรวมเก็บเครื่องเดียวและนโยบายเดียว โดยมีต้นทุนคือการพึ่งพิงวงจรชีวิตของตารางในแอป VPN และชุดเครื่องหมายที่เอกสารของมันอาจเปลี่ยนแปลง เราเตอร์เฉพาะสำหรับเครือข่ายปลายทางขจัดความพึ่งพิงนั้นทั้งหมด ซับเน็ตมีลิงก์อัปของตัวเอง และเวิร์กสเตชันยังคงเป็นไคลเอนต์ที่ไม่มีบทบาทส่งต่อ
เลือกแบบที่สองเมื่อเครือข่ายปลายทางต้องทำงานต่อผ่านการอัปเดต VPN หรือเมื่อไม่มีใครทดสอบนโยบายแบบรวมได้หลังการออกรุ่นทุกครั้ง เลือกแบบแรกเฉพาะเมื่อการรวมถูกบันทึกไว้และมีคนดูแล
ตรวจสอบขอบเขตในสี่สถานะ: เชื่อมต่อแล้ว กำลังเชื่อมต่อใหม่ ถูกบล็อกโดยเจตนา และหยุดแล้ว ตรวจสอบการแปลงชื่อและตระกูลที่อยู่ทั้งสองในแต่ละสถานะ เพราะการข้ามที่รั่ว DNS ไม่ใช่การยกเว้นที่คุณออกแบบ การทดสอบควรพิสูจน์ขอบเขตที่แม่นยำ ไม่ใช่เพียงว่าโหลดหน้าเว็บได้หนึ่งหน้า