iOS VPN API: NEVPNManager, туннелийн нийлүүлэгч эсвэл профайл?

Ярих ёстой транспортоор API-г сонгоод, дараа нь туннель трафик зөөж байгааг нотлоорой: save-load-start дараалал, provider entitlement болон on-demand дүрэм.

iOS VPN гэдэг нэрэнд гурван өөр бүтээгдэхүүн хариулдаг бөгөөд тэд нэг API-г хуваалцдаггүй. Personal VPN нь системийн суурилагдсан IPsec болон IKEv2 транспорт ашигладаг. Custom tunnel нь өөрийн протоколыг network extension дотор ажиллуулдаг. Configuration profile нь аль нэгийг нь тохируулж, on-demand зан төлөвийг нэмж болно. Ямар ч tutorial эхлээд компил болсноор сонгохоос илүү, ярих ёстой транспортоор сонгох нь илүү хурдан.

Доорх шалгалтуудыг дарааллаар гүйцэтгэнэ, учир нь алхам бүр өмнөх нь хүчинтэй тохиргоо гаргасан гэж үздэг.

1-р алхам: транспортоор сонгох

Хэрэв сервер нь IKEv2 эсвэл Cisco хэв маягийн IPsec бол NEVPNManager хангалттай бөгөөд системийн транспортууд үнэгүй ирдэг. Хэрэв сервер OpenVPN, WireGuard эсвэл өөр зүйлээр ярьдаг бол NEVPNManager туслахгүй: гуравдагч этгээдийн протоколд түүнд дэгээ байхгүй. Энэ тохиолдолд протоколыг хэрэгжүүлдэг packet tunnel provider-тай NETunnelProviderManager хэрэгтэй. Профайл нь зөвхөн тохиргоог түгээдэг бөгөөд үйлдлийн системд байхгүй транспортыг нэмж чадахгүй.

PPTP нь одоогийн системд зорилт биш. Shared-secret IPsec нь 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-аас уншина. Дуудлагын газарт амжилт гэж үздэг апп нь extension хэлэлцээр хийсээр байхад VPN холбогдсон гэж мэдээлдэг. Connecting төлөв хормын хугацаанд хэвийн; түүнээс хэзээ ч гарахгүй төлөв нь бүртгэх үнэ цэнэтэй алдаа.

3-р алхам: provider процессд хэрэгтэй зүйлээ өгөх

Custom transport нь өөрийн bundle identifier болон өөрийн entitlement-тай тусдаа процесст ажилладаг. container апп болон provider хоёулаа гарын үсэг зурах үед network-extension entitlement шаарддаг бөгөөд App Store-оос гадуурх Developer ID build үүнийг provisioning profile-д авч явах ёстой. Дутуу entitlement нь протоколын алдаа мэт харагддаг, учир нь extension эхлэхгүй л байдаг.

Зээлэх нийтийн socket descriptor байхгүй. NEPacketTunnelProvider танд read, write болон cancel-тай NEPacketTunnelFlow өгдөг бөгөөд хувийн түлхүүрийн замд хүрдэг код хувилбаруудын хооронд эвдэрдэг. Апп background-д байх үед provider ажилласаар байдаг тул container апп-д үүнд background горим хэрэггүй.

4-р алхам: on-demand бол дүрмийн багц, унтраалга биш

isOnDemandEnabled нь зөвхөн дүрмүүдийг бэлддэг; туннель хэзээ босохыг NEOnDemandRuleConnect болон түүний ахан дүүс шийддэг. probe URL-тай evaluate-connection дүрэм нь тухайн URL-ын чанартай л тэнцэнэ. Хэрэв probe туннельгүйгээр хариулбал, дүрэм хувийн сүлжээнд аль хэдийн хүрч болно гэж дүгнэж, хэзээ ч холбогддоггүй тул зөвхөн дотроос хариулдаг зүйл рүү чиглүүлээрэй.

Always-on нь тусдаа амлалт. Түүнд хяналттай төхөөрөмж болон удирдлагатай профайл хэрэгтэй бөгөөд хяналтгүй хэрэглэгч профайлыг хүссэн үедээ устгаж болно. Флот хяналтад байхгүй л бол always-on-д тулгуурласан загварыг гаргах хэрэггүй.

5-р алхам: шошгыг биш, замыг нотлох

tun, tap, ppp эсвэл ipsec интерфейсийг скан хийх нь VPN тохируулагдсаныг нотолдог, таны хүсэлт үүнийг ашигласныг биш. usesInterfaceType(.other)-тай NWPathMonitor виртуал интерфейс боломжтой гэж хэлдэг бөгөөд viability handler нэг хост шалгаж чадна. Аль нь ч гарах замыг нотолдоггүй тул тэдгээрийг зөвхөн туннель хүрч чадах нөөц рүү хүсэлттэй хослуулаарай. Интерфейсийн нэрнүүд нь оношлогооны туслах бөгөөд аппын логик салбарлах ёстой хаалга хэзээ ч биш.

Хээрийн шалгалтын хувьд нийтийн хаягийг туннельтэй болон тунгүйгээр харьцуулж, зөвхөн дотоод хуудсыг татаж авна. provider хэлэлцэж байх үед status дуудлага холбогдсон гэж мэдээлж болзошгүй тул шийдвэрийг нөөцийн үр дүнд үлдээж, status-ыг дэмжих нотолгоо гэж үзээрэй.

Холбоотой нийтлэлүүд