Таны апп салсан гэж хэлж, цэсний мөр холбогдсон гэж хэлж, урсгал тодорхой урсаж байна. Энэ зөрүү дахин оролдлогоор засагдах уралдааны нөхцөл биш: апп болон туннель нь тусдаа процессууд бөгөөд таны код уншдаг объект нь системийн хадгалдаг тохиргооны кэшлэгдсэн дүрс юм. Apple-н Personal VPN гадаргуу нь удирдлагын API, өгөгдлийн зам биш бөгөөд түүний хачин зан авирын ихэнх нь энэ нэг баримтаас үүдэлтэй. Дуудлага бүрт үнэндээ юу болдог тал нь энэ.

Менежерийн объект бол кэшлэгдсэн дүрс, туннель биш

NETunnelProviderManager системийн эзэмшдэг тохиргооны агуулахаас дүүрдэг тул loadFromPreferences дуусах хүртэл түүний шинж чанарууд ямар ч утгагүй. Түүнээс өмнө connection.status уншвал та өгөгдмөл утга авна, тиймээс дахин асаасны дараах эхний төлөвийн шинэчлэлт туннель ажиллаж байхад салсан гэж мэдээлдэг. Эхлээд ачаалж, дараа нь төлөв болон протоколын тохиргоог мөн адил дуусгах боловсруулагчаас уншина уу. Дараагийн өөрчлөлтийг санал асуулгын оронд NEVPNStatusDidChange-аар ажиглаж, мэдэгдэл On Demand-оос эхэлсэн холболтуудад ч ажилладаг гэдгийг анхаарна уу, тэнд ямар нэг зүйлийг буцаах аппын дуудлага огт байхгүй. Протоколын тохиргоонд ч мөн адил: тэдгээрийг ачаалсан тохиргооноос уншдаг, аппын дамжуулснаас биш.

Туннель өөрөө Network Extension нийлүүлэгчийн процесст амьдардаг тул апп холболтоо алдалгүй өөрийн төлөвөө алдаж болно. Интерфейс харуулж буй бүхнийг менежерээс дахин бүтээх ёстой, өмнөх сессээс санах ёсгүй.

Эхлүүлэх дараалал: хадгал, ачаал, дараа нь эхлүүл

Нийлүүлэгчид суурилсан холболт дарааллаар гурван алхам шаарддаг. Нийлүүлэгчийн тохиргоог бичээд saveToPreferences дуудаж, хадгалсан тохиргоо таны гарт байгаа нь болохын тулд менежерийг ачаалж, дараа нь NETunnelProviderSession.startVPNTunnel()-ээр эхлүүлнэ үү. Хадгалалтыг алгасвал эхлүүлэхэд эхлүүлэх зүйл байхгүй; хадгалахаас өмнө ачаалбал менежер хуучин тохиргоог хэвээр илэрхийлнэ.

startVPNTunnel-ийн буцаах логик утга нь хүсэлт хүлээн авсан гэдгийг л хэлнэ. Нийлүүлэгчийн түвшний алдаа нь дараа нь салсан төлөв рүү шилжих байдлаар ирдэг бөгөөд үүнийг та NEVPNStatusDidChange мэдэгдлээр ажиглана, мэдэгдлийн боловсруулагч loadFromPreferences-ийн дараа connection.status-ыг дахин унших ёстой, учир нь кэшлэгдсэн утга хуучин хэвээр байж болно. Хүсэлтийн түвшний алдаа нь дуудлагын үл хамаарах зүйл шиддэг хэлбэрээс шууд буцаж ирдэг эсвэл startVPNTunnelAndReturnError:-ийн алдааны гаралтын параметрээр ирдэг. Буцаасан утгыг үр дүн гэж үздэг код хэзээ ч тогтоогдоогүй холболтыг мэдээлдэг. Өөр нэг чимээгүй алдаа нь суулгасан өргөтгөлтэй тохирохгүй нийлүүлэгчийн багц танигч юм: хүсэлт татгалзагдаж, мессежид юу ч танигч руу заахгүй. Танигч буруу бол хүсэлт ихэвчлэн тэр даруй бүтэлгүйтдэг, нийлүүлэгчийн нэг ч логийн мөр гарахаас өмнө.

