Delovna aplikacija odpove na upravljanem telefonu, nekdo preveri stikalo VPN, vidi, da je vklopljeno, in razglasi pot za zdravo. Tu se ustavi večina teh diagnoz in to je prezgodaj: aktivni transport VPN ne pove, da so zahteve te aplikacije šle skozenj, in posredniški strežnik, ki dejansko velja, je lahko na aplikacijo ali ga izbere datoteka PAC, namesto da bi bil prikazan v Nastavitvah. Začni s konkretno aplikacijo in profilom, ki ju razhroščuješ, nato preberi lasten pogled platforme na pot.

Začni z aplikacijo in njenim profilom

Aplikacija z delovno značko običajno teče v ločenem profilu z lastno omrežno politiko. Osebni brskalnik na istem telefonu ni dokaz zanjo, prav tako ne rezultat z naprave sodelavca z drugačnim upravljanjem. Preden karkoli prebereš, zabeleži, kateremu profilu aplikacija pripada.

V Nastavitvah naštej nastavljene vnose VPN in zabeleži, komu pripada vsak. V različicah Samsung se oznake menija med izdajami premikajo, zato opiši vnos, ne poti do njega. Siv ali upravljan vnos pripada tistemu, ki upravlja napravo; izklop kot poskus spremeni to, kar poskušaš izmeriti, in je lahko v nasprotju s politiko.

Preberi stanje, ki ga poroča platforma

Znotraj obstoječe aktivnosti v tvojih podpornih orodjih, na API 23 ali novejšem, je stanje omrežja mogoče prebrati, ne da bi poslal en sam bajt. Klic potrebuje običajno dovoljenje manifesta ACCESS_NETWORK_STATE za branje zmogljivosti.

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

Vsaka vrednost odgovarja na ozko vprašanje. Aktivno omrežje je privzeto omrežje klicočega procesa v tistem trenutku. Preverjanje zmogljivosti pove, ali je to privzeto omrežje podprto z VPN. Klic posredniškega strežnika poroča dejanski privzeti posredniški strežnik HTTP, vrnjeni objekt pa lahko opisuje statični posredniški strežnik ali skript PAC.

Če potrebuješ pogled po posameznih omrežjih namesto privzetega, preberi lastnosti povezave istega omrežja in jih primerjaj z cm.getLinkProperties(network)?.httpProxy. Posredniški strežnik, ki ga namesti upravljanje naprave, se pojavi v klicu privzetega posredniškega strežnika in ne v lastnostih povezave, kar je hiter način za razlikovanje posredniškega strežnika, ki ga določi politika, od tistega, ki ga je dodelilo omrežje.

Izhod hrani v svojem podpornem kanalu, ne v javnem poročilu. Imena gostiteljev posredniškega strežnika, naslovi PAC in notranje pripone razkrivajo, kako tvoja organizacija usmerja promet, in nobeno od tega ni potrebno za opis napake.

Razlagaj vsako polje ozko

Ničelno omrežje ali ničelni objekt zmogljivosti pomeni, da stanje omrežja klicočega ni bilo na voljo ali se je med branjem spremenilo. To ne pomeni, da VPN ni. Obravnavaj to kot neznano in preberi znova, potem ko je aplikacija prišla v ospredje, ne kot negativen rezultat.

Transport VPN je najšibkejši med pozitivnimi. Vsaka aplikacija, ki ima VpnService, ustvari enega, tudi lokalna aplikacija za filtriranje, ki tvojega prometa nikoli nikamor ne pošlje. Zato vrednost true pove, da obstaja privzeto omrežje s podporo VPN, ne da je bil uporabljen izhod tvoje organizacije in zagotovo ne da je bil opravljen pregled.

Ničelni privzeti posredniški strežnik pomeni, da ta API ne poroča nobenega privzetega posredniškega strežnika HTTP za dejansko konfiguracijo. Izključuje zelo malo: aplikacija ima lahko svojo nastavitev SOCKS, izvede svojega odjemalca HTTP ali jo vodi posredniški strežnik na prehodu, za katerega naprava nikoli ne izve.

PAC je primer, ki premaga odgovor z eno vrednostjo. Skript lahko en cilj usmeri skozi posredniški strežnik, drugega pa pošlje neposredno, zato lahko dve zahtevi iste aplikacije v eni sekundi ubereta različni poti. In aplikacija, ki svoje vtičnice veže na izbrano omrežje ali kliče bindProcessToNetwork, ni dolžna slediti privzeti vrednosti sploh.

Česa ti ta posnetek ne more povedati

To ni zgodovina. Nič tu ne zabeleži, katero pot je ubrala zahteva, ki je spodletela, in uspešno branje po napaki ni dokaz o napaki. To tudi ni popis: dobiš privzeto omrežje klicočega procesa, ne seznama zasebnih povezav vsake aplikacije.

Nič ne pove niti o tem, kaj se dogaja nad vtičnico. Ročna menjava TLS, ki spodleti na upravljani napravi, je lahko težava shrambe zaupanja, neskladje pripenjanja ali ime, ki ga posredniški strežnik zavrača, in nobeno od tega se ne pokaže pri branju povezljivosti.

Zato štejeta obe polovici skupaj: posnetek zoži, kam gledati, in lastna diagnostika aplikacije pove, kaj je v resnici spodletelo.

Prijavi v obliki, ki jo upravitelj lahko uporabi

Navedi prizadeto aplikacijo, profil, časovni žig in točno fazo, ki je spodletela: razreševanje imen, povezava TCP, ročna menjava TLS ali status HTTP. Dodaj vrednosti posnetka tako, kot so bile prebrane, z ničlami zapisanimi kot ničle, ne kot beseda nič. Zabeleži, ali tudi druge aplikacije v istem profilu spodletijo enako, kar loči težavo aplikacije od težave poti v celem profilu.

Nato se ustavi in pusti lastniku poti, da odgovori. Ne obravnavaj poslovnega potrdila, naslova posredniškega strežnika ali vnosa VPN kot dovoljenja za odstranitev upravljanja ali obhod odobrene poti; to spremeni podporni primer v politični incident.

Pogodba o privzetem posredniškem strežniku je kratka in vredna enega branja, ker natančno določa, kateri posredniški strežnik klic poroča, in vsako pretirano branje tega posnetka se začne s predpostavko, da poroča več.

Sorodni članki