Mac VPN On Demand: การจับคู่ SSID พิสูจน์อะไรได้จริง?
การจับคู่ SSID เป็นเงื่อนไขของกฎ ไม่ใช่หลักฐานของความเชื่อถือ สร้างกฎ On Demand เลือกค่าเริ่มต้นสำหรับเครือข่ายที่ไม่รู้จัก และแยกการบล็อกไว้ต่างหาก
การเชื่อมต่อ VPN ทุกที่ยกเว้น Wi-Fi ของออฟฟิศฟังดูเหมือนนโยบายสองบรรทัด และส่วนที่ยากไม่เคยเป็นการจดจำชื่อเครือข่าย ส่วนที่ยากคือการตัดสินใจว่าชื่อที่ตรงกันได้รับอนุญาตให้พิสูจน์อะไรได้ จุดเชื่อมต่อใดก็ได้สามารถประกาศ SSID ที่คุ้นเคย และ ping ที่สำเร็จไปยังที่อยู่หนึ่งพิสูจน์เพียงว่าการตรวจสอบหนึ่งครั้งได้รับคำตอบ ไม่มีการสังเกตใดในสองอย่างนี้ที่ยืนยันว่า Mac อยู่ในเครือข่ายภายในที่ผ่านการรับรองความถูกต้อง
ชื่อไม่ใช่ตัวตน
SSID คือป้ายที่วิทยุส่งออกมา ไม่ใช่กุญแจ ใบรับรอง หรือคำแถลงว่าใครเป็นเจ้าของฮาร์ดแวร์ และสถานที่จัดงานหรือออฟฟิศข้างเคียงสามารถออกอากาศสตริงเดียวกันได้โดยไม่ต้องประสานงานกันเลย การถือว่าป้ายคือคำสั่งให้ปิดการป้องกันนั้นยกการตัดสินใจให้ผู้ที่กำหนดค่าจุดเชื่อมต่อที่ใกล้ที่สุด
การทดสอบ ping ล้มเหลวด้วยเหตุผลที่ละเอียดอ่อนกว่า คือมันตอบคำถามเกี่ยวกับการเข้าถึง ไม่ใช่เกี่ยวกับการเป็นสมาชิก เป้าหมายที่ตอบสนองอาจเข้าถึงได้จากทุกที่ อาจเข้าถึงได้เฉพาะผ่านอุโมงค์ที่คุณกำลังตัดสินใจ หรืออาจเป็นพอร์ทัล captive ที่ส่งคืนสิ่งที่ดูเหมือนคำตอบ การเข้าถึงเป็นข้อเท็จจริงที่เป็นประโยชน์และเป็นขอบเขตความเชื่อถือที่แย่
วิธีที่ On Demand ประเมินชุดกฎ
โมเดล On Demand ของ Apple จับคู่การกระทำกับเงื่อนไขเครือข่ายที่เป็นทางเลือก และกฎถูกประเมินตามลำดับ กฎข้อแรกที่เงื่อนไขทั้งหมดตรงกันจะเป็นผู้ให้การกระทำ และข้อที่เหลือจะไม่ถูกพิจารณา ลำดับนั้นคือแนวนโยบาย ซึ่งเป็นเหตุผลที่กฎที่เพิ่มเข้าไป «เผื่อไว้» อาจเขียนทับพฤติกรรมที่เคยทำงานได้อย่างเงียบ ๆ
เงื่อนไข SSID อ้างถึงเครือข่ายหลักที่เชื่อมต่ออยู่ในปัจจุบัน ไม่ใช่ทุกชื่อที่มองเห็นในการสแกน สิ่งนี้ก่อให้เกิดสามสถานะที่แตกต่างกัน และการยุบให้เหลือสองคือข้อผิดพลาดในการกำหนดค่าที่พบบ่อย:
| State | What the rule sees | What it must not be taken to mean |
|---|---|---|
| No SSID criterion applied | Nothing to compare | That the network is unknown or unsafe |
| Unknown network | Connected, name does not match | That no rule below applies |
| Recognized network | Primary network matches | That the network is trusted |
กำหนดค่าในที่ที่แนวนโยบายอยู่
ไคลเอนต์ VPN ที่ได้รับอนุมัติหรือเวิร์กโฟลว์การจัดการคือที่ที่กฎนี้ควรอยู่ และผู้ให้บริการแต่ละรายเปิดเผยชุดย่อยของตัวควบคุมที่มีอยู่แตกต่างกัน การไม่มีตัวเลือกในแผงนั้นจึงหมายความว่าไคลเอนต์ไม่ได้เปิดเผย ไม่ใช่แพลตฟอร์มแสดงออกไม่ได้
การเปิดใช้งานอัตโนมัติยังต้องมีวิธีการรับรองความถูกต้องที่ทำเสร็จได้โดยไม่ต้องมีคน เช่น ใบรับรองหรือวิธีอื่นที่รองรับ รหัสใช้ครั้งเดียวที่จัดเก็บไว้ไม่ใช่วิธีการนั้น และกฎที่ทำงานในขณะที่การรับรองความถูกต้องทำไม่เสร็จจะสร้างความพยายามเชื่อมต่อที่ล้มเหลวอย่างเงียบ ๆ ในเบื้องหลัง
สองรูปแบบที่ควรเขียนลงใน runbook
รูปแบบแรกคือชื่อเลียนแบบ สถานที่จัดประชุม โรงแรม หรือผู้เช่าในอาคารเดียวกันประกาศสตริงที่กฎของคุณถือว่า «อยู่ข้างใน» และการป้องกันจะปิดลงในที่ที่คุณต้องการน้อยที่สุด ชื่อไม่ได้โกหก กฎได้ถามคำถามที่ชื่อนั้นตอบไม่ได้
รูปแบบที่สองคือการตรวจสอบที่เอาชนะตัวเอง สคริปต์ ping ไปยังที่อยู่ส่วนตัว เห็นคำตอบผ่านอุโมงค์ สรุปว่าอยู่ในเครือข่ายภายในแล้วและตัดการเชื่อมต่อ จากนั้นการตรวจสอบล้มเหลว สคริปต์จึงเชื่อมต่อใหม่และทำซ้ำ และอุโมงค์จะแกว่งไปมาในขณะที่แต่ละขั้นตอนดูถูกต้อง การทดสอบที่ผลลัพธ์ขึ้นอยู่กับอุโมงค์ไม่สามารถตัดสินได้ด้วยว่าอุโมงค์ควรมีอยู่หรือไม่
ตัดสินค่าเริ่มต้น แล้วบังคับใช้แยกต่างหาก
กรณีเครือข่ายที่ไม่รู้จักและกรณีสายไฟต้องมีคำตอบที่ชัดเจนแทนค่าเริ่มต้นที่สืบทอดมา หากต้องให้ทราฟฟิกที่ได้รับการป้องกันยังคงถูกบล็อกในขณะที่ระบบยังจำแนกเครือข่ายหรือกำลังยกอุโมงค์ขึ้น สิ่งนั้นต้องใช้การควบคุมการบังคับใช้ที่รองรับของตัวเอง ทริกเกอร์ On Demand ให้พฤติกรรมการเชื่อมต่อ ไม่ใช่การรับประกันการบล็อก
เมื่อเขียนอย่างถูกต้อง กฎของผู้ดูแลระบบจะระบุข้อยกเว้นที่ได้รับอนุมัติ หลักฐานที่ทำให้ข้อยกเว้นนั้นชอบธรรม และการถอยกลับอย่างตั้งใจเมื่อไม่มีหลักฐานเหล่านั้น การจดจำชื่อ Wi-Fi เป็นอินพุตที่ชอบธรรมสำหรับการตัดสินใจนั้น ไม่ใช่เหตุผลของการตัดสินใจ และไม่ควรเป็นบรรทัดเดียวในกฎ