Kailangan ba ng VPN ng work app? Suriin muna ang tatlong layer na ito

Sinasabi ng mensahe na kailangan ng app ang VPN, ngunit karaniwang nag-uulat ang app ng sintomas kaysa pangalanan ang bagay na humadlang dito. Tatlong magkaibang may-ari ang maaaring gumawa ng pangungusap na iyon: ang pribadong serbisyo na kausap ng app, ang sariling patakaran code ng app at ang layer ng pamamahala ng device na kumokontrol sa work profile. Alin sa kanila ang nagtatanong ang nagbabago sa dapat mong gawin, at isa lang sa tatlo ang naaayos sa pamamagitan ng pagkonekta ng tunnel. Ang paghahanap muna sa may-ari ay nakakatipid sa iyo sa muling pag-install ng client na hindi naman kailanman naging problema.

Ano ang kayang suriin ng app mismo

Bago ipalagay ang isang nakatagong tuntunin ng platform, tandaan na kayang makita ng ordinaryong app kung aktibo ang VPN transport. Nag-uulat ang ConnectivityManager ng mga network na may TRANSPORT_VPN, at ang kawalan ng NET_CAPABILITY_NOT_VPN ay nagsasabi sa sinumang tumatawag na ang kasalukuyang landas ay dumadaan sa tunnel. Ang developer na gustong tumangging tumakbo sa labas ng tunnel ay magagawa ito gamit ang mga public API at nang walang anumang tool ng enterprise.

Ang hindi kayang makita ng app sa ganoong paraan ay kung kanino ang VPN. Sinasabi ng transport flag na may tunnel, hindi na nagtatapos ito kung saan inaasahan ng iyong organisasyon.

Ang landas ng serbisyo: mga pribadong pangalan at address

Ang pinakakaraniwang tapat na bersyon ng mensahe ay hindi pagsusuri ng patakaran. Niresolba ng app ang isang panloob na hostname tulad ng wiki o API endpoint na umiiral lamang sa loob ng corporate DNS view, at nabibigo ang paghahanap bago tumakbo ang anumang patakaran code. Maaaring nakabukas ang tunnel at nagpapadaan ng pangkalahatang internet traffic habang ipinapadala ng split DNS ang pangalang iyon sa isang resolver na hindi pa narinig ito.

Makitid ang mga sintomas dito. Isang host ang nabigo, gumagana ang iba pang network call ng app, at lumilitaw ang kabiguan sa paghahanap ng pangalan at hindi sa paglunsad. Ang mga panloob na sertipiko ay nagdaragdag ng pangalawang paraan ng kabiguan, dahil tinatanggihan ng app na naka-pin sa CA ng organisasyon ang pampublikong sertipiko kahit dumadaloy ang mga packet.

Ang pagkonekta ng anumang commercial VPN ay walang naaayos sa alinman doon. Binabago nito ang iyong exit address at hinahayaang hindi malutas ang panloob na pangalan.

Ang layer ng patakaran ng app

Maaari ring magdala ang app ng sarili nitong gate. Ang mga managed configuration ay nagpapahintulot sa organisasyon na magpush ng key at value pairs na idinedeklara ng app, at binabasa ito ng app sa pamamagitan ng RestrictionManager. Ang key tulad ng kinakailangang profile name o listahan ng pinapayagang network ay buong disenyo ng developer, ipinatutupad sa application code gamit ang anumang error text na pinili ng code na iyon.

Ito ang layer kung saan karaniwang nagpapakita ng sarili ang pananalita. Kung lumilitaw ang mensahe agad sa paglunsad, bago ang anumang network call, at binabanggit ang patakaran, profile o administrator, malamang tinitingnan mo ang logic ng application at hindi ang nahulog na packet.

Ang pagbasa ng parehong paghihigpit sa personal na device ay dead end. Walang paghihigpit na mababasa ang mga device na hindi pinamamahalaan, kaya bumabalik ang app sa anumang default na ginamit nang ito ay itayo.

Ang layer ng platform: laging bukas at lock

Nagdadagdag ang pamamahala ng device ng pagpapatupad na hindi kayang lampasan ng app. Maaaring tumawag ang device policy controller ng setAlwaysOnVpnPackage para sa work profile, opsyonal na may nakabukas na lock, at kapag nakabukas ang lock ay tinatanggihan ng platform ang traffic na hindi dumadaan sa package na iyon. Nakikita ang pagharang bilang kondisyon ng system at hindi bilang error ng app: humihinto rin ang ibang app sa profile sa pag-abot sa network.

Mahalaga ang saklaw. Ang always-on VPN ay naka-configure kada user, kaya hindi saklaw ng work profile package ang iyong personal na profile, at hindi natutugunan ng personal na VPN ang work profile package. Dalawang profile, dalawang independiyenteng patakaran ng network, isang device.

Ito rin ang tanging layer kung saan hindi makakatulong ang walang kaugnayang VPN, dahil pinapangalanan ng patakaran ang isang partikular na package.

Ang pagkilala sa tatlo

Daanin ang mga senyales sa pagkakasunod-sunod at huminto sa unang tugma. Isang hostname ang nabigo habang nalulutas ang lahat ng iba pa, tumuturo ito sa landas ng serbisyo. Ang agad na pagtanggi sa paglunsad na may pananalita ng patakaran ay tumuturo sa logic ng application. Ang buong profile na nawawalan ng connectivity tuwing nadidiskonekta ang approved client ay tumuturo sa lock. At ang app na tumatanggap ng anumang tunnel ay sinusuri ang transport flag, hindi ang identity ng iyong organisasyon.

Kapaki-pakinabang na ebidensya: ang eksaktong teksto at oras nito, kung may connectivity pa ang ibang app sa parehong profile, kung nalulutas ang pribadong pangalan sa loob ng approved tunnel, at kung may work badge na ipinapakita ang device para sa app na binuksan mo.

Ano ang ilalagay sa kahilingan ng suporta

Ang kahilingang nagpapangalan sa layer ay nairuruta nang tama sa unang pagtatangka. Isang bagay na tulad nito: bumukas ang work profile app, nabigo ang resource list pagkatapos kumonekta ang approved VPN, nabigo ang resolution ng pribadong pangalan sa pinapayagang diagnostic, at patuloy na gumagana ang ibang app sa profile. Binabasa iyon bilang problema sa ruta o resolver at nilalaktawan ang loop ng pag-reset ng account.

Kung wala talaga ang approved VPN, ang sinusuportahang landas ay enrollment o muling pag-provision sa pamamagitan ng iyong administrator. Ang pag-alis ng management profile, pag-install ng walang kaugnayang client o pagpeke sa estado ng network ay nagbabago ng kaayusan ng seguridad sa halip na ibalik ito.

Magsimula sa layer, hindi sa client. Karaniwang natatapos ng tatlong senyales sa itaas ang bagay na ito sa isang session.