สองบัญชีล็อกอิน Mac ไม่ได้แยกทราฟฟิก VPN

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

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

เริ่มจากทราฟฟิก ไม่ใช่จากรายชื่อบัญชี

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

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

ช่องทางโปรไฟล์กับขอบเขตทราฟฟิกเป็นคนละเรื่อง

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

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

ระบบรับเชิญเป็นขอบเขตจริงที่มีข้อจำกัดจริง

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

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

พร็อกซีแคบกว่าบัญชีผู้ใช้

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

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

พิสูจน์ขอบเขตด้วยการทดสอบสองอย่าง

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

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