VPN ต่อแอปหรือ split tunnel? เส้นทางของ Mac ตัดสินใจอะไรได้

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

ตัวเลือกคือปลายทาง ไม่เคยเป็นโปรเซส

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

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

split tunnel ปกติให้อะไรจริงๆ

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

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

VPN ต่อแอปบน macOS ต้องมีอะไร

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

การติดตั้งไคลเอนต์ด้วยมือไม่ได้สร้างการแมปนั้น และแผงการตั้งค่าปกติไม่ได้ทำให้แอปเลือกได้ทีละตัว ผู้ขายอาจเปิดเผยกฎของแอปเอง และกฎเหล่านั้นเป็นไปตามเอกสารของผู้ขายไม่ใช่กฎทั่วไป

สามวิธีแยกตามแอปโดยไม่ต้องมี MDM

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

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

เขียนคำขอให้คำตอบชัดเจน

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

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