Kræver arbejdsappen en VPN? Se først på disse tre lag

Beskeden siger, at appen har brug for en VPN, men appen rapporterer normalt et symptom i stedet for at navngive det, der blokerede den. Tre forskellige ejere kan frembringe den sætning: den private tjeneste, appen taler med, appens egen politik-kode og det enhedsstyringslag, der kontrollerer arbejdsprofilen. Hvilken af dem, der spørger, ændrer, hvad du bør gøre, og kun én af de tre løses ved at tilslutte en tunnel. At finde ejeren først sparer dig for at geninstallere en klient, der aldrig var problemet.

Hvad appen selv kan kontrollere

Før du antager en skjult platformregel, så husk, at en normal app kan se, om en VPN-transport er aktiv. ConnectivityManager rapporterer netværk, der bærer TRANSPORT_VPN, og fraværet af NET_CAPABILITY_NOT_VPN fortæller enhver kalder, at den aktuelle vej er tunneleret. En udvikler, der vil nægte at køre uden for en tunnel, kan gøre det med offentlige API'er og helt uden virksomhedsværktøjer.

Det, appen ikke kan se på den måde, er, hvis VPN det er. Et transportflag siger, at der findes en tunnel, ikke at den slutter, hvor din organisation forventer.

Tjenestestien: private navne og adresser

Den mest almindelige ærlige version af beskeden er slet ikke et politikttjek. Appen opløser et internt værtsnavn som en wiki eller et API-endepunkt, der kun findes i virksomhedens DNS-visning, og opslaget fejler, før nogen politik-kode kører. Tunnelen kan være oppe og føre almindelig internettrafik igennem, mens opdelt DNS sender det navn til en resolver, der aldrig har hørt om det.

Symptomerne her er snævre. Én vært fejler, resten af appens netværkskald virker, og fejlen vises under et navneopslag i stedet for ved start. Interne certifikater tilføjer en anden fejltilstand, fordi en app, der er fastgjort til organisationens CA, afviser et offentligt certifikat, selv når pakkerne flyder.

At tilslutte en tilfældig kommerciel VPN løser intet af det. Det ændrer din udgangsadresse og efterlader det interne navn lige så uopløseligt.

Apppolitiklaget

En app kan også bære sin egen port. Administrerede konfigurationer lader organisationen skubbe nøgle- og værdipar, som appen erklærer, og appen læser dem gennem RestrictionManager. En nøgle som et krævet profilnavn eller en liste over tilladte netværk er helt udviklerens design, håndhævet i applikationskoden med den fejltekst, som koden vælger.

Dette lag er, hvor formuleringen normalt afslører det. Hvis beskeden vises med det samme ved start, før noget netværkskald, og nævner en politik, en profil eller en administrator, ser du sandsynligvis på applikationslogik i stedet for en tabt pakke.

At læse den samme begrænsning på en personlig enhed er en blindgyde. Ikke-administrerede enheder har ingen begrænsninger at læse, så appen falder tilbage til den standard, den blev bygget med.

Platformlaget: altid-tilsluttet og låsning

Enhedsstyring tilføjer håndhævelse, som appen ikke kan tilsidesætte. En enhedspolitikcontroller kan kalde setAlwaysOnVpnPackage for arbejdsprofilen, eventuelt med låsning aktiveret, og når låsningen er slået til, afviser platformen trafik, der ikke går gennem den pakke. Blokeringen ses som en systemtilstand i stedet for en appfejl: andre apps i profilen holder også op med at nå netværket.

Omfanget betyder noget. Altid-tilsluttet VPN konfigureres pr. bruger, så en arbejdsprofilpakke dækker ikke din personlige profil, og en personlig VPN opfylder ikke arbejdsprofilpakken. To profiler, to uafhængige netværkspolitikker, én enhed.

Det er også det eneste lag, hvor en uvedkommende VPN ikke kan hjælpe, fordi politikken navngiver én bestemt pakke.

At skelne de tre

Gå gennem signaturene i rækkefølge, og stop ved den første, der passer. Ét værtsnavn, der fejler, mens alt andet opløses, peger på tjenestestien. Et øjeblikkeligt afslag ved start med politikformulering peger på applikationslogik. En hel profil, der mister forbindelsen, hver gang den godkendte klient afbryder, peger på låsning. Og en app, der accepterer enhver tunnel, kontrollerer transportflaget, ikke din organisations identitet.

Nyttig dokumentation: den præcise tekst og dens timing, om andre apps i samme profil stadig har forbindelse, om det private navn opløses inde i den godkendte tunnel, og om enheden viser et arbejdsbadge for den app, du åbnede.

Hvad du skal skrive i supportanmodningen

En anmodning, der navngiver laget, bliver dirigeret korrekt i første forsøg. Noget i retning af: arbejdsprofilappen åbner, resurselisten fejler, efter at den godkendte VPN tilsluttes, privat navneopløsning fejler i den tilladte diagnostik, og andre apps i profilen bliver ved med at virke. Det læses som et rute- eller resolverproblem og springer konto-nulstillingsløkken over.

Hvis den godkendte VPN helt mangler, er den understøttede vej tilmelding eller genklargøring gennem din administrator. At fjerne styringsprofilen, installere en uvedkommende klient eller forfalske netværkstilstanden ændrer sikkerhedsordningen i stedet for at genskabe den.

Start med laget, ikke klienten. De tre signaturer ovenfor afgør det normalt i én session.