ทำไมแอปจึงเปิดโปรไฟล์ VPN ที่บันทึกไว้บน Android หรือ iOS ไม่ได้
การสร้างอุโมงค์ของคุณเองกับการเปิดโปรไฟล์ที่บันทึกไว้เป็นงานสองอย่างที่ต่างกัน เปรียบเทียบสิ่งที่ Android, iOS และเดสก์ท็อปอนุญาตให้แอปทำได้จริง
งานสองอย่างที่แตกต่างกันอย่างสิ้นเชิงถูกจัดไว้ใต้ชื่อ VPN เชิงโปรแกรม และมีเพียงอย่างเดียวเท่านั้นที่แอปทั่วไปเข้าถึงได้บนแพลตฟอร์มมือถือทั้งสองแห่ง อย่างแรกคือการเปิดโปรไฟล์ที่ผู้ใช้บันทึกไว้แล้ว ส่วนอย่างที่สองคือการสร้างอุโมงค์ภายในโปรเซสของคุณเอง Android มอบอย่างที่สองผ่าน VpnService และ iOS มอบอย่างที่สองผ่านสิทธิ์ Network Extension ขณะที่อย่างแรกยังคงอยู่กับระบบ เจ้าของอุปกรณ์ หรือเซิร์ฟเวอร์ MDM การระบุว่าคุณต้องการสิ่งใดจริง ๆ มักทำให้โครงการเล็กลง
สองงานที่ใช้ชื่อเดียวกัน
การเปิดใช้งานโปรไฟล์ที่บันทึกไว้หมายถึงการสั่งให้อุโมงค์ที่มีอยู่ยกขึ้น ได้แก่ โฮสต์ ข้อมูลรับรอง โปรโตคอล ทั้งหมดถูกกำหนดค่าไว้แล้วในที่ที่ผู้ใช้มองเห็น ส่วนการสร้างอุโมงค์หมายถึงโค้ดของคุณเป็นเจ้าของอินเทอร์เฟซ ลูปแพ็กเก็ต และโปรโตคอล ทั้งสองดูคล้ายกันในรายการงานผลิตภัณฑ์และแทบไม่ใช้การนำไปใช้ร่วมกันเลย
ไม่มีแพลตฟอร์มมือถือใดเปิดเผยอย่างแรกให้แอป SDK การเชื่อมต่อที่ปรากฏขึ้นโดยที่ผู้ใช้ไม่ได้ทำอะไรเลยนั้นแยกไม่ออกจากมัลแวร์ ดังนั้นทั้งสองระบบจึงวางประตูความยินยอมไว้หน้าทุกแอปที่รับส่งข้อมูล
Android: ประตูความยินยอม และไม่มี API สำหรับโปรไฟล์
VpnService มีมาตั้งแต่ Android 4.0 และให้แอปสร้างอินเทอร์เฟซ tun จากนั้นอ่านและเขียนแพ็กเก็ต บริการต้องถูกประกาศด้วย BIND_VPN_SERVICE และ VpnService.prepare() สร้างกล่องโต้ตอบของระบบที่ขอให้ผู้ใช้อนุญาต ตัวอย่างของแพลตฟอร์มอย่าง ToyVpn คือคำแถลงที่ชัดเจนที่สุดของรูปแบบที่ตั้งใจไว้: โค้ดของคุณเป็นเจ้าของอินเทอร์เฟซและทุกสิ่งที่ไหลผ่าน
สิ่งที่มันไม่ทำคือการเพิ่มรายการในหน้าจอการตั้งค่า VPN ของระบบ ไม่มี API สาธารณะสำหรับสิ่งนั้น และแอปการตั้งค่าเก็บโปรไฟล์ไว้ในที่จัดเก็บที่แอปทั่วไปเข้าถึงไม่ได้ การเรียกคลาสที่ซ่อนอยู่จากแอปปกติจะสร้างโปรไฟล์ที่ระบบไม่เคยแสดงรายการ ซึ่งเป็นเหตุให้โค้ดที่ดูเหมือนทำงานในบิลด์หนึ่งหยุดทำงานอย่างเงียบ ๆ ในบิลด์ถัดไป
เส้นทางที่จัดการนั้นแยกออกมา เจ้าของอุปกรณ์หรือเจ้าของโปรไฟล์สามารถกำหนดแพ็กเกจ VPN ที่เปิดตลอดเวลาผ่าน API นโยบายอุปกรณ์ และเครื่องมือองค์กรสามารถส่งโปรไฟล์ที่ผู้ใช้อนุมัติในภายหลัง นี่คืออำนาจการจัดการอุปกรณ์ ไม่ใช่สิทธิ์ที่แอปขอตอนติดตั้ง หากลูกค้าของคุณเป็นองค์กร นี่คือเส้นทางที่ต้องวางแผน หากลูกค้าของคุณเป็นบุคคลที่ติดตั้งจากร้านค้า ก็ไม่มีให้ใช้เลย
iOS: สิทธิ์คือขอบเขต
iOS แบ่งงานเดียวกันต่างออกไป ไคลเอนต์ VPN จะใช้งานผู้ให้บริการอุโมงค์แพ็กเก็ตหรือพร็อกซีแอปภายใต้เฟรมเวิร์ก Network Extension และสิทธิ์ที่สอดคล้องต้องมอบให้บัญชีนักพัฒนา การกำหนดค่า VPN ส่วนบุคคลผ่าน NEVPNManager มีอยู่สำหรับกรณีที่ง่ายกว่า และยังทำงานภายใต้แบบจำลองสิทธิ์เดียวกัน Apple จัดทำเอกสารพื้นผิวทั้งหมดไว้ใน เอกสารอ้างอิง Network Extension ซึ่งคุ้มค่าที่จะอ่านก่อนกำหนดขอบเขตงาน
ไม่มีวิธีที่รองรับในการเปิดหน้าจอการตั้งค่า VPN อ่านการกำหนดค่าที่บันทึกไว้ของผู้ใช้ หรือเริ่มหนึ่งในนั้น สิ่งที่ไคลเอนต์ทำได้คือส่งโปรไฟล์การกำหนดค่าให้ผู้ใช้ติดตั้ง แล้วใช้อุโมงค์ที่ได้ผ่านการเรียกเครือข่ายปกติ การทำอุโมงค์รายแอปถูกกำหนดโดยเซิร์ฟเวอร์ MDM ผ่านกฎตามต้องการ ไม่ใช่แอปเลือกเองในขณะรัน
ไคลเอนต์ VPN จากผู้จำหน่ายรายใหญ่ไม่ใช่หลักฐานว่าบัญชีของคุณส่งสิ่งเดียวกันได้ สิทธิ์เหล่านั้นถูกขอเป็นรายบัญชีนักพัฒนาและถูกตรวจสอบ ดังนั้นความเสี่ยงด้านกำหนดการจึงอยู่ที่ Apple ไม่ใช่แผนสปรินต์ของคุณ
เดสก์ท็อปไปได้ไกลกว่า แต่ความเป็นเจ้าของไม่เปลี่ยน
Windows เป็นกรณีที่อนุญาต Add-VpnConnection สร้างรายการสมุดโทรศัพท์จากเซสชัน PowerShell ที่ยกระดับ และ rasdial เชื่อมต่อหรือตัดการเชื่อมต่อจากสคริปต์ แอปยังสามารถขับเคลื่อนไคลเอนต์ของผู้จำหน่ายผ่านบรรทัดคำสั่งที่มีเอกสารได้ การสร้างโปรไฟล์ยังเป็นการดำเนินการด้านการบริหาร เพราะรายการอาศัยอยู่ในที่จัดเก็บระดับเครื่อง
macOS ทำงานแบบเดียวกันด้วยเครื่องมือต่างกัน scutil --nc start และ stop ทำงานกับบริการที่มีอยู่แล้ว ขณะที่การสร้างใหม่เป็นงานดูแลระบบ การเป็นเจ้าของโปรเซสบนแล็ปท็อปไม่ได้ทำให้คุณเป็นเจ้าของการกำหนดค่า
สิ่งที่ควรสร้างแทน
หากความต้องการจริงคือให้แอปของคุณเข้าถึง API ภายใน อุโมงค์ที่ผู้ใช้รันอยู่แล้วก็เพียงพอ ส่งคำขอ HTTPS ปกติ ปล่อยให้ระบบเลือกเส้นทาง และเลิกพยายามควบคุมอุโมงค์ หากความต้องการคือให้เฉพาะทราฟฟิกของแอปคุณใช้อุโมงค์ ให้ขอ VPN รายแอปผ่านช่องทางจัดการ หรือยุติ TLS ภายในแอปกับบริการที่เข้าถึงได้โดยไม่ต้องใช้อุโมงค์
API ที่ซ่อนอยู่ไม่ใช่ทางลัดที่คุ้มค่า มันเปลี่ยนไประหว่างรีลีส ทำให้การตรวจสอบแอปไม่ผ่าน และความล้มเหลวที่เกิดขึ้นดูเหมือนปัญหาครือข่ายปกติสำหรับคนที่รับช่วงโค้ดต่อ การเปรียบเทียบไม่ใช่ Android กับ iOS แต่คือการเป็นเจ้าของอุโมงค์กับการขอให้แพลตฟอร์มกำหนดเส้นทางทราฟฟิก และมีเพียงอย่างแรกเท่านั้นที่เป็นของคุณให้สร้าง