API ของ VPN บน iOS: NEVPNManager, ผู้ให้บริการอุโมงค์ หรือโปรไฟล์?

ผลิตภัณฑ์ที่แตกต่างกันสามชนิดตอบชื่อ iOS VPN และไม่ได้ใช้ API ร่วมกัน Personal VPN ใช้การขนส่ง IPsec และ IKEv2 ที่มีมาในระบบ Custom tunnel รันโปรโตคอลของคุณเองภายใน network extension Configuration profile กำหนดค่าใดค่าหนึ่งและเพิ่มพฤติกรรม on-demand ได้ การเลือกตามการขนส่งที่คุณต้องพูดคุยด้วยเร็วกว่าการเลือกตามบทช่วยสอนที่คอมไพล์สำเร็จก่อน

รันการตรวจสอบด้านล่างตามลำดับ เพราะแต่ละขั้นตอนถือว่าขั้นตอนก่อนหน้าสร้างการกำหนดค่าที่ถูกต้องแล้ว

ขั้นตอนที่ 1: เลือกตามการขนส่ง

หากเซิร์ฟเวอร์เป็น IKEv2 หรือ IPsec สไตล์ Cisco การใช้ NEVPNManager ก็เพียงพอและการขนส่งของระบบมาฟรี หากเซิร์ฟเวอร์พูด OpenVPN, WireGuard หรืออย่างอื่น NEVPNManager ช่วยไม่ได้: มันไม่มีจุดเชื่อมสำหรับโปรโตคอลของบุคคลที่สาม กรณีนั้นต้องใช้ NETunnelProviderManager พร้อม packet tunnel provider ที่ใช้งานโปรโตคอล โปรไฟล์เพียงแจกจ่ายการกำหนดค่า และไม่สามารถเพิ่มการขนส่งที่ระบบปฏิบัติการไม่มีได้

PPTP ไม่ใช่เป้าหมายในระบบปัจจุบัน IPsec แบบ shared secret ยังคงคาดหวังชื่อกลุ่มใน remoteIdentifier รายการ keychain ที่เก็บความลับ และการตรวจสอบสิทธิ์แบบขยายเมื่อเซิร์ฟเวอร์ขอชื่อผู้ใช้ ชิ้นส่วนที่หายไปแต่ละชิ้นปรากฏเป็นข้อผิดพลาดการกำหนดค่าแบบทั่วไปเดียวกัน ดังนั้นเพิ่มให้ครบทั้งหมดก่อนดีบักอย่างอื่น

ขั้นตอนที่ 2: เคารพลำดับบันทึก โหลด เริ่ม

NEVPNManager เขียนลง preferences อ่านกลับ แล้วจึงเริ่ม เติมออบเจ็กต์โปรโตคอลและ manager เรียก saveToPreferences เรียก loadFromPreferences และเรียก startVPNTunnel จาก load completion handler การเริ่มก่อนการโหลดกลับมาทำให้เกิดข้อผิดพลาด configuration-invalid, NEVPNErrorDomain code 1 ในการกำหนดค่าที่ถูกต้องอยู่แล้ว

รูปแบบสั้นพอที่จะเก็บไว้ที่เดียว:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel คืนค่าเมื่อคำขอได้รับการยอมรับ ไม่ใช่เมื่ออุโมงค์ขึ้นแล้ว สังเกต NEVPNStatusDidChange และอ่าน connection.status เพื่อดูสถานะจริง แอปที่ถือว่าสำเร็จ ณ จุดเรียก รายงานว่า VPN เชื่อมต่อแล้วในขณะที่ extension ยังเจรจาอยู่ สถานะ connecting เป็นเรื่องปกติชั่วครู่ สถานะที่ไม่เคยออกจากมันคือความล้มเหลวที่ควรบันทึก

ขั้นตอนที่ 3: ให้สิ่งที่โปรเซส provider ต้องการ

Custom transport ทำงานในโปรเซสแยกที่มี bundle identifier ของตัวเองและ entitlement ของตัวเอง ทั้งแอป container และ provider ต้องมี entitlement network-extension ตอนเซ็นชื่อ และ build แบบ Developer ID นอก App Store ก็ยังต้องพกมันไว้ใน provisioning profile entitlement ที่หายไปดูเหมือนบั๊กโปรโตคอลเพราะ extension ไม่เริ่มทำงานเลย

ไม่มี socket descriptor สาธารณะให้ยืม NEPacketTunnelProvider ให้ NEPacketTunnelFlow พร้อม read, write และ cancel แก่คุณ และโค้ดที่เอื้อมถึงเส้นทางคีย์ส่วนตัวจะพังระหว่างรีลีส provider ยังทำงานต่อไปขณะแอปอยู่ในเบื้องหลัง ดังนั้นแอป container ไม่ต้องมีโหมดเบื้องหลังสำหรับเรื่องนี้

ขั้นตอนที่ 4: on-demand คือชุดกฎ ไม่ใช่สวิตช์

isOnDemandEnabled เพียงติดอาวุธกฎเท่านั้น NEOnDemandRuleConnect และพี่น้องของมันตัดสินใจว่าอุโมงค์จะขึ้นเมื่อใด กฎ evaluate-connection ที่มี probe URL ดีได้เท่ากับ URL นั้น หาก probe ตอบโดยไม่มีอุโมงค์ กฎจะสรุปว่าเครือข่ายส่วนตัวเข้าถึงได้แล้วและจะไม่เชื่อมต่อเลย ดังนั้นชี้ไปที่สิ่งที่ตอบเฉพาะจากภายใน

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

ขั้นตอนที่ 5: พิสูจน์เส้นทาง ไม่ใช่ป้ายชื่อ

การสแกนหาอินเทอร์เฟซ tun, tap, ppp หรือ ipsec พิสูจน์ว่ามีการกำหนดค่า VPN ไม่ใช่คำขอของคุณใช้มัน NWPathMonitor ที่ใช้ usesInterfaceType(.other) บอกว่ามีอินเทอร์เฟซเสมือน และ viability handler ทดสอบโฮสต์หนึ่งเครื่องได้ ทั้งสองไม่ได้พิสูจน์เส้นทางออก ดังนั้นรวมมันเข้ากับคำขอไปยังทรัพยากรที่อุโมงค์เท่านั้นเข้าถึงได้ ชื่ออินเทอร์เฟซเป็นเครื่องช่วยวินิจฉัย ไม่ใช่ประตูที่ตรรกะของแอปควรแยกสาขา

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