Krev jobbappen VPN? Sjekk desse tre laga først

Meldinga seier at appen treng VPN, men vanlegvis rapporterer appen eit symptom i staden for å namngje det som blokkerte han. Tre ulike eigarar kan lage den setninga: den private tenesta appen snakkar med, appens eigen policykode og eininga sitt administrasjonslag som styrer arbeidsprofilen. Kven av dei som spør, endrar kva du bør gjere, og berre éin av dei tre blir løyst ved å kopie til ein tunnel. Å finne eigaren først sparer deg for å installere på nytt ein klient som aldri var problemet.

Kva appen sjølv kan sjekke

Før du føreset ei skjult plattformregel, hugs at ein vanleg app kan sjå om ein VPN-transport er aktiv. ConnectivityManager rapporterer nettverk som ber TRANSPORT_VPN, og fråværet av NET_CAPABILITY_NOT_VPN fortel kvar ein kallar at gjeldande veg går gjennom ein tunnel. Ein utviklar som vil nekte å køyre utanfor ein tunnel, kan gjere det med offentlege API og heilt utan bedriftsverktøy.

Det appen ikkje kan sjå på den måten, er kven sin VPN det er. Eit transportflagg seier at ein tunnel finst, ikkje at han endar der organisasjonen din ventar.

Tenestestien: private namn og adresser

Den vanlegaste ærlege versjonen av meldinga er ikkje ein policykontroll i det heile. Appen løyser opp eit internt vertsnamn som ein wiki eller eit API-endepunkt som berre finst i bedrifta si DNS-vising, og oppslaget feilar før nokon policykode køyrer. Tunnelen kan vere oppe og sleppe gjennom vanleg internettrafikk medan delt DNS sender namnet til ein resolver som aldri har høyrt om det.

Symptoma her er smale. Éin vert feilar, resten av nettverkskalla til appen verkar, og feilen viser seg under eit namneoppslag i staden for ved oppstart. Interne sertifikat legg til ein annan feilmodus, fordi ein app som er festa til CA-en til organisasjonen, avviser eit offentleg sertifikat sjølv når pakkane flyt.

Å kopie til ein tilfeldig kommersiell VPN fiksar ingenting av dette. Det endrar utgangsadressa di og lèt det interne namnet vere like uløyseleg.

Policylaget til appen

Ein app kan også bere si eiga port. Administrerte konfigurasjonar lèt organisasjonen skyve nøkkel- og verdipar som appen erklærer, og appen les dei gjennom RestrictionManager. Ein nøkkel som eit påkravd profilnamn eller ei liste over tillatne nettverk er heilt utvikaren sitt design, handheva i applikasjonskoden med den feilteksten den koden vel.

Dette laget er der ordlyden vanlegvis avslører det. Viss meldinga kjem straks ved oppstart, før noko nettverkskall, og nemner ein policy, ein profil eller ein administrator, ser du truleg applikasjonslogikk og ikkje ein tapt pakke.

Å lese den same avgrensinga på ei personleg eining er ein blindveg. Ikkje-administrerte einingar har ingen avgrensingar å lese, så appen fell tilbake til den standardverdien han vart bygd med.

Plattformlaget: alltid på og låsing

Einingsadministrasjon legg til handheving som appen ikkje kan overstyre. Ein einingspolicykontrollør kan kalle setAlwaysOnVpnPackage for arbeidsprofilen, eventuelt med låsing slått på, og når låsinga er på, avviser plattformen trafikk som ikkje går gjennom den pakken. Blokkeringa viser seg som ein systemtilstand og ikkje som ein appfeil: andre apper i profilen sluttar også å nå nettverket.

Omfanget betyr noko. Alltid på-VPN blir konfigurert per brukar, så ein arbeidsprofilpakke dekkjer ikkje din personlege profil, og ein personleg VPN oppfyller ikkje arbeidsprofilpakken. To profilar, to uavhengige nettverkspolicyar, éi eining.

Dette er også det einaste laget der ein urelatert VPN ikkje kan hjelpe, fordi policyen namngjev éin bestemd pakke.

Å skilje dei tre

Gå gjennom signaturane i rekkjefølgje og stopp ved den første som passar. Eitt vertsnamn feilar medan alt anna blir løyst opp, peikar på tenestestien. Ei umiddelbar avvising ved oppstart med policyordlyd peikar på applikasjonslogikk. Ein heil profil som mistar tilkoplinga kvar gong den godkjende klienten koplar frå, peikar på låsing. Og ein app som godtek kva som helst tunnel, kontrollerer transportflagget, ikkje identiteten til organisasjonen.

Nyttige prov: den nøyaktige teksten og tidspunktet, om andre apper i same profil framleis har tilkopling, om det private namnet blir løyst opp inne i den godkjende tunnelen, og om eininga viser eit arbeidsmerke for appen du opna.

Kva du bør skrive i støtteførespurnaden

Ein førespurnad som namngjev laget, blir ruta rett på første forsøk. Noko som: arbeidsprofilappen opnar, ressurslista feilar etter at den godkjende VPN-en koplar til, privat namneoppslag feilar i den tillatne diagnostikken, og andre apper i profilen held fram med å verke. Det blir lese som eit rute- eller resolverproblem og hoppar over konto-tilbakestillingsløkka.

Viss den godkjende VPN-en manglar heilt, er den støtta vegen registrering eller ny klargjering gjennom administratoren din. Å fjerne administrasjonsprofilen, installere ein urelatert klient eller forfalske nettverkstilstanden endrar tryggleiksoppsettet i staden for å gjenopprette det.

Start med laget, ikkje klienten. Dei tre signaturane over avgjer det vanlegvis i éi økt.