VPN kada app sa mga pinamamahalaang iPhone app: ano ang niruruta at ano ang hindi
Ang per-app tunnel ay sumusunod sa pinamamahalaang app, hindi sa telepono. Suriin ang ugnayan ng payload, ang pinamamahalaang kopya, ang mga tuntunin kapag hiniling at ang mga daloy na lumalabas sa app.
Ang per-app VPN sa iPhone ay hindi switch ng buong telepono. Ito ay ugnayan ng isang pinamamahalaang app at isang payload ng VPN, na nagagawa kapag ipinapakalat ang app, at ang trapiko ng lahat ng iba ay nananatili sa dating ruta. Kaya ang parehong telepono ay kumikilos nang hindi pantay: binubuksan ng app sa trabaho ang pribadong pahina samantalang hindi naaabot ng Safari ang parehong host, o hindi tumataas ang tunnel at nag-uulat ang app ng timeout na mukhang maling kredensyal. Ang mga pagsusuri ay mula sa pinakamalawak na dahilan pababa, kaya huminto sa unang bigong pagsusuri.
Suriin muna ang payload at talaan ng app
Ang ugnayan ay nabubuhay sa dalawang bagay, hindi isa. Itinatakda ng payload ng VPN ang tunnel: uri, server, pagpapatotoo, DNS at ang bundle identifier ng provider kapag gumamit ng pasadyang kliyente. Itinuturo ng talaan ng app ang payload na iyon, at iniaalok ito ng karamihan ng console ng pamamahala bilang opsyon kada app sa configuration ng app, na may pangalang malapit sa Per-App VPN. Ang payload na walang app na nagtuturo ay walang niruruta kada app; kumikilos ito tulad ng ordinaryong tunnel na kailangang simulan ng isang tao nang manwal.
Basahin ang dalawang bagay bago hawakan ang telepono. Tiyakin na itinuturo ng configuration ng app ang payload na sinusuri mo at hindi ang lumang kopya nito, dahil karaniwan ang doble na payload na halos pareho ang pangalan pagkatapos ng migrasyon at masayang itinuturo ng app ang naibaba na. Pagkatapos ay tiyakin na umabot sa device ang configuration: Mga Setting, Pangkalahatan, VPN at Pamamahala ng Device ay dapat ipakita ito bilang naka-install na profile. Ang listahan ng VPN doon ay hindi ang pagsubok. Ang serbisyong kada app ay karaniwang walang manwal na switch, kaya ang tamang naka-deploy na configuration ay maaaring hindi kailanman lumitaw sa mga VPN na masisimulan. Makikita ang kawalan sa talaan ng app at sa kung tumataas ang tunnel sa unang kahilingan ng app.
Isang kondisyon ang nagpapaliwanag ng maraming ticket: kailangan ng modelong ito na dumating ang app sa pamamagitan ng pamamahala. Ang kopyang naka-install sa gilid o binili nang personal ay hindi nakakakuha ng ugnayan, kahit tumugma ang bundle identifier nito. Inilalarawan ng gabay ng Apple sa deployment ng VPN ang modelong payload sa likod nito (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Tiyakin na ang naka-install na app ay ang pinamamahalaang kopya
Sumusunod ang ugnayan sa naka-install at pinamamahalaang app. Kung muling ininstol ito ng isang tao mula sa App Store gamit ang personal na Apple ID, pinalitan ng enterprise build na muling pinirmahan, o muling nairehistro ang device at bumalik ang app sa ibang channel, maaaring manatiling bumaba ang tunnel habang ang app mismo ay mukhang ganap na normal.
Subukan sa pamamagitan ng paghahambing, hindi ng isang obserbasyon. Sa imbentaryo ng pamamahala, dapat lumitaw ang app bilang pinamamahalaan para sa device na iyon na may mapping ng VPN sa talaan nito. Sa telepono, dapat tumaas ang tunnel kapag inilunsad ang app at lumabas ang unang kahilingan nito, hindi lamang kapag may nagsimula ng hiwalay na manwal na configuration sa Mga Setting. Kung walang binabago ang paglunsad ng app at binabago ng manwal na configuration na iyon, ang app ay hindi nakatali sa per-app tunnel.
Mahalaga ang mga update: ang itinulak sa pamamagitan ng pamamahala ay nagpapanatili ng mapping, samantalang ang muling pag-install na sinimulan ng user ay maaaring mawala ito. Kapag ang reklamo ay may petsa mula sa isang update, suriin ang talaan ng app bago ang network.
Suriin kung ano ang maaaring kunin ng tunnel
Ang per-app tunnel ay pinipili ng source app, kaya ang default na ruta ng telepono ay pag-aari pa rin ng Wi-Fi o cellular. Ang OverridePrimary ang susi na nagbabago nito. Kapag itinakda ito ng profile, kumikilos ang tunnel tulad ng buong tunnel at minamana ito ng bawat app, kaya lahat ng dumadaan sa VPN ay nagiging isyu ng profile at hindi ng app.
Ang mga tuntunin kapag hiniling ang nagpapasya sa pagtitiyaga. Ang OnDemandEnabled at ang set ng tuntunin nito ay nagbabalik ng tunnel kapag nagpapadala ng trapiko ang app, nakakalampas sa paglipat mula Wi-Fi patungong cellular, o nagbababa kapag pumunta sa background ang app. Ang deployment na kumokonekta at pagkatapos ay tahimik na namamatay ay karaniwang may tuntuning tumutugma lamang sa probe na hindi kailanman nagsisimula habang idle ang app.
Pagkatapos ay basahin nang tapat ang panig ng ruta. Kung ang profile ng provider o vendor ay nagbibigay ng listahan ng pagsasama, ang tunnel na nagdadala lamang ng 10.20.0.0/16 ay hindi magdadala ng serbisyo sa 10.30.0.0/16; ang listahan ang gumagawa ng trabaho nito, hindi ang per-app na pagkabigo. Ang built-in na payload ng iOS ay walang listahan ng pagsasama. Kung wala iyon, sinusunod ng paghahati ang default ng provider at ang IncludeAllNetworks, hindi ang nakatagong listahan.
Subukan ang app, pagkatapos subukan ang lumalabas dito
Subukan gamit ang pangalan, hindi lamang address. Ang paglutas ng internal host sa loob ng pinamamahalaang app ay nagpapatunay na dumaan din sa tunnel ang DNS, dahil itinatakda ng payload kung aling resolver ang sasagot at aling search domain ang malalapat. Maaaring perpekto ang routing habang nabigo ang paghahanap ng pangalan, at ang dalawang sintomas ay tumuturo sa magkaibang setting.
Pagkatapos ay subukan ang hangganan mula sa magkabilang panig. Ang personal na app o Safari ay dapat makarating sa ordinaryong pampublikong pahina at iulat ang address ng operator o ng bahay, samantalang naaabot ng pinamamahalaang app ang pribadong serbisyo. Kung pareho silang nag-uulat ng parehong pampublikong address, hindi na per-app ang tunnel, ano man ang sinasabi ng talaan ng app.
Ang mga daloy na lumalabas sa app ay gumagawa ng nakakalitong ticket. Ang link na bumubukas sa Safari, dokumentong ipinasa sa share sheet, o pag-log in ng SSO na lumipat sa browser ay lumalabas sa proseso ng app at kasama nito ang tunnel. Ang pag-log in na ipinapakita sa loob ng app ay karaniwang itinatributo sa app, kaya ang embedded na pag-log in ay maaaring magtagumpay kung saan nabigo ang parehong URL sa Safari; tiyakin iyon sa halip na ipagpalagay. Kapag ang identity provider ay naaabot lamang sa tunnel, panatilihin ang pag-log in sa loob ng app o idagdag ang domain ng provider sa mga Safari domain ng payload upang mahuli ang tugmang trapiko ng Safari.
Itugma ang sintomas sa sapin
Sinasabi ng hugis ng pagkabigo kung aling pagsusuri ang uulitin.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Sa likod ng gitnang mga linya ay may dalawang detalye: ang per-app tunnel ay maaaring malusog at gayunman makaligtaan ang subnet na wala sa anumang listahan ng provider, at ang pinamamahalaang telepono ay maaaring humawak ng higit sa isang configuration ng VPN, kaya tiyakin kung alin ang nakatali ang app sa halip na ipagpalagay na iyon ang binabasa mo.
Ayusin sa ganitong pagkakasunod-sunod: ituro ang talaan ng app sa aktibong payload, muling i-install ang app sa pamamagitan ng pamamahala, tiyakin na tumataas ang tunnel sa unang kahilingan ng app, pagkatapos ay ulitin ang mga pagsubok sa pangalan at hangganan. Kung ang unang kahilingan ay hindi makapagsimula ng tunnel, huminto at suriin ang panig ng provider, dahil ang pasadyang kliyente ay nangangailangan ng Network Extension na umiiral at identifier na tumutugma sa naka-install na app.
Ibalik ang tatlong katotohanan sa halip na screenshot: aling payload ang itinuturo ng talaan ng app, ipinapakita ba ito ng Mga Setting bilang naka-install na profile, at ano ang bigong kahilingan — isang pangalan, address o paglipat sa browser. Ang tatlong sagot na ito ay naghihiwalay ng pagkakamali sa deployment mula sa pagkakamali sa routing, at ang susunod na tao ay makakilos nang hindi inuulit ang diagnosis.