Blockera VPN-konfiguration på Android: checklista för utrullningen
Bestäm policyn, bekräfta den behörighet du har, kontrollera beteendet per version och håll den godkända alltid-på-vägen vid liv innan du verkställer.
Någon ber dig hindra människor från att konfigurera sin egen VPN på hanterade Android-enheter. Det frestande svaret är en brandväggsregel som blockerar några välkända portar. Det svaret bortser från hur plattformen fungerar och hur applikationer faktiskt ansluter.
Den stödda kontrollen är en administrationsbegränsning på enheten eller profilen du äger, och den har en uttrycklig omfattning, versionsberoende beteende och ett undantag du måste konfigurera medvetet.
Gå igenom de fem kontrollerna nedan i ordning. Var och en kan ogiltigförklara planen, så stanna vid den första som inte håller.
Kontroll 1: bestäm vad ingen VPN betyder
Bakom samma mening döljer sig två krav. Det ena är att ingen användare får skapa sin egen VPN. Det andra är att endast organisationens godkända VPN får köras. Båda är legitima, och de ger olika konfigurationer, olika supportberättelser och olika fellägen.
Skriv ned vilken av dem du köper innan du rör en administrationskonsol. Om avsikten är en enda godkänd tunnel för alla implementerar du en godkänd väg med ett förbud runt den; om avsikten är inga tunnlar alls måste du också acceptera att vägar för fjärråtkomst och felsökning förändras.
Gör fel här och utrullningen verkar fungera medan den tyst skär av den VPN som driften är beroende av, vilket vanligtvis upptäcks av den som har jour vid en olämplig timme.
Kontroll 2: bekräfta den behörighet du faktiskt har
Android exponerar begränsningen genom UserManager.DISALLOW_CONFIG_VPN, dokumenterad i UserManager-referensen. Den förhindrar VPN-konfiguration och -start, och det är inte en inställning som en vanlig applikation kan tillämpa på sig själv eller på andra appar.
Den tillämpas av en auktoriserad administratör: en enhetsägare för hela enheten, eller en profilägare för den hanterade profilen, med samma behörighet tillgänglig för en profilägare inuti den hanterade profilen. Om din EMM inte kan agera som en av dessa har du inte den här kontrollen, och ingen mängd policykonfiguration i konsolen skapar den.
Omfattningen spelar lika stor roll som behörigheten. En begränsning som tillämpas på en arbetsprofil styr den profilen, inte den personliga sidan av samma telefon. Att beskriva det som kontroll över allt användaren gör är felaktigt, och det kommer att testas av den första person som installerar en VPN i den personliga profilen och upptäcker att den fungerar.
Kontroll 3: känn till beteendet per version
Begränsningen har förändrats mellan utgåvorna, och skillnaderna avgör vad din utrullning faktiskt gör på enheterna i fält.
| Plattformsgräns | Dokumenterat beteende |
|---|---|
| Enhets- eller profilägare | Begränsningen kan tillämpas under den ägarens behörighet |
| API 24 och senare | En alltid-på-VPN som enhets- eller profilägaren konfigurerade startas fortfarande av systemet |
| API 31 och senare | Om du slår på begränsningen kopplas en VPN ned som användaren redan hade igång |
API 31-raden är den som överraskar folk mitt i utrullningen: på dessa enheter är verkställandet inte kosmetiskt, det kopplar ned en tunnel som redan körde. Planera det som en synlig händelse i stället för en tyst inställningsändring.
API 24-raden är den som räddar dig: en alltid-på-VPN konfigurerad av ägaren överlever begränsningen, och det är så den godkända vägen överhuvudtaget förblir tillgänglig.
Kontroll 4: håll den godkända vägen vid liv
Konfigurera och testa organisationens alltid-på-VPN innan du verkställer begränsningen, inte efteråt. Verkställer du först förlorar enheterna tunneln och verktygen du skulle diagnosticera dem med samtidigt.
Verifiera tre saker uttryckligen: att alltid-på-VPN:en skapas av ägaren och inte av användaren; att den startar på dessa enheter efter verkställandet; och att den överlever en omstart. En tunnel som bara kommer upp manuellt är inte en godkänd väg; det är en kö av supportärenden.
Behåll en återställningsväg som inte är beroende av att tunneln är uppe. En administrationskonsol, en lokal adminväg eller en kanal utanför bandet fungerar alla. Det som inte fungerar är att anta att du kan laga en trasig policy genom den anslutning som policyn just inaktiverade.
Kontroll 5: verifiera och beskriv sedan gränsen ärligt
Testa med en riktig enhet och ett riktigt konto. Bekräfta att en användare inte kan lägga till eller starta en VPN, bekräfta att den godkända tunneln ansluter och bär trafik, och bekräfta att den personliga profilen fortfarande beter sig som dokumenterat. Dessa tre resultat är acceptanskriterierna.
Var sedan försiktig med vad du påstår. Begränsningen styr Androids VPN-förmåga. Den gör inte varje tillåten anslutning till ett inspekterat protokoll, och den hindrar inte en app från att routa sina egna förfrågningar genom en explicit proxy. Att blockera UDP 500, UDP 4500 och en OpenVPN-port är inte samma kontroll, eftersom trafik kan färdas över många transportmedel, inklusive vanligt utseende HTTPS.
Om kravet är bredare än VPN-förmågan, kombinera detta med appdistributionspolicy, kontokontroller och nätverksbegränsningar som passar miljön. Och registrera vad som står utanför omfattningen, så att ingen upprepar en partiell begränsning som en fullständig i nästa revision.