Android: Always-On i bloqueig sense VPN, trieu la parella correcta

Always-On i el bloqueig sense VPN són dos ajustos i activar el primer no activa el segon. La parella depèn de qui posseeix el dispositiu, de quines apps cobreix el túnel i de què passa abans de desbloquejar-lo.

Dos interruptors amb promeses diferents

Always-On promet persistència i reinicia el servei quan cau; el bloqueig promet confinament: sense túnel, el trànsit cobert no té camí enfora.

El tercer factor és l abast per aplicació, que pertany al client o a la política de gestió, no als interruptors del sistema; bloquejar sense decidir l abast dona una política més ampla o més estreta del necessari.

Decisió primera: dispositiu gestionat o ajust d usuari?

En un dispositiu gestionat la política controla Always-On i el bloqueig, i l interruptor local pot faltar; canvieu el requisit a la política, no a l equip.

En un dispositiu personal l usuari decideix si accepta quedar-se sense xarxa quan el túnel no hi és; el bloqueig és un intercanvi de disponibilitat i un interruptor absent no justifica fer root.

L abast és per perfil, no per dispositiu: Android permet un VPN actiu per perfil d usuari.

Un bloqueig al perfil de feina no diu res del perfil personal i provar un context no valida l altre.

Decisió segona: tot bloquejat o algunes apps excloses?

Les exclusions per aplicació en mode bloqueig s entenen al revés: segons Android les apps excloses poden perdre la connexió en lloc d usar silenciosament la xarxa normal, així que excloure no és permís per sortir a internet.

Trieu conscientment: bloquegeu tot el trànsit cobert i accepteu que les apps excloses quedin a les fosques, o desactiveu el bloqueig i accepteu l alternativa; si una app ha de tenir sempre connexió, el bloqueig és l instrument equivocat.

Decisió tercera: què passa abans de desbloquejar i en un portal?

En la majoria de clients el túnel no puja fins que el dispositiu es desbloqueja, així que els primers instants són un buit, no una fallada; confirmeu-ho per al client que desplegueu.

Els portals captius són l altre extrem: una xarxa d hotel o aeroport necessita una sessió de navegador sense autenticar i un bloqueig dur pot impedir l accés; la resposta admesa és un flux de recuperació aprovat amb el disparador, la durada màxima, qui el concedeix i la comprovació que el control torna sol.

La documentació dels clients VPN d Android cobreix Always-On, el bloqueig, les exclusions per app i la regla d un VPN per perfil; llegiu-la abans de dissenyar de memòria.

Proveu l estat sense xarxa i després escriviu la línia d acceptació

Feu servir trànsit innociu i la prova de fallada admesa: connexió normal, pèrdua del túnel, recuperació i reinici abans de desbloquejar, anotant si l app va quedar bloquejada com calia.

Verifiqueu el recurs i el resolutor, no la icona, i proveu a part un dispositiu en tethering, perquè la política del telèfon no estableix reenviament per als clients del punt d accés.

La línia d acceptació és concreta i provable: l app prevista al perfil previst arriba al túnel aprovat i resta bloquejada quan no pot. Abans de signar-la:

• Always-On i el bloqueig estan configurats on la plataforma els admet i se sap qui és l amo de cada ajust.
• L abast de les apps és deliberat i heu confirmat què passa amb les apps excloses en mode bloqueig.
• El buit abans de desbloquejar i el flux del portal captiu estan decidits, no descoberts.
• La prova de fallada s ha fet a la classe de dispositiu que realment desplegueu.