Aplicația de muncă cere un VPN? Verificați mai întâi aceste trei straturi

Mesajul spune că aplicația are nevoie de un VPN, dar de obicei aplicația raportează un simptom în loc să numească lucrul care a blocat-o. Trei responsabili diferiți pot produce acea propoziție: serviciul privat cu care vorbește aplicația, codul de politici al aplicației și stratul de administrare a dispozitivului care controlează profilul de lucru. Care dintre ei întreabă schimbă ce ar trebui să faceți, și doar unul din trei se rezolvă conectând un tunel. Găsirea responsabilului mai întâi vă scutește de reinstalarea unui client care nu a fost niciodată problema.

Ce poate verifica aplicația însăși

Înainte de a presupune o regulă ascunsă a platformei, amintiți-vă că o aplicație obișnuită poate vedea dacă un transport VPN este activ. ConnectivityManager raportează rețele care poartă TRANSPORT_VPN, iar absența NET_CAPABILITY_NOT_VPN spune oricărui apelant că traseul actual trece printr-un tunel. Un dezvoltator care vrea să refuze să ruleze în afara unui tunel poate face asta cu API publice și fără niciun instrument de întreprindere.

Ce nu poate vedea astfel aplicația este al cui este VPN-ul. Un indicator de transport spune că există un tunel, nu că se termină acolo unde se așteaptă organizația dumneavoastră.

Traseul serviciului: nume și adrese private

Cea mai obișnuită versiune onestă a mesajului nu este deloc o verificare de politici. Aplicația rezolvă un nume de gazdă intern, cum ar fi un wiki sau un punct final API care există doar în vizualizarea DNS a companiei, iar căutarea eșuează înainte de a rula vreun cod de politici. Tunelul poate fi activ și poate lăsa să treacă trafic general de internet în timp ce DNS-ul divizat trimite acel nume către un resolver care nu a auzit niciodată de el.

Simptomele sunt înguste aici. O gazdă eșuează, restul apelurilor de rețea ale aplicației funcționează, iar eșecul apare în timpul unei căutări de nume, nu la pornire. Certificatele interne adaugă un al doilea mod de eșec, pentru că o aplicație fixată la CA-ul organizației respinge un certificat public chiar și atunci când pachetele curg.

Conectarea unui VPN comercial oarecare nu repară nimic din asta. Schimbă adresa de ieșire și lasă numele intern la fel de nerezolvabil.

Stratul de politici al aplicației

O aplicație poate avea și propria poartă. Configurațiile administrate permit organizației să trimită perechi de cheie și valoare pe care aplicația le declară, iar aplicația le citește prin RestrictionManager. O cheie precum un nume de profil obligatoriu sau o listă de rețele permise este în întregime designul dezvoltatorului, aplicat în codul aplicației cu textul de eroare pe care îl alege acel cod.

Acesta este stratul în care formularea trădează de obicei. Dacă mesajul apare imediat la pornire, înainte de orice apel de rețea, și menționează o politică, un profil sau un administrator, probabil priviți logica aplicației, nu un pachet pierdut.

Citirea aceleiași restricții pe un dispozitiv personal este o fundătură. Dispozitivele neadministrate nu au restricții de citit, așa că aplicația revine la valoarea implicită cu care a fost construită.

Stratul platformei: mereu activ și blocare

Administrarea dispozitivului adaugă o impunere pe care aplicația nu o poate ocoli. Un controlor de politici de dispozitiv poate apela setAlwaysOnVpnPackage pentru profilul de lucru, opțional cu blocarea activată, iar odată activată blocarea, platforma refuză traficul care nu trece prin acel pachet. Blocarea este vizibilă ca stare de sistem, nu ca eroare a aplicației: și celelalte aplicații din profil încetează să mai ajungă la rețea.

Amploarea contează. VPN-ul mereu activ se configurează pe utilizator, așa că un pachet de profil de lucru nu acoperă profilul dumneavoastră personal, iar un VPN personal nu satisface pachetul profilului de lucru. Două profiluri, două politici de rețea independente, un singur dispozitiv.

Este și singurul strat în care un VPN fără legătură nu poate ajuta, pentru că politica numește un pachet anume.

Distincția între cele trei

Parcurgeți semnăturile în ordine și opriți-vă la prima care se potrivește. Un singur nume de gazdă care eșuează în timp ce tot restul se rezolvă indică traseul serviciului. Un refuz imediat la pornire cu formulare de politici indică logica aplicației. Un profil întreg care pierde conectivitatea de fiecare dată când clientul aprobat se deconectează indică blocarea. Iar o aplicație care acceptă orice tunel verifică indicatorul de transport, nu identitatea organizației dumneavoastră.

Dovezi utile: textul exact și momentul lui, dacă alte aplicații din același profil mai au conectivitate, dacă numele privat se rezolvă în interiorul tunelului aprobat și dacă dispozitivul afișează o insignă de muncă pentru aplicația pe care ați deschis-o.

Ce să includeți în cererea de asistență

O cerere care numește stratul este direcționată corect din prima încercare. Ceva de genul: aplicația profilului de lucru se deschide, lista de resurse eșuează după conectarea VPN-ului aprobat, rezolvarea numelui privat eșuează în diagnosticul permis, iar celelalte aplicații din profil continuă să funcționeze. Asta se citește ca o problemă de rută sau de resolver și evită bucla de resetare a contului.

Dacă VPN-ul aprobat lipsește complet, calea acceptată este înrolarea sau reprovisionarea prin administratorul dumneavoastră. Eliminarea profilului de administrare, instalarea unui client fără legătură sau falsificarea stării rețelei schimbă aranjamentul de securitate în loc să îl restaureze.

Începeți cu stratul, nu cu clientul. Cele trei semnături de mai sus rezolvă de obicei problema într-o singură sesiune.