Always On VPN กับ VPN On Demand บน iPhone: จะปรับใช้แบบไหน

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

ขั้นตอนที่ 1: กำหนดว่าอุปกรณ์บังคับใช้อะไรได้

Always On เป็นคุณสมบัติของอุปกรณ์ที่ถูกกำกับดูแล หากกลุ่มอุปกรณ์ไม่ได้ถูกกำกับดูแล การถกเถียงจบก่อนจะเริ่ม และไม่มีคีย์ payload ใดเปลี่ยนโทรศัพท์ที่ไม่ได้ถูกกำกับดูแลให้กลายเป็นเครื่องที่ถูกบังคับ ยืนยันการกำกับดูแลจากฝั่งการจัดการและจากตัวเครื่อง แล้วยืนยันว่าใครลงนามในโปรไฟล์

บนโทรศัพท์ เปิด Settings จากนั้น General จากนั้น VPN และ Device Management รายการโปรไฟล์ระบุเจ้าของ และโปรไฟล์ส่วนตัวที่ติดตั้งด้วยมือจะดูต่างจากโปรไฟล์ที่ส่งมาจากบริการจัดการ อย่าเดาการบังคับใช้จากชื่อโปรไฟล์หรือจากป้ายการตลาดของผู้ให้บริการ ป้ายไม่ใช่นโยบายของแพลตฟอร์ม

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

ขั้นตอนที่ 2: อ่านกฎ on-demand ไม่ใช่อ่านชื่อคุณสมบัติ

On Demand คือรายการกฎที่ประเมินตามลำดับ แต่ละกฎระบุการกระทำและเงื่อนไขที่เลือกกฎนั้น และเงื่อนไขคือส่วนที่น่าสนใจ: ชนิดอินเทอร์เฟซ, Wi-Fi SSID, คำต่อท้ายโดเมน DNS หรือ URL ทดสอบ ชุดกฎที่ไม่เคยตรงเงื่อนไขคือคุณสมบัติที่ไม่เคยเชื่อมต่อ

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

อ่านทั้งอาร์เรย์และถามสองคำถามต่อกฎ: เงื่อนไขนี้เป็นจริงได้หรือไม่บนกลุ่มอุปกรณ์นี้ และเกิดอะไรขึ้นเมื่อไม่มีกฎใดตรงเงื่อนไข เครือข่ายองค์กรเปลี่ยนชื่อจุดเชื่อมต่อ รวม SSID และเปลี่ยนคำต่อท้าย DNS และการแก้ไขแต่ละอย่างนั้นแยกกฎออกจากความจริงอย่างเงียบ ๆ

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

ขั้นตอนที่ 3: ทดสอบการเปลี่ยนผ่าน ไม่ใช่การเชื่อมต่อที่นิ่ง

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

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

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

ขั้นตอนที่ 4: รู้จักรูปแบบความล้มเหลวสองแบบ

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

On Demand ล้มเหลวด้วยการไม่ทริกเกอร์ กฎไม่ตรงเงื่อนไข ไม่มีอุโมงค์ปรากฏ และทรัพยากรส่วนตัวก็หมดเวลาเฉย ๆ กรณีนี้วินิจฉัยผิดว่าเป็นปัญหาเซิร์ฟเวอร์ได้ง่าย เพราะไคลเอนต์ทำตามที่กำหนดไว้พอดี

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

ขั้นตอนที่ 5: ตรวจสอบ แล้วซ้อมการย้อนกลับ

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

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

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