Skal VPN’en på iPhone være tændt hele tiden? To krav afgør det

To personer lader den samme VPN-profil være slået til hele dagen og får forskellig værdi ud af det. Den ene når en privat arbejdsapplikation uden at tænke over det; den anden holder en personlig tunnel kørende mest af vane. Begge ser den samme indikator i statuslinjen, og den indikator er det eneste, de to ordninger har til fælles.

Beslutningen handler ikke om, hvorvidt vedvarende dækning føles sikrere. Den handler om, hvilket krav du betaler for, hvad klienten gør, når gatewayen ikke kan nås, og hvor meget af din trafik den valgte udbyder kan se. Svar på de tre, og kontakten holder op med at være en smagssag.

To opgaver, der deler ét ikon

Det første job er adgang: et bestemt sæt private ressourcer bør kunne nås, når du åbner appen, uanset hvor du er. Det andet job er dækning: trafik, der ellers ville krydse et ukendt netværk, bør i stedet forlade gennem en tjeneste, du stoler på.

De peger på forskellige konfigurationer. Adgang vil have det snævreste omfang, der stadig virker, fordi en fuld tunnel til én intern applikation sender alt andet gennem et netværk, der aldrig var dimensioneret til det. Dækning vil have det bredeste omfang, du kan tolerere, fordi en tunnel, der kun bærer nogle applikationer, efterlader resten blotlagt på netop det netværk, du var bekymret for. De fleste fejlkonfigurerede telefoner ender som en blanding af begge, og derfor skal kravet navngives, før profilen vælges.

Privat arbejdsadgang: omfang slår permanens

Hvis målet er at nå en intern applikation, er det nyttige spørgsmål, hvornår tunnelen aktiveres, ikke om den forbliver oppe. En administreret ordning per app kan sende kun den applikations trafik gennem gatewayen, hvilket holder privat browsing på den almindelige vej og arbejdstrafikken på den godkendte. Det er en anden form for kontrol end en fuld tunnel, og det ændrer, hvad indikatoren betyder. Med omfang per app kan ikonet mangle, mens arbejdsappen stadig når sin tjeneste.

Det omfang er en politikbeslutning truffet af den, der ejer udrulningen, ikke en personlig præference, du kan udlede af appens adfærd. Klientens indstillingsskærme afslører ikke altid hvilken af platformens flere mekanismer der er i kraft, og etiketterne overlapper på måder, der vildleder.

Apples dokumentation skelner mellem betinget aktivering, valg per app og administreret altid-til-adfærd. En tredjepartsklients kontakt til automatisk forbindelse hører ikke i sig selv til nogen af disse kategorier, så en etiket, der lyder tilsvarende, bør ikke læses som et løfte om den administrerede egenskab.

Den praktiske test er en anmodning til en tjeneste, du ved er intern, sendt med tunnelen bevidst slået fra. Hvis den lykkes, er tunnelen ikke den kontrol, du tror, og resten af konfigurationen fortjener et andet blik, før du regner med den.

Dækket browsing: fejlstrategien er produktet

Hvis målet er dækning på ukendte netværk, er den interessante del af produktet ikke forbindelsen, men afbrydelsen. To klienter, der begge forbinder automatisk, kan opføre sig helt forskelligt i det øjeblik, gatewayen afviser, eller netværket blokerer den.

En blokeringspolitik gør dækket trafik utilgængelig, mens tunnelen ikke kan etableres. Det er den stærkeste version af dækning og den mest forstyrrende: et udfald bliver dit udfald, og en captive portal bliver en mur, du ikke kan komme forbi for at nå den side, der ville lukke dig igennem.

En fallback-politik holder dig online ved at lade trafikken tage den almindelige vej. Det er mere brugbart og svagere per definition, fordi det præcise øjeblik, hvor tunnelen fejler, er det øjeblik, hvor trafikken forlader nettet ukrypteret gennem det netværk, du er på. Trafikken forlader stadig, og den forlader på det netværk, du ikke stolede på. Det er byttet, sagt uden markedsføringen.

Ingen af dem er forkerte, og fejlen er at opdage, hvilken du købte, under en rejse. Test det derhjemme: slå tunnelens evne til at forbinde fra, og se så, om siderne indlæses. Det ene eksperiment fortæller dig mere end nogen beskrivelse på en udbyders marketingside.

Hvad tunnelen ikke reparerer

Rutning af trafik gennem én udbyder giver den udbyder en position i din forbindelsesvej. Det gør ikke de websteder, du besøger, troværdige, og det erstatter ikke HTTPS, kontosikkerhed eller omhu med, hvilke profiler du installerer. En tunnel, der ender i en udbyders netværk, er en ændring af, hvem der kan observere hvad, ikke en fjernelse af spørgsmålet.

Det samme gælder det lokale netværk. En VPN kan holde din trafik væk fra et hotels adgangsnetværk, og den kan ikke forhindre det netværk i at blokere selve tunnelen eller forstyrre navneopløsningen, før tunnelen findes.

Ydeevne og batteri hører i samme kategori af ærlig observation. Der er ingen fast straf knyttet til indikatoren; den rute, gatewayen tager, adgangsnetværkets kvalitet, mængden af trafik og hyppigheden af genopkoblinger flytter alle tallet. At sammenligne to konfigurationer under samme brug er den eneste måling, der betyder noget.

Vælg til den enhed, du faktisk har

På en personlig telefon vælger du den adfærd, der passer til dit krav, og skriver den fejlstrategi ned, du har accepteret. Hvis du valgte dækning med blokering, så behold en måde at nå udbyderens statusside fra en anden enhed; hvis du valgte fallback, så vid, at tunnelens fejl er tavs af design.

På en administreret arbejdstelefon er administratorens politik svaret, og fraværet af en pausekontrol er normalt bevidst snarere end en forglemmelse, man skal gå udenom. At bede om en undtagelse gennem den normale kanal er hurtigere end at finde en omvej, som den næste profilopdatering fjerner.

Uanset hvad, tag beslutningen op igen, når formålet ændrer sig. En tunnel konfigureret til én intern applikation passer dårligt til dækning af browsing på fuld tid, og en fuldtunnelprofil, der holdes til en enkelt app, flytter stille en masse trafik, du aldrig havde tænkt dig at aflevere.