Nasa VPN ba ang iPhone? Ano ang talagang nakikita ng isang iOS app
Walang iisang flag ng VPN sa iOS SDK. Ang app ay makakapagmasid lamang ng sarili nitong configuration, isang notification ng status at isang limitadong snapshot ng proxy, wala nang iba.
Tanungin ang isang iOS app kung ang telepono ay nasa VPN, at ang tapat na sagot ay hindi nito malalaman sa paraang ibig mong sabihin. Hindi naglalantad ang SDK ng flag para sa «ang device ay nasa isang tunnel», at ang mga pribadong interface na maaaring makalapit doon ay sarado sa mga app na inilalathala. Maaari mong pagmasdan ang configuration ng sarili mong app, ang status na nakakabit dito, at isa o dalawang indirect na pahiwatig mula sa network stack. Bawat isa ay sumasagot sa ibang tanong, at karamihan sa mga sirang pagsusuri ay nagmumula sa pagkuha sa isa sa kanila bilang buong sagot.
Ang alamat ng iisang flag ng VPN
Ang paniniwala ay mayroong property sa isang lugar sa SDK na nag-uulat kung ang device ay nasa tunnel, tulad ng flag ng reachability na nag-uulat kung may tumutugon na host. Walang ganoong pampublikong property. At kahit mayroon, ang «may tunnel» at «ginagamit ito ng trapiko ko» ay magkaibang pahayag, at para sa karamihan ng app ang pangalawa lamang ang mahalaga.
Ang agwat na iyon ang dahilan kung bakit ang mga library na nag-aanunsyo ng one-line na VPN detector ay madalas na nagbabasa ng isang marupok, tulad ng pangalan ng interface o susi ng proxy, at inilalahad ito bilang hatol.
I-load ang mga preference bago magtiwala sa isang nil
Umiiral ang shared manager instance sa sandaling hingin mo ito, ngunit ang property ng protocol nito ay nananatiling nil hanggang matapos ang load callback. Kaya ang nil protocol ay nangangahulugang «hindi pa na-load» nang hindi bababa sa kasingdalas ng «hindi naka-install». Gawin ang pagbasa sa loob ng completion block, at pagkatapos lamang magpasya: ang isang protocol object na umiiral, na may naka-on na enable flag, ay ganoon ang hitsura ng «naka-install».
Ang ikalawang senyales ay nasa connection object: ang invalid na estado, na iniuulat ng system kapag ang app na ito ay walang naka-install na configuration. Ang invalid na status kasama ng isang nil protocol pagkatapos ng kumpletong pag-load ay tunay na kawalan, hindi isang karera ng oras.
Dumarating ang mga pagbabago ng koneksyon bilang mga notification
Ang mga handler na ibinibigay sa load at save ay nag-uulat kung ano ang nangyari sa configuration, hindi kung ano ang ginagawa ng tunnel. Ang paghihintay na mag-trigger ang isa sa kanila sa oras ng pagkonekta ay isang karerang hindi kailanman nalulutas. Sa halip, panoorin ang notification ng pagbabago ng status, at basahin ang kasalukuyang halaga ng connection object kapag dumating ito.
Kapag naka-install na ang isang configuration, dumadaan ang estado ng koneksyon sa isang maikling pagkakasunod-sunod: disconnected, kumokonekta, konektado, muling nagpapatibay, dumidiskonekta. Inilalarawan ng «konektado» ang tunnel at hindi ang server sa likod nito, kaya hindi ito patunay na dumadaloy ang trapiko. Ang On-demand ay maaari ring magtaas ng tunnel habang suspendido ang app, at pagkatapos ay dumarating ang notification bago ka pa magkaroon ng anumang ia-update.
Ang limitadong snapshot ng proxy ay isang pahiwatig, hindi isang hatol
Maaaring ibigay ng CFNetwork sa app ang kasalukuyang mga setting ng proxy ng system, at sa loob ng resultang iyon ay may isang limitadong diksyunaryo na naka-key sa pangalan ng interface. Ang makakita ng pangalang nagsisimula sa tun, utun, ppp, ipsec o tap ay isang pahiwatig na may tunnel. Nananatili itong snapshot ng nakikita ng app na ito, hindi isang pahayag tungkol sa kung saan naglalakbay ang mga packet.
Hindi nagkakasundo ang mga provider sa pagpapangalan, kaya ang nawawalang prefix ay walang pinatutunayan, at ang isang interface na naroroon ay maaaring umiiral nang hindi nagdadala ng trapiko. Ang reachability ay mas mahina pa: ang matagumpay na kahilingan sa isang pribadong address ay nagpapakita na gumana ang landas para sa kahilingang iyon sa sandaling iyon, hindi na may naka-install na VPN.
Hinihiram ng simulator ang Mac, at nananatiling invisible ang ibang apps
Walang sariling network stack ang simulator; bawat koneksyong ginagawa nito ay sa Mac. Kaya ang VPN na tumatakbo sa host Mac ay may bisa na para sa simulate na app, at walang ipinapakita ang sariling mga setting ng simulator. Kung umangat ang tunnel pagkatapos magsimula ang simulator, karaniwang mas mabilis ang i-restart ito kaysa i-debug ang app. Ang host sa hindi standard na port ay nangangailangan ng port na iyon sa URL, o isang lokal na pagpapasa tulad ng socat TCP-LISTEN:12345,fork TCP:host:12345.
Hindi ililista ng mga pampublikong API ang mga profile ng VPN na pag-aari ng ibang apps o ng mga configuration profile. Para sa isang kilalang app, ang pagsusuri ng URL scheme sa pamamagitan ng canOpenURL ang portable na paraan, at mula iOS 9 ang scheme na itinatanong ay dapat ideklara sa iyong Info.plist; kung iiwan mo ito, ang tawag ay magbabalik ng false. Tumutugon ang OpenVPN Connect sa openvpn://, na ginagawa itong magandang halimbawa at masamang pangkalahatang detector.
Pagsamahin ang tatlong obserbasyon at sabihin kung ano ang ibig sabihin ng mga ito
Sa pagsasanay, ipatong ang tatlong resulta: isang configuration na na-load at naka-enable, isang estado ng koneksyon na hindi invalid, at isang kahilingan sa isang address na maaabot lamang sa pamamagitan ng tunnel. Ang bawat isa ay nakakalito nang mag-isa; kapag magkasama, sinasabi nila kung ano ang maaaring malaman ng app, hindi kung ano ang ipinapalagay ng user.
Isulat ang resulta bilang tatlong linya sa iyong diagnostics, hindi isang boolean. Kapag sinabi ng isang user na patay ang VPN habang hindi sumasang-ayon ang app mo, ipinapakita ng tatlong linya kung aling obserbasyon ang naiiba, at iyon ang pagkakaiba sa pagitan ng isang support ticket na maaari mong aksyunan at isa na nagtatapos sa «sa akin gumagana ito».