Vraagt de werkapp om een VPN? Controleer eerst deze drie lagen

Het bericht zegt dat de app een VPN nodig heeft, maar meestal meldt de app een symptoom in plaats van te benoemen wat hem heeft geblokkeerd. Drie verschillende eigenaren kunnen die zin produceren: de privédienst waarmee de app praat, de eigen beleidscode van de app en de apparaatbeheerland die het werkprofiel bestuurt. Welke van de drie het vraagt, verandert wat u moet doen, en slechts één van de drie wordt opgelost door een tunnel te verbinden. Eerst de eigenaar vinden bespaart u het herinstalleren van een client die nooit het probleem was.

Wat de app zelf kan controleren

Voordat u een verborgen platformregel aanneemt, bedenk dat een gewone app kan zien of een VPN-transport actief is. ConnectivityManager meldt netwerken die TRANSPORT_VPN dragen, en de afwezigheid van NET_CAPABILITY_NOT_VPN vertelt elke aanroeper dat het huidige pad via een tunnel loopt. Een ontwikkelaar die buiten een tunnel wil weigeren te werken, kan dat doen met openbare API's en helemaal zonder bedrijfshulpmiddelen.

Wat de app zo niet kan zien, is van wie de VPN is. Een transportvlag zegt dat er een tunnel bestaat, niet dat die eindigt waar uw organisatie het verwacht.

Het dienstpad: privénamen en adressen

De meest voorkomende eerlijke versie van het bericht is helemaal geen beleidscontrole. De app lost een interne hostnaam op, zoals een wiki of een API-eindpunt dat alleen binnen de bedrijfs-DNS-weergave bestaat, en de opzoeking mislukt voordat er enige beleidscode draait. De tunnel kan actief zijn en algemeen internetverkeer doorlaten terwijl gesplitste DNS die naam naar een resolver stuurt die er nooit van heeft gehoord.

De symptomen zijn hier smal. Eén host mislukt, de rest van de netwerkaanroepen van de app werkt, en de fout verschijnt tijdens een naamopzoeking en niet bij het starten. Interne certificaten voegen een tweede foutmodus toe, want een app die aan de CA van de organisatie is vastgezet, weigert een openbaar certificaat zelfs wanneer de pakketten stromen.

Een willekeurige commerciële VPN verbinden lost daar niets van op. Het verandert uw uitgaande adres en laat de interne naam net zo onoplosbaar.

De beleidslaag van de app

Een app kan ook zijn eigen poort dragen. Beheerde configuraties laten de organisatie sleutel-waardeparen pushen die de app aangeeft, en de app leest ze via RestrictionManager. Een sleutel zoals een vereiste profielnaam of een lijst met toegestane netwerken is volledig het ontwerp van de ontwikkelaar, afgedwongen in de appcode met de fouttekst die die code kiest.

Deze laag is waar de formulering het meestal verraadt. Als het bericht meteen bij het starten verschijnt, vóór enige netwerkaanroep, en een beleid, een profiel of een beheerder noemt, kijkt u waarschijnlijk naar applicatielogica en niet naar een verloren pakket.

Dezelfde beperking op een persoonlijk apparaat lezen is een doodlopende weg. Niet-beheerde apparaten hebben geen beperkingen om te lezen, dus valt de app terug op de standaardwaarde waarmee hij is gebouwd.

De platformlaag: altijd aan en vergrendeling

Apparaatbeheer voegt handhaving toe die de app niet kan overschrijven. Een apparaatbeleidscontroller kan setAlwaysOnVpnPackage voor het werkprofiel aanroepen, optioneel met vergrendeling ingeschakeld, en zodra de vergrendeling aan staat weigert het platform verkeer dat niet via dat pakket gaat. De blokkade is zichtbaar als een systeemconditie en niet als een appfout: andere apps in het profiel bereiken het netwerk ook niet meer.

De reikwijdte is belangrijk. Always-on-VPN wordt per gebruiker geconfigureerd, dus een werkprofielpakket dekt uw persoonlijke profiel niet, en een persoonlijke VPN voldoet niet aan het werkprofielpakket. Twee profielen, twee onafhankelijke netwerkbeleidsregels, één apparaat.

Dit is ook de enige laag waar een niet-verwante VPN niet kan helpen, omdat het beleid één specifiek pakket noemt.

De drie onderscheiden

Loop de signaturen op volgorde door en stop bij de eerste die past. Eén hostnaam die mislukt terwijl al het andere oplost, wijst op het dienstpad. Een onmiddellijke weigering bij het starten met beleidsformulering wijst op applicatielogica. Een heel profiel dat de verbinding verliest telkens wanneer de goedgekeurde client loskoppelt, wijst op de vergrendeling. En een app die elke tunnel accepteert, controleert de transportvlag, niet de identiteit van uw organisatie.

Nuttig bewijs: de exacte tekst en het tijdstip, of andere apps in hetzelfde profiel nog verbinding hebben, of de privénaam binnen de goedgekeurde tunnel oplost en of het apparaat een werkbadge toont voor de app die u heeft geopend.

Wat u in het supportverzoek zet

Een verzoek dat de laag noemt, wordt bij de eerste poging correct gerouteerd. Iets als: de werkprofielapp opent, de bronnenlijst mislukt nadat de goedgekeurde VPN verbindt, privénaamresolutie mislukt in de toegestane diagnose, en andere apps in het profiel blijven werken. Dat leest als een route- of resolverprobleem en slaat de accountreset-lus over.

Als de goedgekeurde VPN volledig ontbreekt, is het ondersteunde pad inschrijving of opnieuw inrichten via uw beheerder. Het beheerprofiel verwijderen, een niet-verwante client installeren of de netwerkstatus vervalsen verandert de beveiligingsregeling in plaats van die te herstellen.

Begin bij de laag, niet bij de client. De drie signaturen hierboven beslechten het meestal in één sessie.