Always-On taastab ühendust ja blokeerimine ilma VPN-ita on kaks seadet, ning esimese sisselülitamine ei lülita teist sisse. Õige paar sõltub sellest, kellele seade kuulub, milliseid rakendusi tunnel katab ja mis toimub enne avamist.

Kaks lülitit erinevate lubadustega

Always-On lubab püsivust ja taaskäivitab teenuse selle katkedes; blokeerimine lubab isoleerimist: ilma tunnelita ei ole kaetud liiklusel väljapääsu.

Kolmas tegur on rakendusepõhine ulatus, mis kuulub kliendile või halduspoliitikale, mitte süsteemi kahele lülitile; blokeerimine ilma ulatuse otsuseta annab poliitika, mis on nõudest laiem või kitsam.

Otsus esimene: hallatav seade või kasutaja säte?

Hallataval seadmel juhib poliitika Always-On-i ja lukustust ning kohalik lüliti võib puududa; muutke nõuet poliitikas, mitte seadmes.

Isiklikul seadmel otsustab kasutaja, kas ta nõustub võrguühenduseta olema, kui tunnelit pole; blokeerimine on kättesaadavuse vahetus ja puuduv lüliti ei õigusta root-imist.

Ulatus on profiilipõhine, mitte seadmeipõhine: Android lubab ühe aktiivse VPN-i kasutajaprofiili kohta.

Tööprofiili blokeering ei ütle isikliku poole kohta midagi ja ühe konteksti testimine ei kinnita teist.

Otsus teine: kas blokeerida kõik või jätta mõned rakendused välja?

Rakendusepõhiseid erandeid blokeerimisrežiimis mõistetakse sageli vastupidi: Androidi järgi võivad erandina välja jäetud rakendused ühenduse kaotada, mitte vaikselt tavalist võrku kasutada, seega erand ei ole internetiluba.

Otsustage teadlikult: blokeerige kogu kaetud liiklus ja leppige, et erandina välja jäetud rakendused jäävad pimedaks, või lülitage blokeerimine välja ja leppige varuteega; kui üks rakendus peab alati ühendatud olema, on blokeerimine vale tööriist.

Otsus kolmas: mis toimub enne avamist ja portaalis?

Enamikus klientides ei ole tunnel üleval enne, kui kasutaja seadme avab, seega on esimesed hetked pärast käivitust lünk, mitte rike; kinnitage see oma kliendi jaoks.

Captive-portaalid on teine serv: hotelli- või lennujaamavõrk vajab autentimata brauseriseanssi ja karm blokeering võib sisselogimise võimatuks teha; toetatud vastus on kinnitatud taastetoiming, millel on päästik, maksimaalne kestus, kes selle annab, ja kontroll, et jõustamine taastub ise.

Androidi VPN-klientide dokumentatsioon katab Always-On-i ja blokeerimise, rakendusepõhised erandid ning reegli ühe VPN-i kohta profiili kohta; lugege seda enne mälupõhist projekteerimist.

Katsetage võrguühenduseta olekut ja kirjutage siis vastuvõtureal

Kasutage kahjutut liiklust ja kliendi toetatud rikketesti: tavaline ühendus, tunneli kadu, taastumine ja taaskäivitus enne avamist, märkides, kas rakendus blokeeriti nii nagu ette nähtud.

Kontrollige ressurssi ja resolverit, mitte ikooni, ning katsetage telefonitagust seadet eraldi, sest telefoni poliitika ei loo hotspot-klientidele edastust.

Vastuvõtureal on konkreetne ja testitav: kavandatud rakendus kavandatud profiilis jõuab kinnitatud tunnelini ja jääb nõutud blokeeritud olekusse, kui ei jõua. Enne allkirjastamist:

  • Always-On ja blokeerimine on seadistatud seal, kus platvorm neid toetab, ja iga sätte omanik on teada.
  • Rakenduste ulatus on teadlik ja olete kinnitanud, mis juhtub erandina välja jäetud rakendustega blokeerimisrežiimis.
  • Enne avamist olev lünk ja captive-portaali toiming on otsustatud, mitte avastatud.
  • Rikketest tehti seadmeklassil, mida te tegelikult juurutate.

Seotud artiklid