Pse një aplikacion nuk mund të aktivizojë një profil VPN të ruajtur në Android ose iOS

Dy punë shumë të ndryshme renditen nën emrin VPN programatik, dhe vetëm njëra prej tyre është në dispozicion për një aplikacion të zakonshëm në secilën nga dy platformat mobile. E para është aktivizimi i një profili që përdoruesi e ka ruajtur tashmë; e dyta është ndërtimi i një tuneli brenda procesit tuaj. Android ju jep të dytën përmes VpnService dhe iOS ju jep të dytën përmes së drejtës Network Extension, ndërsa e para mbetet me sistemin, me pronarin e pajisjes ose me një server MDM. Të kuptuarit se cila ju nevojitet vërtet e bën zakonisht projektin më të vogël.

Dy punë që ndajnë një emër

Aktivizimi i një profili të ruajtur do të thotë t'i thuash një tuneli ekzistues të ngrihet: një host, një kredencial, një protokoll, të gjitha të konfiguruara tashmë në një vend që përdoruesi mund ta shohë. Ndërtimi i një tuneli do të thotë që kodi juaj zotëron ndërfaqen, ciklin e paketave dhe protokollin. Duken të ngjashëm në backlogun e produktit dhe pothuajse nuk ndajnë implementim.

Asnjëra nga dy platformat mobile nuk e ekspozon të parën ndaj një aplikacioni SDK. Një lidhje që shfaqet pa bërë asgjë përdoruesi nuk dallohet dot nga softueri keqdashës, prandaj të dy sistemet vendosin një portë pëlqimi përpara çdo aplikacioni që transporton trafik.

Android: një portë pëlqimi dhe asnjë API profili

VpnService ekziston që nga Android 4.0 dhe lejon një aplikacion të krijojë një ndërfaqe tun, pastaj të lexojë dhe shkruajë paketa. Shërbimi duhet të deklarohet me BIND_VPN_SERVICE, dhe VpnService.prepare() prodhon dialogun e sistemit që i kërkon përdoruesit ta lejojë. Shembulli i platformës, ToyVpn, është deklarata më e qartë e formës së synuar: kodi juaj zotëron ndërfaqen dhe gjithçka që rrjedh përmes saj.

Ajo që nuk bën është të shtojë një zë në ekranin e cilësimeve të VPN të sistemit. Nuk ka API publik për këtë, dhe aplikacioni Cilësimet i mban profilet e tij në një depo që një aplikacion i zakonshëm nuk arrin ta prekë. Thirrjet drejt klasave të fshehura nga një aplikacion normal prodhojnë profile që sistemi nuk i liston kurrë, prandaj kodi që dukej se funksiononte në një kompilim ndalon në heshtje së funksionuari në tjetrin.

Rruga e menaxhuar është e veçantë. Një pronar pajisjeje ose profili mund të caktojë një paketë VPN gjithmonë të ndezur përmes API-ve të politikës së pajisjes, dhe një mjet ndërmarrjeje mund të dërgojë një profil që përdoruesi e miraton më pas. Ky është autoritet i menaxhimit të pajisjes, jo një leje që aplikacioni kërkon në instalim. Nëse klienti juaj është një organizatë, kjo është rruga për të cilën duhet të planifikoni; nëse klienti juaj është një person që instalon nga një dyqan, ajo nuk është fare e disponueshme.

iOS: e drejta është kufiri

iOS e ndan të njëjtën punë ndryshe. Një klient VPN implementon një ofrues tuneli paketash ose një përfaqësues aplikacioni brenda kornizës Network Extension, dhe e drejta përkatëse duhet t'i jepet llogarisë së zhvilluesit. Një konfigurim personal VPN përmes NEVPNManager ekziston për rastin më të thjeshtë, dhe ai vazhdon të ekzekutohet brenda të njëjtit model lejesh. Apple dokumenton të gjithë sipërfaqen në referencën Network Extension, që ia vlen të lexohet përpara se të përcaktoni fushën e punës.

Nuk ka asnjë mënyrë të mbështetur për të hapur ekranin e cilësimeve të VPN, për të lexuar konfigurimet e ruajtura të përdoruesit ose për të nisur një prej tyre. Ajo që një klient mund të bëjë është të dërgojë një profil konfigurimi që përdoruesi ta instalojë, dhe pastaj të përdorë tunelin që rezulton përmes thirrjeve normale të rrjetit. Tunelimi për çdo aplikacion caktohet nga një server MDM përmes një rregulli sipas kërkesës, nuk zgjidhet nga aplikacioni në kohë ekzekutimi.

Një klient VPN nga një furnizues i madh nuk është provë që llogaria juaj mund të dërgojë të njëjtën gjë. Ato të drejta kërkohen për çdo llogari zhvilluesi dhe shqyrtohen, prandaj rreziku i afatit qëndron te Apple, jo në planin tuaj të sprintit.

Desktopi arrin më larg, por pronësia nuk ndryshon

Windows është rasti lejues. Add-VpnConnection krijon një zë në librin e telefonit nga një sesion PowerShell i ngritur, dhe rasdial e lidh ose e shkëput nga një skript. Një aplikacion mund të drejtojë gjithashtu një klient furnizuesi përmes linjës së tij të komandës të dokumentuar. Krijimi i profilit është ende veprim administrativ, sepse zëri jeton në një depo për të gjithë makinën.

macOS sillet njësoj me mjete të tjera. scutil --nc start dhe stop veprojnë mbi shërbime që ekzistojnë tashmë, ndërsa krijimi i njërit është detyrë e administrimit të sistemit. Zotërimi i procesit në një laptop nuk ju bën pronar të konfigurimit.

Çfarë të ndërtoni në vend të kësaj

Nëse kërkesa e vërtetë është që aplikacioni juaj të arrijë një API të brendshme, tuneli që përdoruesi ekzekuton tashmë është i mjaftueshëm. Dërgoni kërkesa normale HTTPS, lini sistemin të zgjedhë rrugën, dhe ndaloni së provuari të kontrolloni tunelin. Nëse kërkesa është që vetëm trafiku i aplikacionit tuaj të përdorë tunelin, kërkoni VPN për çdo aplikacion përmes kanalit të menaxhimit, ose përfundoni TLS brenda aplikacionit ndaj një shërbimi të arritshëm pa të.

API-t e fshehura nuk janë një shkurtore që ia vlen të merret. Ndryshojnë mes versioneve, dështojnë në shqyrtimin e aplikacioneve, dhe dështimet që prodhojnë duken për atë që trashëgon kodin si dështime normale rrjeti. Krahasimi nuk është Android kundër iOS; është zotërimi i një tuneli kundër kërkesës që platforma të drejtojë trafikun, dhe vetëm e para është e juaja për t'u ndërtuar.