Kräver arbetsappen en VPN? Kontrollera de här tre lagren först

Meddelandet säger att appen behöver en VPN, men vanligtvis rapporterar appen ett symptom i stället för att namnge det som blockerade den. Tre olika ägare kan producera den meningen: den privata tjänsten som appen pratar med, appens egen policykod och enhetshanteringslagret som styr arbetsprofilen. Vilken av dem som frågar ändrar vad du bör göra, och bara en av de tre åtgärdas genom att ansluta en tunnel. Att hitta ägaren först sparar dig från att installera om en klient som aldrig var problemet.

Vad appen själv kan kontrollera

Innan du antar en dold plattformsregel, kom ihåg att en vanlig app kan se om en VPN-transport är aktiv. ConnectivityManager rapporterar nätverk som bär TRANSPORT_VPN, och avsaknaden av NET_CAPABILITY_NOT_VPN säger till varje anropare att den aktuella vägen går genom en tunnel. En utvecklare som vill vägra köra utanför en tunnel kan göra det med offentliga API:er och helt utan företagsverktyg.

Det appen inte kan se på det sättet är vems VPN det är. En transportflagga säger att en tunnel finns, inte att den slutar där din organisation förväntar sig.

Tjänstevägen: privata namn och adresser

Den vanligaste ärliga versionen av meddelandet är inte en policykontroll alls. Appen löser ett internt värdnamn som en wiki eller en API-slutpunkt som bara finns i företagets DNS-vy, och uppslaget misslyckas innan någon policykod körs. Tunneln kan vara uppe och släppa igenom vanlig internettrafik medan delad DNS skickar namnet till en resolver som aldrig har hört talas om det.

Symptomen är smala här. En värd misslyckas, resten av appens nätverksanrop fungerar, och felet visas vid ett namnuplag och inte vid start. Interna certifikat lägger till ett andra felläge, eftersom en app som är fäst vid organisationens CA avvisar ett offentligt certifikat även när paketen flödar.

Att ansluta en slumpmässig kommersiell VPN fixar inget av detta. Det ändrar din utgångsadress och lämnar det interna namnet lika olösligt.

Appens policylager

En app kan också bära sin egen port. Hanterade konfigurationer låter organisationen skicka nyckel- och värdepar som appen deklarerar, och appen läser dem via RestrictionManager. En nyckel som ett obligatoriskt profilnamn eller en lista över tillåtna nätverk är helt utvecklarens design, genomförd i applikationskoden med den feltext som koden väljer.

Det här lagret är där formuleringen vanligtvis avslöjar det. Om meddelandet visas direkt vid start, före något nätverksanrop, och nämner en policy, en profil eller en administratör, tittar du troligen på applikationslogik och inte ett tappat paket.

Att läsa samma begränsning på en personlig enhet är en återvändsgränd. Ohanterade enheter har inga begränsningar att läsa, så appen faller tillbaka på det standardvärde den byggdes med.

Plattformslagret: alltid på och låsning

Enhetshantering lägger till genomdrivande som appen inte kan åsidosätta. En enhetspolicykontroll kan anropa setAlwaysOnVpnPackage för arbetsprofilen, eventuellt med låsning aktiverad, och när låsningen är på vägrar plattformen trafik som inte går genom det paketet. Blockeringen syns som ett systemtillstånd och inte som ett appfel: andra appar i profilen slutar också nå nätverket.

Omfattningen spelar roll. Alltid på-VPN konfigureras per användare, så ett arbetsprofilpaket täcker inte din personliga profil, och en personlig VPN uppfyller inte arbetsprofilpaketet. Två profiler, två oberoende nätverkspolicyer, en enhet.

Det är också det enda lagret där en orelaterad VPN inte kan hjälpa, eftersom policyn namnger ett specifikt paket.

Att skilja de tre åt

Gå igenom signalerna i ordning och stanna vid den första som passar. Ett värdnamn misslyckas medan allt annat löses, pekar på tjänstevägen. Ett omedelbart avslag vid start med policyformulering pekar på applikationslogik. En hel profil som tappar anslutningen varje gång den godkända klienten kopplar från, pekar på låsningen. Och en app som accepterar vilken tunnel som helst kontrollerar transportflaggan, inte din organisations identitet.

Användbara bevis: den exakta texten och dess tidpunkt, om andra appar i samma profil fortfarande har anslutning, om det privata namnet löses inuti den godkända tunneln och om enheten visar en arbetsbricka för appen du öppnade.

Vad du ska skriva i supportbegäran

En begäran som namnger lagret dirigeras rätt vid första försöket. Ungefär så här: arbetsprofilappen öppnas, resurslistan misslyckas efter att den godkända VPN:en anslutit, privat namnuplag misslyckas i den tillåtna diagnostiken, och andra appar i profilen fortsätter att fungera. Det läses som ett rutt- eller resolverproblem och hoppar över kontots återställningsloop.

Om den godkända VPN:en saknas helt är den stödda vägen registrering eller ny etablering via din administratör. Att ta bort hanteringsprofilen, installera en orelaterad klient eller förfalska nätverkstillståndet ändrar säkerhetsarrangemanget i stället för att återställa det.

Börja med lagret, inte klienten. De tre signalerna ovan avgör det vanligtvis i en enda session.