Skal VPN-en på iPhone vera på heile tida? To krav avgjer

To personar let den same VPN-profilen vera på heile dagen og får ulik nytte av han. Den eine når ein privat arbeidsapplikasjon utan å tenkje over det; den andre held ein personleg tunnel i gang mest av vane. Begge ser den same indikatoren i statuslinja, og den indikatoren er det einaste dei to ordningane har til felles.

Avgjerda handlar ikkje om varig dekning kjennest tryggare. Ho handlar om kva krav du betalar for, kva klienten gjer når gatewayen ikkje er tilgjengeleg, og kor mykje av trafikken din den valde operatøren kan sjå. Svar på dei tre, og brytaren sluttar å vera ei smakssak.

To jobbar som deler eit ikon

Den første jobben er tilgang: eit bestemt sett private ressursar bør vera tilgjengeleg når du opnar appen, uansett kvar du er. Den andre jobben er dekning: trafikk som elles ville krysse eit ukjent nettverk, bør i staden gå ut gjennom ei teneste du stolar på.

Dei peikar mot ulike konfigurasjonar. Tilgang vil ha det smalaste omfanget som framleis verkar, fordi ein full tunnel for ein intern applikasjon sender alt anna gjennom eit nettverk som aldri var dimensjonert for det. Dekning vil ha det breiaste omfanget du kan tole, fordi ein tunnel som berre ber nokre applikasjonar, lèt resten stå eksponert på nettopp det nettverket du var uroa for. Dei fleste feilkonfigurerte telefonar endar som ei blanding av begge, difor må kravet nemnast før profilen blir vald.

Privat jobbtilgang: omfang slår varigheit

Viss målet er å nå ein intern applikasjon, er det nyttige spørsmålet når tunnelen blir aktivert, ikkje om han blir ståande. Ei styrt ordning per app kan sende berre trafikken til den applikasjonen gjennom gatewayen, noko som held privat surfing på den vanlege vegen og arbeidstrafikk på den godkjende. Det er ei anna form for kontroll enn ein full tunnel, og det endrar kva indikatoren tyder. Med omfang per app kan ikonet mangla medan arbeidsappen framleis når tenesta si.

Det omfanget er ei politikkgjerd frå den som eig utrullinga, ikkje ei personleg preferanse du kan utleie av åtferda til appen. Innstillingsskjermane til klienten avdekkjer ikkje alltid kva av fleire mekanismar på plattforma som er i kraft, og etikettene overlappar på måtar som villeder.

Dokumentasjonen til Apple skil mellom vilkårsbunden aktivering, val per app og styrt alltid-på-åtferd. Ein tredjepartsklients brytar for automatisk tilkopling høyrer ikkje i seg sjølv til nokon av desse kategoriane, så ei etikett som høyrest likeverdig ut bør ikkje lesast som eit løfte om den styrte eigenskapen.

Den praktiske sjekken er ei førespurnad til ei teneste du veit er intern, gjord med tunnelen medvite slått av. Viss ho lykkast, er ikkje tunnelen den kontrollen du trur, og resten av konfigurasjonen fortener eit nytt blikk før du reknar med han.

Dekka surfing: feilpolitikken er produktet

Viss målet er dekning på ukjende nettverk, er den interessante delen av produktet ikkje tilkoplinga, men fråkoplinga. To klientar som begge koplar til automatisk, kan oppføre seg heilt ulikt i det augneblunken gatewayen avviser eller nettverket blokkerer han.

Ein blokkeringspolitikk gjer dekka trafikk utilgjengeleg så lenge tunnelen ikkje kan etablerast. Det er den sterkaste versjonen av dekning og den mest forstyrrande: eit avbrot blir ditt avbrot, og ein captive portal blir ein vegg du ikkje kjem forbi for å nå sida som ville sleppe deg gjennom.

Ein reservepolitikk held deg på nett ved å la trafikken ta den vanlege vegen. Det er meir brukbart og svakare per definisjon, fordi det nøyaktige augneblunken tunnelen sviktar, er det augneblunken trafikken går ut ukryptert gjennom det nettverket du er på. Trafikken går framleis ut, og han går ut på nettverket du ikkje stolte på. Det er bytet, sagt utan marknadsføringa.

Ingen av dei er feil, og feilen er å oppdage under ei reise kven du kjøpte. Test det heime: slå av evna til tunnelen til å kople til, og sjå deretter om sider lastar. Det eine eksperimentet fortel deg meir enn noka skildring på ei marknadsføringsside hjå ein leverandør.

Det tunnelen ikkje rettar opp

Å rute trafikk gjennom éin operatør gjev den operatøren ein posisjon i tilkoplingvegen din. Det gjer ikkje nettstadene du besøkjer pålitelege, og det erstattar ikkje HTTPS, kontosikkerheit eller omsuta for kva profilar du installerer. Ein tunnel som endar i nettverket til ein leverandør, er ei endring av kven som kan observere kva, ikkje ei fjerning av spørsmålet.

Det same gjeld det lokale nettverket. Ein VPN kan halde trafikken din unna eit hotells tilgangsnettverk, og han kan ikkje hindre det nettverket i å blokkere sjølve tunnelen eller forstyrre namneoppslaget før tunnelen finst.

Yting og batteri høyrer til i same kategori av ærleg observasjon. Det er inga fast straff knytt til indikatoren; ruta gatewayen tar, kvaliteten på tilgangsnettverket, mengda trafikk og kor ofte ein koplar til på nytt flyttar alle talet. Å samanlikne to konfigurasjonar under same bruk er den einaste målinga som betyr noko.

Vel for eininga du faktisk har

På ein personleg telefon vel du åtferda som passar til kravet ditt, og skriv ned feilpolitikken du har godteke. Viss du valde dekning med blokkering, hald ein måte å nå statussida til leverandøren frå ei anna eining; viss du valde reserve, vit at svikten til tunnelen er stille av design.

På ein styrt jobbtelefon er svaret politikken til administratoren, og fråværet av ein pausekontroll er vanlegvis medvite og ikkje ei gløymsle som skal omgåast. Å be om eit unntak gjennom den vanlege kanalen er raskare enn å finne ein omveg som neste profiloppdatering fjernar.

Uansett bør du vurdere avgjerda på nytt når føremålet endrar seg. Ein tunnel konfigurert for ein intern applikasjon passar dårleg til dekning for surfing på heiltid, og ein fulltunnelprofil som blir halden for ein einaste app, flyttar stille mykje trafikk du aldri meinte å overlevere.