Cum se citește starea VPN și proxy a unei aplicații de lucru administrate

O aplicație de lucru eșuează pe un telefon administrat, cineva verifică comutatorul VPN, îl vede pornit și declară calea sănătoasă. Aici se opresc majoritatea acestor diagnostice, și este prea devreme: un transport VPN activ nu spune că cererile acestei aplicații l-au folosit, iar proxy-ul care se aplică de fapt poate fi pe aplicație sau ales de un fișier PAC în loc să apară în Setări. Începe cu aplicația și profilul concrete pe care le depanezi, apoi citește viziunea proprie a platformei asupra căii.

Începe cu aplicația și profilul ei

O aplicație cu ecuson de lucru rulează de obicei într-un profil separat, cu propria politică de rețea. Un browser personal pe același telefon nu este o dovadă pentru ea, iar un rezultat de pe dispozitivul unui coleg cu altă administrare nici atât. Notează cărui profil îi aparține aplicația înainte de a citi orice.

În Setări, listează intrările VPN configurate și notează cui aparține fiecare. În build-urile Samsung etichetele meniului se mută între versiuni, așa că descrie intrarea, nu calea către ea. O intrare gri sau administrată aparține celui care administrează dispozitivul; dezactivarea ei ca experiment schimbă ceea ce încerci să măsori și poate încălca politica.

Citește starea raportată de platformă

În interiorul unei activități existente în instrumentele tale de suport, pe API 23 sau mai nou, starea rețelei poate fi citită fără a trimite un singur byte. Apelul are nevoie de permisiunea normală de manifest ACCESS_NETWORK_STATE pentru citirea capabilităților.

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

Fiecare valoare răspunde la o întrebare îngustă. Rețeaua activă este rețeaua implicită pentru procesul apelant în acel moment. Verificarea capabilităților îți spune dacă acea rețea implicită este susținută de VPN. Apelul proxy raportează proxy-ul HTTP implicit efectiv, iar obiectul returnat poate descrie fie un proxy static, fie un script PAC.

Dacă ai nevoie de vizualizarea pe fiecare rețea în loc de cea implicită, citește proprietățile de legătură ale aceleiași rețele și compară cu cm.getLinkProperties(network)?.httpProxy. Un proxy instalat de administrarea dispozitivului apare în apelul proxy-ului implicit și nu în proprietățile de legătură, ceea ce este o modalitate rapidă de a distinge un proxy furnizat de politică de unul oferit de rețea.

Păstrează rezultatul în canalul tău de suport, nu într-un raport public. Numele de gazdă ale proxy-ului, adresele PAC și sufixele interne dezvăluie cum îți direcționează organizația traficul, și niciunul dintre ele nu este necesar pentru a descrie defecțiunea.

Interpretează fiecare câmp îngust

O rețea nulă sau un obiect de capabilități nul înseamnă că starea rețelei apelantului nu era disponibilă sau s-a schimbat în timpul citirii. Nu înseamnă că nu există VPN. Trateaz-o ca necunoscută și citește din nou după ce aplicația a trecut în prim-plan, nu ca pe un rezultat negativ.

Un transport VPN este cel mai slab dintre pozitive. Orice aplicație care deține un VpnService produce unul, inclusiv o aplicație locală de filtrare care nu trimite niciodată traficul tău nicăieri. Deci o valoare true spune că există o rețea implicită susținută de VPN, nu că a fost folosită ieșirea organizației tale și cu siguranță nu că a avut loc o inspecție.

Un proxy implicit nul înseamnă că acest API nu raportează niciun proxy HTTP implicit pentru configurația efectivă. Exclude foarte puțin: o aplicație poate avea propria setare SOCKS, își poate implementa propriul client HTTP sau poate fi ghidată de un proxy la poartă despre care dispozitivul nu află niciodată.

PAC este cazul care învinge un răspuns cu o singură valoare. Un script poate direcționa o destinație prin proxy și trimite alta direct, așa că două cereri ale aceleiași aplicații într-o secundă pot lua căi diferite. Și o aplicație care își leagă socketurile de o rețea aleasă, sau apelează bindProcessToNetwork, nu este deloc obligată să urmeze valoarea implicită.

Ce nu îți poate spune acest instantaneu

Nu este un istoric. Nimic aici nu înregistrează ce cale a luat cererea care eșuează, iar o citire reușită după eșec nu este o dovadă despre eșec. Nu este nici un inventar: primești rețeaua implicită a procesului apelant, nu o listă a conexiunilor private ale fiecărei aplicații.

Nu spune nimic nici despre ce se întâmplă deasupra socketului. O strângere de mână TLS care eșuează pe un dispozitiv administrat poate fi o problemă a depozitului de încredere, o nepotrivire de fixare sau un nume pe care proxy-ul îl refuză, și niciuna dintre ele nu apare într-o citire de conectivitate.

De aceea cele două jumătăți contează împreună: instantaneul restrânge unde să te uiți, iar diagnosticul propriu al aplicației spune ce a eșuat de fapt.

Raportează într-o formă pe care un administrator o poate folosi

Dă aplicația afectată, profilul, marca temporală și etapa exactă care a eșuat: rezolvarea numelor, conexiunea TCP, strângerea de mână TLS sau un status HTTP. Adaugă valorile instantaneului așa cum au fost citite, cu nulele scrise ca nule, nu ca niciunul. Notează dacă alte aplicații din același profil eșuează la fel, ceea ce separă o problemă a aplicației de o problemă de cale la nivelul întregului profil.

Apoi oprește-te și lasă proprietarul căii să răspundă. Nu trata un certificat corporativ, o adresă de proxy sau o intrare VPN ca permisiune de a elimina administrarea sau de a ocoli ruta aprobată; asta transformă un caz de suport într-un incident de politică.

Contractul proxy-ului implicit este scurt și merită o lectură, pentru că definește exact ce proxy raportează apelul, iar orice citire excesivă a acestui instantaneu începe prin a presupune că raportează mai mult.