Apple IncludeAllNetworks: ano pa ang lumalampas sa VPN

Binubuksan mo ang profile sa MDM console, nakikita mong naka-tick ang IncludeAllNetworks, at ipinapalagay na ang bawat packet mula sa device na iyon ay pumapasok na sa tunnel. Hindi iyon ipinapangako ng sariling schema ng Apple. Ang setting ay nagruruta ng trapiko sa VPN na may mga pagbubukod, ang ilan ay opsyonal na switch at ang iba ay kailangan para patuloy na gumana ang system. Ang paglalakbay sa ibaba ay sumusunod sa dokumentong iyon mula sa profile pakanlabas, kaya ang unang binabasa mo ay ang setting mismo, hindi isang capture mula sa device na wala pang nakakakilala.

Dalawa sa mga pagbubukod na iyon ang nagpapaliwanag ng halos lahat ng kalituhan, at pareho silang tungkol sa cellular service.

Magsimula sa managed profile, hindi sa capture

Buksan ang schema ng managed VPN profile at basahin ang paglalarawan ng property bago magbasa ng anumang packet log. Pansinin na ang paglalarawan ay tungkol sa routing na may mga pagbubukod, hindi sa garantiya ng buong tunnel. Ang nag-iisang pangungusap na iyon ang nagtatakda kung paano mo bibigyang-kahulugan ang lahat ng makikita mo pagkatapos.

Isulat ang tatlong bagay habang nasa console ka: ang payload identifier na nagdadala ng setting, ang managed OS release sa device, at kung aling VPN implementation ang aktuwal na naka-install. Ang paglalarawan ng isang key sa dokumentasyon ay walang sinasabi tungkol sa kung ipinapakita ito ng third-party client sa sarili nitong configuration UI.

Basahin ang cellular exclusion bilang dalawang magkaibang kaso

Sa mga sinusuportahang configuration, ibinubukod ng ExcludeCellularServices ang cellular-service traffic na naruruta sa internet, ngunit kapag pinagana lamang kasama ng IncludeAllNetworks. Binabanggit ng schema ang Wi-Fi Calling, IMS at mga serbisyong kaugnay ng messaging bilang mga halimbawa ng kategoryang iyon. Ang mga flow na iyon ay maaaring lumabas ng tunnel ayon sa disenyo, at walang pagsusuri ng profile ang magpapadaan sa kanila dito habang bukas ang pagbubukod.

Ang ikalawang kaso ay hiwalay at hindi nakadepende sa anumang switch. Ang ilang operator ay direktang naghahatid ng cellular services sa sarili nilang network sa halip na sa internet, at idinodokumento ng Apple ang kategoryang iyon bilang laging ibinubukod sa tunnel. Hindi ito ang kondisyonal na internet-routable na kaso sa itaas, kaya ang profile na naglilinis ng bawat kahon ng pagbubukod ay hindi pa rin ito mahuhuli. Ang pagtrato sa dalawa bilang isang feature ay doon nagsisimula ang karamihan ng debate tungkol sa leak.

Kung ang pangangailangan mo ay literal na walang packet na kailanman lalabas ng tunnel, ginagawang imposible na ng ikalawang kasong ito ang pangangailangang iyon sa isang cellular device. Kailangan mong malaman iyon bago ang design review, hindi pagkatapos.

Tingnan kung aling mga key ang aktuwal na inilalantad ng iyong platform

Inilalarawan din ng schema ang kinakailangang network-connection at captive-network traffic, kasama ang hiwalay na mga kontrol para sa iba pang kategorya tulad ng local network at komunikasyon ng device. Ito ay mga dokumentadong ugnayan sa configuration, hindi mga obserbasyon sa iyong device. Kumpirmahin ang bawat isa laban sa OS release na pinamamahalaan mo, dahil nagbabago ang availability sa pagitan ng mga release at ang isang profile key na tahimik na binabalewala ay mukhang eksaktong katulad ng key na gumagawa ng trabaho nito.

Ang minimal na payload para sa desisyong ito ay karaniwang ganito, na may cellular flag na tahasan sa halip na minana mula sa template:

<key>IncludeAllNetworks</key><true/>
<key>ExcludeCellularServices</key><true/>
<key>ExcludeLocalNetworks</key><true/>

Kung may key na nawawala sa inihatid na profile, babalik ang device sa default na halaga ng key na iyon, na hindi naman kinakailangang ang halagang nasa isip ng may-akda ng template. Ihambing ang inihatid na payload sa template sa halip na basahin lamang ang template.

Alamin kung ano ang isang hindi pamilyar na hostname

Kapag may lumabas na kahina-hinalang pangalan, itatag kung ano talaga ang kinakatawan ng obserbasyon: isang pangalang hiniling ng system, ang resolver na sumagot, isang destinasyon ng koneksyon, o isang label na inimprenta ng tool. Ang pangalang kaugnay ng operator ay hindi nagtatakda nang mag-isa ng pinagmulang proseso o ng inilapat na pagbubukod. Ang paghabol dito bilang patunay ng paglampas ay kung paano gumugugol ng isang linggo ang isang support thread sa maling layer.

Gumamit ng sinusuportahang diagnostics at kausapin ang administrator na may-ari ng profile, pagkatapos ay ihambing ang flow sa nilalayong patakaran. Ang paghahambing na iyon, hindi ang hostname, ang magsasabi kung inaasahan ang trapiko.

Lutasin ang pangangailangan sa halip na pahinain ang system

Huwag mag-install ng hindi maipaliwanag na root certificate o huwag patayin ang mga serbisyo ng system para lang maging mas tahimik ang isang capture. Ang pagpapatahimik sa capture ay nag-aalis ng ebidensiya at iniiwan ang pagbubukod sa lugar nito, na mas masamang kalagayan kaysa sa orihinal na tanong. Kung ipinagbabawal ng isang compliance rule ang kategoryang sinadyang ibinubukod ng platform, dalhin ang tunggalian na iyon sa mga may-ari ng device at network na may hawak na seksyon ng schema.

Tapusin ang paglalakbay sa pamamagitan ng pagtatala kung aling pagbubukod ang nagpaliwanag ng trapiko, kung aling OS release ito naaangkop, at kung aling halaga ng profile ang lumikha nito. Hindi kayang pagkasunduin ng isang connection icon ang dalawang hindi magkatugmang palagay tungkol sa kung gaano kalayo umaabot ang saklaw ng trapiko ng operating system.