Blokker VPN-konfigurasjon på Android: sjekkliste for utrulling

Noen ber deg hindre folk i å konfigurere sin egen VPN på administrerte Android-enheter. Det fristende svaret er en brannmurregel som blokkerer noen få kjente porter. Det svaret overser hvordan plattformen fungerer og hvordan applikasjoner faktisk kobler til.

Den støttede kontrollen er en administrasjonsbegrensning på enheten eller profilen du eier, og den har et eksplisitt omfang, versjonsavhengig atferd og et unntak du må konfigurere bevisst.

Gå gjennom de fem kontrollene nedenfor i rekkefølge. Hver av dem kan ugyldiggjøre planen, så stopp ved den første som ikke holder.

Kontroll 1: bestem hva ingen VPN betyr

To krav gjemmer seg bak samme setning. Det ene er at ingen bruker kan opprette sin egen VPN. Det andre er at bare organisasjonens godkjente VPN kan kjøre. Begge er legitime, og de gir forskjellige konfigurasjoner, forskjellige støttehistorier og forskjellige feilmodi.

Skriv ned hvilken av dem du kjøper før du rører en administrasjonskonsoll. Hvis hensikten er én godkjent tunnel for alle, implementerer du en godkjent vei med et forbud rundt; hvis hensikten er ingen tunneler i det hele tatt, må du også akseptere at veier for fjernaksess og feilsøking endres.

Tar du feil her, ser utrullingen ut til å virke mens den stille kutter VPN-en driften er avhengig av, noe som vanligvis oppdages av den som har vakt på et ubeleilig tidspunkt.

Kontroll 2: bekreft myndigheten du faktisk har

Android eksponerer begrensningen gjennom UserManager.DISALLOW_CONFIG_VPN, dokumentert i UserManager-referansen. Den hindrer VPN-konfigurasjon og -oppstart, og det er ikke en innstilling en vanlig applikasjon kan bruke på seg selv eller på andre apper.

Den brukes av en autorisert administrator: en enhetseier for hele enheten, eller en profileier for den administrerte profilen, med samme myndighet tilgjengelig for en profileier inne i den administrerte profilen. Hvis EMM-en din ikke kan opptre som en av disse, har du ikke denne kontrollen, og ingen mengde policykonfigurasjon i konsollen vil skape den.

Omfang betyr like mye som myndighet. En begrensning som brukes på en arbeidsprofil, styrer den profilen, ikke den personlige siden av samme telefon. Å beskrive det som kontroll over alt brukeren gjør er unøyaktig, og det vil bli testet av den første som installerer en VPN i den personlige profilen og oppdager at den virker.

Kontroll 3: kjenn atferden per versjon

Begrensningen har endret seg gjennom utgivelsene, og forskjellene avgjør hva utrullingen din faktisk vil gjøre på enhetene i felt.

API 31-raden er den som overrasker folk midt i utrullingen: på disse enhetene er håndhevelsen ikke kosmetisk, den kobler fra en tunnel som allerede kjørte. Planlegg det som en synlig hendelse i stedet for en stille innstillingsendring.

API 24-raden er den som redder deg: en alltid-på-VPN konfigurert av eieren overlever begrensningen, og det er slik den godkjente veien i det hele tatt forblir tilgjengelig.

Kontroll 4: hold den godkjente veien i live

Konfigurer og test organisasjonens alltid-på-VPN før du håndhever begrensningen, ikke etterpå. Håndhever du først, mister enhetene tunnelen og verktøyene du ville diagnostisere dem med samtidig.

Bekreft tre ting eksplisitt: at alltid-på-VPN-en opprettes av eieren og ikke av brukeren; at den starter på disse enhetene etter håndhevelsen; og at den overlever en omstart. En tunnel som bare kommer opp manuelt, er ikke en godkjent vei; det er en kø av støttebilletter.

Behold en gjenopprettingsvei som ikke avhenger av at tunnelen er oppe. En administrasjonskonsoll, en lokal admin-vei eller en kanal utenfor båndet fungerer alle. Det som ikke fungerer, er å anta at du kan rette en ødelagt policy gjennom tilkoblingen policyen nettopp deaktiverte.

Kontroll 5: verifiser, og beskriv deretter grensen ærlig

Test med en ekte enhet og en ekte konto. Bekreft at en bruker ikke kan legge til eller starte en VPN, bekreft at den godkjente tunnelen kobler til og bærer trafikk, og bekreft at den personlige profilen fortsatt oppfører seg som dokumentert. Disse tre resultatene er akseptkriteriene.

Vær deretter forsiktig med hva du påstår. Begrensningen styrer Androids VPN-evne. Den gjør ikke hver tillatt tilkobling til en inspisert protokoll, og den hindrer ikke en app i å rute sine egne forespørsler gjennom en eksplisitt proxy. Å blokkere UDP 500, UDP 4500 og én OpenVPN-port er ikke den samme kontrollen, fordi trafikk kan reise over mange transporter, inkludert vanlig utseende HTTPS.

Hvis kravet er bredere enn VPN-evnen, kombiner dette med appdistribusjonspolicy, kontokontroller og nettverksbegrensninger som passer miljøet. Og registrer hva som blir stående utenfor omfanget, slik at ingen gjentar en delvis begrensning som en fullstendig i neste revisjon.