Android Always-on og blokkering utan VPN: vel rett kombinasjon

Always-on som koplar til på nytt og blokkering utan VPN er to innstillingar, og å slå på den første slår ikkje på den andre. Paret du treng, avheng av tre vilkår: kven som eig eininga, kva appane tunnelen dekkjer, og kva som skjer før telefonen er låst opp. Får du eitt av desse feil, ser telefonen verna ut medan ein app stille tek det vanlege nettet, eller han ser øydelagd ut medan han gjer nøyaktig det retningslinja bad om.

To brytarar som gjev ulike lovnader

Always-on er ein lovnad om varigheit. Systemet held den valde VPN-tenesta i gang gjennom livssyklushendingane ho støttar, og startar ho på nytt når ho fell. Blokkering er ein lovnad om innestenging: medan tunnelen ikkje er brukbar, har dekt trafikk ingen veg utanom han. Ein tenar som er nede, ei passordoppmoding ingen kan svare på, eller ein klient som har krasja, lèt alle ei blokkerande eining med vilje vera fråkopla.

Ein tredje faktor ligg oppå båe: klienten sitt omfang per app. Android støttar VPN-konfigurasjonar per app, og omfanget høyrer til klienten eller styringsretningslinja, ikkje til dei to systembrytarane. Å vedta blokkering utan å avgjere omfanget gjev ei retningslinje som er anten vidare eller smalare enn kravet.

Avgjerd éin: styrt eining eller ei brukarinnstilling?

På ei styrt eining kan ein styringsagent for eininga eige always-on og lockdown for ein profil, og den lokale brytaren kan mangle, vera gråa ut eller nullstilla ved neste oppdatering av retningslinja. Det er retningslinja som verkar, ikkje ein feil å rute rundt. Sjekk retningslinja før du leitar etter ein skjult meny, og endre kravet i retningslinja i staden for på endepunktet.

På ei personleg eining er det brukaren som vel, og det ærlege spørsmålet er om brukaren godtek å vera fråkopla når tunnelen ikkje er tilgjengeleg. Blokkering er eit kompromiss med tilgjenge, og det bør skildrast slik. Ein fråverande brytar er heller ikkje ei oppfordring til å roote telefonen eller fjerne einingstyringa; dersom plattforma ikkje tilbyr kontrollen, må kravet endrast.

Omfang per profil, ikkje per eining. Personlege og arbeidsrelaterte profilar er separate kontekstar, og Android tillet éin aktiv VPN per brukarprofil.

Ei blokkering i arbeidsprofilen seier ingenting om den personlege sida, og testing av éin kontekst validerer ikkje den andre.

Avgjerd to: alt blokkert eller nokre appar utelatne?

Utelatingar per app under blokkeringsmodus er den delen folk får bakvendt. I Androids dokumenterte åtferd kan appar som er utelatne frå ein VPN per app miste tilkoplinga i blokkeringsmodus i staden for stille å bruke det vanlege nettet. Ei utelating er altså ikkje løyve for den appen til å nå internett, og ei retningslinje bygd på den føresetnaden vil gje uforklarlege feil.

Vel med vilje: blokker all dekt trafikk og godta at utelatne appar blir mørke, eller la blokkeringa vera av og godta at reserveveg er mogleg. Dersom kravet er at éin app alltid skal ha tilkopling, er blokkeringsmodus feil instrument for den eininga, og ingen mengd justering per app får dei to krava til å sameksistere.

Avgjerd tre: kva skjer før opplåsing og ved ein portal?

Hjå dei fleste klientar er ikkje tunnelen oppe før brukaren har låst opp eininga, så handsama dei første augneblinkane etter oppstart som eit hol og ikkje som ein feil; stadfest åtferda for klienten du ruller ut før du godkjenner. Det same gjeld opplåsing med legitimasjon, som kan vera nettopp det ei blokkeringsretningslinje hindrar. Avgjer om holet er akseptabelt før utrulling, og test det i staden for å oppdage det ute i felt.

Captive portals er den andre kanten. Eit hotell- eller flyplassnett treng ei uautentisert nettlesarøkt før noko anna verkar, og ei hard blokkering kan gjera pålogging umogleg. Det støtta svaret er ein godkjend gjenopprettingsflyt, anten det er eit mellombels styrt unntak eller ein dokumentert prosedyre. Det unntaket bør namngje utløysaren (ein portal-SSID eller eit nett), maksimal varigheit, kven som kan gje det, og kontrollen som syner at handhevinga kjem tilbake av seg sjølv etterpå; å slå av handhevinga som ei uforklart omvegsløysing er ikkje det unntaket.

Plattformdokumentasjonen om Android VPN-klientar dekkjer åtferda for always-on og blokkering, utelatingar per app og regelen om éin VPN per profil. Les han før du designar rundt ei åtferd du hugsar frå ein eldre versjon, for klienten du ruller ut kan alt avvike.

Test den fråkopla tilstanden, og skriv så godtakingslinja

Bruk harmlaus trafikk og klienten sin støtta feiltest. Sjekk den vanlege tilkoplinga, tapet av tunnelen, gjenopprettinga og tilfellet med omstart før opplåsing. For kvar av dei, registrer om den dekte appen kopla til, vart blokkert som tenkt, eller uventa tok ein annan veg.

Stadfest ressursen og resolvaren, ikkje statusikonet. Eit VPN-grensesnitt kan finnast medan den nyttige vegen er ubrukeleg, og eit ikon som seier tilkopla er ikkje prov på at appen nådde noko. Test ei tethering-eining separat òg: retningslinja på ein telefon etablerer ikkje videresending for hotspot-klientar, fordi tethering er sin eigen veg med si eiga åtferd.

Godtakingslinja er spesifikk og testbar: den tiltenkte appen i den tiltenkte profilen når den godkjende tunnelen, og held seg i den kravde blokkerte tilstanden når han ikkje kan. Før du godkjenner ho:

• Always-on og blokkering er båe konfigurerte der plattforma støttar dei, og eigaren av kvar innstilling er kjend.
• Appomfanget er med vilje valt, og du har stadfesta kva som skjer med utelatne appar i blokkeringsmodus.
• Holet før opplåsing og captive-portal-flyten er avgjorde, ikkje oppdaga.
• Feiltesten vart køyrd på den einingstypen du faktisk ruller ut.