Эхлүүлсний дараа тохиргоог дахин ачаалах нь төлөвийн дэлгэцүүдийг зөв болгодог. Систем тохиргоог өөрчлөхөд менежер танд шинэ тохиргоо түлхдэггүй.

Итгэлийн материал профайлаар ирдэг, хэзээ ч аппын кодоос биш

Апп нь iOS-ийн итгэлийн агуулахад үндсэн гэрчилгээ нэмэх дэмжигдсэн аргагүй тул Personal VPN тохиргоо зөвхөн төхөөрөмж аль хэдийн итгэдэг материалд лавлаж болно: суулгасан профайл, төхөөрөмжийн удирдлага эсвэл систем өөр шалтгаанаар итгэдэг CA-ийн үүсгэсэн гинжид. Эхний ажиллагаанд өөрийн CA-г үүсгээд систем үүнийг хүлээн зөвшөөрнө гэж хүлээдэг апп нийлүүлэгчийн доторх баталгаажуулалтад бүтэлгүйтнэ, тэнд аппын интерфейс шалтгааныг харж чадахгүй.

Энэ хил хязгаарыг байгаагаар нь дизайны хязгаарлалт гэж үзэж, итгэлийн зангууг бүртгэлийн профайлын хамт хүргэнэ үү. VPN баталгаажуулалтыг итгэлийн шийдвэрээс тусдаа байлга, учир нь тэд өөр өөр газарт бүтэлгүйтдэг бөгөөд өөр өөр хүмүүс алдааг нь засдаг.

Тоолуурууд интерфейсээс ирдэг, VPN API-аас биш

Менежер төлөв болон тохиргоог ил гаргадаг бөгөөд туннель бүрийн байтыг тоолдог зүйл байхгүй. Хэрэв танд хэрэглээний тоо хэрэгтэй бол getifaddrs() дуудаж, холбогдох интерфейсийн if_data-ыг уншина уу: Wi-Fi-д en0, үүрэн холбоонд pdp_ip интерфейсүүд, туннельд өөрт нь utun төхөөрөмж. utun тоолуурууд дотоод урсгалыг тодорхойлж, протоколын нэмэлт зардлыг агуулна.

Эдгээр тоо нь тооцоо бөгөөд апп тус бүрийн бүртгэл биш, интерфейс дахин үүсэхэд тэдгээр тэглэгдэнэ. Интерфейс дээр тэдгээрийг ингэж шошгоно уу, эс тэгвээс хэн нэгэн тэдгээрийг харилцагчид нэхэмжлэхэд ашиглана. Хэрэв танд апп тус бүрийн тоо хэрэгтэй бол огт өөр механизм хэрэгтэй, эдгээр талбарыг илүү сайн унших нь биш.

Цэвэрлэгээ stopVPNTunnel-д хамаарна, дуусгахад биш

applicationWillTerminate систем процессорыг алж болохоос өмнө танд хэдэн секунд өгдөг бөгөөд энэ нь холболтыг салгахад найдвартай газар биш. Зогсоолтыг stopVPNTunnel() руу илгээх эсвэл нийлүүлэгчийн зогсоолтын буцаан дуудлагад шийдвэрлэж, эхлүүлсэн менежер эсвэл тохиргооны танигчийг хадгал, ингэснээр зогсоолт төхөөрөмж дээрх бүх тохиргоог биш, тэр холболтыг чиглүүлнэ.

Тэр танигчийг хамаарах профайлын хажууд хадгал, учир нь менежерийн объект хэрэглэгч аль тохиргоог сонгосныг бүртгэдэггүй. Мөн On Demand-ийн өргөсөн холболтын ард аппын дуудлага огт байхгүй гэдгийг сана, тиймээс төлөвийн дэлгэц ямар нэг зүйл зурахаас өмнө тохиргоог ачаалах ёстой хэвээр.

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