การล็อก VPN ด้วย PF บน Mac: นโยบายของไซต์ ไม่ใช่ฟีเจอร์ที่จัดส่งได้

มันทำงานบน Mac ของคุณ จึงดูเหมือนสิ่งที่มอบให้ผู้ใช้ได้ ข้อสันนิษฐานนั้นคือสิ่งแรกที่ต้องละทิ้ง เอกสาร TN3165 ของ Apple ระบุชัดเจนว่า Packet Filter ไม่ใช่ API ที่รองรับสำหรับผลิตภัณฑ์ที่เผยแพร่ทั่วไป และถือว่าการดูแลไซต์แบบมีสิทธิพิเศษและควบคุมได้เป็นกรณีที่สมเหตุสมผล การล็อก VPN ที่สร้างบน PF จึงเป็นนโยบายปฏิบัติการภายในที่มีเจ้าของ ไม่ใช่ฟีเจอร์ที่จัดส่งได้ในแอป

PF ไม่ใช่พื้นผิวสำหรับการแพ็กเกจ

ความแตกต่างนี้ไม่ใช่เรื่องวิชาการ ผลิตภัณฑ์ที่เผยแพร่ซึ่งพึ่งพา PF จะสืบทอดทุกการเปลี่ยนแปลงที่ Apple ทำกับมัน ทุกความขัดแย้งกับเครื่องมืออื่นที่เขียนกฎด้วย และไม่มีคำมั่นสนับสนุนว่าการจัดวางนี้จะทำงานต่อไป ไซต์ที่ดูแลเครื่องของตนเองมีความสัมพันธ์ต่างออกไป: มันสามารถจัดทำเอกสารการพึ่งพา ทดสอบกับ OS ทุกรุ่น และยอมรับการบำรุงรักษา

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

เขียนเจตนาขาออกก่อนไวยากรณ์

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

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

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

หมายเลข utun ไม่ใช่ตัวตน

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

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

ทำให้นโยบายที่โหลดระบุที่มาได้

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

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

ทดสอบการเปลี่ยนสถานะ ไม่ใช่สถานะที่เชื่อมต่อ

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

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

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