Laboraapo malsukcesas en administrata telefoneto, iu kontrolas la VPN-ŝaltilon, vidas ĝin ŝaltita kaj deklaras la vojon sana. Ĝuste tie ĉesas la plej multaj el ĉi tiuj diagnozoj, kaj tio estas tro frue: aktiva VPN-transporto ne diras, ke la petoj de ĉi tiu apo uzis ĝin, kaj la prokurilo, kiu fakte validas, povas esti por-apa aŭ elektita de PAC-dosiero anstataŭ aperi en Agordoj. Komencu de la konkreta apo kaj profilo, kiujn vi sencimigas, kaj poste legu la vidpunkton de la platformo pri la vojo.

Komencu de la apo kaj ĝia profilo

Apo kun labora insigno kutime kuras en aparta profilo kun sia propra retadministra politiko. Persona retumilo sur la sama telefoneto ne estas pruvo pri ĝi, kaj same ne estas rezulto de aparato de kolego kun alia administrado. Notu, al kiu profilo apartenas la apo, antaŭ ol legi ion ajn.

En Agordoj, listigu la agorditajn VPN-ajn erojn kaj notu, kiu posedas ĉiun. En Samsung-aj versioj la menuaj etikedoj moviĝas inter la aperoj, do priskribu la eron anstataŭ la vojon al ĝi. Griza aŭ administrata ero apartenas al tiu, kiu administras la aparaton; malŝalti ĝin pro eksperimento ŝanĝas la aferon, kiun vi provas mezuri, kaj povas kontraŭi la politikon.

Legu la staton, kiun la platformo raportas

Ene de ekzistanta aktiveco en via subtena ilaro, je API 23 aŭ pli nova, la reta stato povas esti legita sen sendi iun ajn bitokon. La voko bezonas la normalan manifestpermeson ACCESS_NETWORK_STATE por la legado de kapabloj.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Ĉiu valoro respondas mallarĝan demandon. La aktiva reto estas la defaŭlta reto por la vokanta procezo en tiu momenteto. La kapabla kontrolo diras al vi, ĉu tiu defaŭlta reto estas VPN-subtenata. La prokurila voko raportas la fakte efikan defaŭltan HTTP-prokurilon, kaj la redonita objekto povas priskribi jen statikan prokurilon, jen PAC-skripton.

Se vi bezonas la vidon por unuopa reto anstataŭ la defaŭlta, legu la ligopropraĵojn de la sama reto kaj komparu kun cm.getLinkProperties(network)?.httpProxy. Prokurilo instalita de la administrado de la aparato aperas en la voko de la defaŭlta prokurilo kaj ne en la ligopropraĵoj, kio estas rapida rimedo distingi prokurilon provizitan de politiko disde tiu, kiun donis la reto.

Tenu la eligon en via subtena kanalo anstataŭ en publika raporto. Prokurilaj gastigantaj nomoj, PAC-adresoj kaj internaj sufiksoj malkaŝas, kiel via organizo enkursigas trafikon, kaj neniu el ili necesas por priskribi la malsukceson.

Interpretu ĉiun kampon mallarĝe

Nula reto aŭ nula kapabla objekto signifas, ke la reta stato de la vokanto ne estis havebla aŭ ŝanĝiĝis dum la legado. Tio ne signifas, ke mankas VPN. Traktu ĝin kiel nekonatan kaj legu denove post kiam la apo aperis en la frontplano, anstataŭ kiel negativan rezulton.

VPN-transporto estas la plej malforta el la pozitivoj. Ĉiu apo, kiu tenas VpnService, produktas unu, inkluzive lokan filtradon, kiu neniam sendas vian trafikon ie ajn. Do la vera valoro diras, ke ekzistas VPN-subtenata defaŭlta reto, ne ke la elirejo de via organizo estis uzita kaj certe ne ke inspektado okazis.

Nula defaŭlta prokurilo signifas, ke ĉi tiu API raportas neniun defaŭltan HTTP-prokurilon por la efika agordo. Ĝi ekskludas tre malmulte: apo povas porti propran SOCKS-agordon, efektivigi propran HTTP-klienton, aŭ esti gvidata de prokurilo ĉe la pordego, pri kiu la aparato neniam sciiĝas.

PAC estas la kazo, kiu venkas unu-valoran respondon. Skripto povas enkursigi unu destinon tra prokurilo kaj sendi alian rekte, do du petoj de la sama apo dum unu sekundo povas elekti diversajn vojojn. Kaj apo, kiu ligas siajn soketojn al elektita reto aŭ vokas bindProcessToNetwork, tute ne devas sekvi la defaŭltan.

Kion ĉi tiu momentfoto ne povas diri al vi

Ĝi ne estas historio. Nenio ĉi tie registras, kiun vojon prenis la malsukcesa peto, kaj sukcesa legado post la malsukceso ne estas pruvo pri la malsukceso. Ĝi same ne estas inventaro: vi ricevas la defaŭltan reton de la vokanta procezo, ne liston de la privataj konektoj de ĉiu apo.

Ĝi ankaŭ diras nenion pri tio, kio okazas super la soketo. TLS-manpremado, kiu malsukcesas en administrata aparato, povas esti problemo de fido-stokejo, malkongruo de fiksado aŭ nomo, kiun la prokurilo rifuzas, kaj neniu el tiuj aperas en konektec-legado.

Tial la du duonoj gravas kune: la momentfoto mallarĝigas, kien rigardi, kaj la propraj diagnozoj de la apo diras, kio fakte malsukcesis.

Raportu ĝin en formo, kiun administranto povas uzi

Donu la tuŝitan apon, la profilon, la tempstampon kaj la precizan etapon, kiu malsukcesis: nomosolvado, TCP-konekto, TLS-manpremado aŭ HTTP-statuso. Aldonu la momentfoto-valorojn tiel, kiel ili estis legitaj, kun nuloj skribitaj kiel nuloj anstataŭ kiel nenio. Notu, ĉu aliaj apoj en la sama profilo malsukcesas same, kio apartigas apan problemon disde profilo-larĝa voja problemo.

Poste haltu kaj lasu la posedanton de la vojo respondi. Ne traktu entreprenan atestilon, prokurilan adreson aŭ VPN-erron kiel permeson forigi administradon aŭ preterpasi la aprobitan itineron; tio faras subtenan kazon politika incidento.

La kontrakto pri defaŭlta prokurilo estas mallonga kaj inda je unu legado, ĉar ĝi difinas precize, kiun prokurilon la voko raportas, kaj ĉiu troa legado de ĉi tiu momentfoto komenciĝas per la supozo, ke ĝi raportas pli.

Rilataj artikoloj