Android: Always-On kaj blokado sen VPN — elektu la ĝustan paron

Always-On rekonektas kaj blokado sen VPN estas du agordoj, kaj ŝalti la unuan ne ŝaltas la duan. La ĝusta paro dependas de tri kondiĉoj: kiu posedas la aparaton, kiujn apojn la tunelo kovras kaj kio okazas antaŭ la malŝloso.

Du ŝaltiloj kun malsamaj promesoj

Always-On promesas daŭrecon kaj restartigas la servon post falo; blokado promesas enfermon: sen tunelo la kovrita trafiko havas neniun vojon eksteren.

La tria faktoro estas la amplekso laŭ apo, kiu apartenas al la kliento aŭ al la administra politiko, ne al la sistemaj ŝaltiloj; bloki sen decidi la amplekson donas politikon pli larĝan aŭ pli mallarĝan ol necese.

Unua decido: administrata aparato aŭ uzanta agordo?

Sur administrata aparato la politiko regas Always-On kaj ŝlosadon, kaj la loka ŝaltilo povas manki; ŝanĝu la postulon en la politiko, ne en la aparato.

Sur persona aparato la uzanto decidas, ĉu akcepti senreton kiam la tunelo ne haveblas; blokado estas interŝanĝo de havebleco, kaj mankanta ŝaltilo ne pravigas radikigon.

La amplekso estas laŭ profilo, ne laŭ aparato: Android permesas unu aktivan VPN por uzantprofilo.

Blokado en la labora profilo diras nenion pri la persona flanko, kaj testi unu kuntekston ne validigas la alian.

Dua decido: ĉio blokita aŭ kelkaj apoj esceptitaj?

Esceptoj laŭ apo en bloka reĝimo ofte kompreniĝas malĝuste: laŭ Android esceptitaj apoj povas perdi la konekton anstataŭ silente uzi la normalan reton, do escepto ne estas permeso al la interreto.

Decidu konscie: bloku la tutan kovritan trafikon kaj akceptu, ke esceptitaj apoj restas mallumaj, aŭ malŝaltu blokadon kaj akceptu rezervan vojon; se unu apo devas ĉiam havi konekton, blokado estas la malĝusta ilo.

Tria decido: kio okazas antaŭ malŝloso kaj ĉe portalo?

Ĉe plej multaj klientoj la tunelo ne staras ĝis la uzanto malŝlosas la aparaton, do la unuaj momentoj post starto estas breĉo, ne paneo; konfirmu tion por la kliento, kiun vi lanĉas.

Captive-portaloj estas la alia rando: hotelo aŭ flughavena reto bezonas neaŭtentikigitan retumilan sesion kaj malmola blokado povas malebligi saluton; la subtenata respondo estas aprobita riparebla fluo kun ellaso, maksimuma daŭro, kiu rajtas doni ĝin, kaj kontrolo, ke la plenumo mem revenas.

La dokumentaro pri Android VPN-klientoj priskribas Always-On, blokadon, esceptojn laŭ apo kaj la regulon de unu VPN por profilo; legu ĝin antaŭ ol desegni laŭ memoro.

Testu la senretan staton, poste skribu la akceptan linion

Uzu senriskan trafikon kaj la subtenatan panean teston: normala konekto, perdo de la tunelo, restarigo kaj restarto antaŭ malŝloso, kaj notu, ĉu la apo blokiĝis kiel celite.

Kontrolu la rimedon kaj la solvilon, ne la ikonon, kaj testu aparte aparaton malantaŭ la telefono, ĉar la politiko de la telefono ne starigas plusendadon por hotspot-klientoj.

La akcepta linio estas konkreta kaj testebla: la celita apo en la celita profilo atingas la aprobitan tunelon kaj restas blokita, kiam ĝi ne povas. Antaŭ ol vi subskribos:

• Always-On kaj blokado estas agorditaj tie, kie la platformo subtenas ilin, kaj la posedanto de ĉiu agordo estas konata.
• La amplekso de apoj estas intenca, kaj vi konfirmis, kio okazas al esceptitaj apoj en bloka reĝimo.
• La breĉo antaŭ malŝloso kaj la captive-portala fluo estas deciditaj, ne malkovritaj.
• La panea testo okazis sur la aparata klaso, kiun vi efektive lanĉas.