Kræver jobbappen VPN? Sjekk disse tre lagene først

Meldingen sier at appen trenger VPN, men vanligvis rapporterer appen et symptom i stedet for å navngi det som blokkerte den. Tre forskjellige eiere kan produsere den setningen: den private tjenesten appen snakker med, appens egen policykode og enhetsadministrasjonslaget som styrer arbeidsprofilen. Hvilken av dem som spør, endrer hva du bør gjøre, og bare én av de tre løses ved å koble til en tunnel. Å finne eieren først sparer deg for å installere på nytt en klient som aldri var problemet.

Hva appen selv kan sjekke

Før du antar en skjult plattformregel, husk at en vanlig app kan se om en VPN-transport er aktiv. ConnectivityManager rapporterer nettverk som bærer TRANSPORT_VPN, og fraværet av NET_CAPABILITY_NOT_VPN forteller enhver innringer at gjeldende vei går gjennom en tunnel. En utvikler som vil nekte å kjøre utenfor en tunnel, kan gjøre det med offentlige API-er og helt uten bedriftsverktøy.

Det appen ikke kan se på den måten, er hvem sin VPN det er. Et transportflagg sier at en tunnel finnes, ikke at den ender der organisasjonen din forventer.

Tjenestestien: private navn og adresser

Den vanligste ærlige versjonen av meldingen er ikke en policykontroll i det hele tatt. Appen løser opp et internt vertsnavn som en wiki eller et API-endepunkt som bare finnes i bedriftens DNS-visning, og oppslaget feiler før noen policykode kjører. Tunnelen kan være oppe og slippe gjennom vanlig internettrafikk mens delt DNS sender navnet til en resolver som aldri har hørt om det.

Symptomene her er smale. Én vert feiler, resten av appens nettverkskall virker, og feilen vises under et navneoppslag i stedet for ved oppstart. Interne sertifikater legger til en annen feilmodus, fordi en app som er festet til organisasjonens CA, avviser et offentlig sertifikat selv når pakkene flyter.

Å koble til en tilfeldig kommersiell VPN fikser ingenting av dette. Det endrer utgangsadressen din og lar det interne navnet være like uløselig.

Appens policylag

En app kan også bære sin egen port. Administrerte konfigurasjoner lar organisasjonen skyve nøkkel- og verdipar som appen erklærer, og appen leser dem gjennom RestrictionManager. En nøkkel som et påkrevd profilnavn eller en liste over tillatte nettverk er helt utviklerens design, håndhevet i applikasjonskoden med den feilteksten den koden velger.

Dette laget er der ordlyden vanligvis avslører det. Hvis meldingen vises umiddelbart ved oppstart, før noe nettverkskall, og nevner en policy, en profil eller en administrator, ser du sannsynligvis applikasjonslogikk og ikke en tapt pakke.

Å lese den samme begrensningen på en personlig enhet er en blindvei. Ikke-administrerte enheter har ingen begrensninger å lese, så appen faller tilbake til den standardverdien den ble bygget med.

Plattformlaget: alltid på og låsing

Enhetsadministrasjon legger til håndheving som appen ikke kan overstyre. En enhetspolicykontroller kan kalle setAlwaysOnVpnPackage for arbeidsprofilen, eventuelt med låsing aktivert, og når låsingen er på, avviser plattformen trafikk som ikke går gjennom den pakken. Blokkeringen vises som en systemtilstand og ikke som en appfeil: andre apper i profilen slutter også å nå nettverket.

Omfanget betyr noe. Alltid på-VPN konfigureres per bruker, så en arbeidsprofilpakke dekker ikke din personlige profil, og en personlig VPN oppfyller ikke arbeidsprofilpakken. To profiler, to uavhengige nettverkspolicyer, én enhet.

Dette er også det eneste laget der en urelatert VPN ikke kan hjelpe, fordi policyen navngir én bestemt pakke.

Å skille de tre

Gå gjennom signaturene i rekkefølge og stopp ved den første som passer. Ett vertsnavn feiler mens alt annet løses opp, peker på tjenestestien. En umiddelbar avvisning ved oppstart med policyordlyd peker på applikasjonslogikk. En hel profil som mister tilkoblingen hver gang den godkjente klienten kobler fra, peker på låsing. Og en app som godtar hvilken som helst tunnel, kontrollerer transportflagget, ikke organisasjonens identitet.

Nyttige bevis: den nøyaktige teksten og tidspunktet, om andre apper i samme profil fortsatt har tilkobling, om det private navnet løses opp inne i den godkjente tunnelen, og om enheten viser et arbeidsmerke for appen du åpnet.

Hva du bør skrive i støtteforespørselen

En forespørsel som navngir laget, blir rutet riktig på første forsøk. Noe som: arbeidsprofilappen åpnes, ressurslisten feiler etter at den godkjente VPN-en kobles til, privat navneoppslag feiler i den tillatte diagnostikken, og andre apper i profilen fortsetter å virke. Det leses som et rute- eller resolverproblem og hopper over konto-tilbakestillingsløkken.

Hvis den godkjente VPN-en mangler helt, er den støttede veien registrering eller ny klargjøring gjennom administratoren din. Å fjerne administrasjonsprofilen, installere en urelatert klient eller forfalske nettverkstilstanden endrer sikkerhetsoppsettet i stedet for å gjenopprette det.

Start med laget, ikke klienten. De tre signaturene over avgjør det vanligvis i én økt.