VPN per aplicacions a Android: excloure una aplicació no és bloquejar-la
La llista per aplicacions de la pantalla pertany a un sol propietari del túnel, i excloure una aplicació la desvia al voltant d~aquest túnel, no fora de la xarxa. Comenceu aquí.
Dues persones fan la mateixa pregunta i reben respostes incompatibles, perquè són en llocs diferents. Una té oberta la pantalla de configuració de VPN del sistema i edita una llista d’aplicacions. L’altra escriu VpnService.Builder.addDisallowedApplication() en un editor. Totes dues ho anomenen filtre VPN per aplicacions. Només una posseeix el control que descriu, i cap de les dues bloqueja res.
Comenceu per la pantalla que veu l’usuari
Obriu Configuració, trobeu l’entrada de VPN i mireu quina connexió és realment activa. Si el client ofereix una llista per aplicacions, aquesta llista pertany al seu propi túnel. La plataforma no publica una API general amb què una aplicació no relacionada pugui llegir o editar la selecció d’aplicacions d’un altre VPN, així que una segona aplicació no pot arreglar aquesta llista per a l’usuari.
Aquesta és la primera bifurcació del recorregut. Si el VPN instal·lat no té aquesta opció, no hi ha res a envoltar amb codi: la funció no existeix al producte que posseeix el túnel. Si la té, la solució correcta és en aquella pantalla i la fa qui la pot obrir.
Seguiu el paquet fins al túnel
Quan la vostra aplicació construeix un túnel, crea una interfície TUN i declara quin trànsit d’aplicacions hi entra. Les crides de pertinença passen abans que la interfície s’estableixi, i després el conjunt de regles queda fix per a aquella sessió:
val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish() // membership decided here
Aquestes crides només s’apliquen al túnel que la vostra aplicació acaba de crear. No són una política per a tot el dispositiu, no persisteixen per a altres clients i no poden arribar al VPN d’algú altre. Quan una crida de builder falla perquè el paquet no es pot resoldre, la interfície no s’estableix mai, cosa que és un fracàs net i no pas silenciós.
Per què l’exclusió semblava un bloqueig
Una aplicació exclosa es desvia al voltant del vostre túnel cap a la xarxa subjacent. És el contrari de bloquejar-la: el trànsit encara surt del dispositiu, només que fora de la interfície que controleu. Una aplicació d’estil tallafocs fa el revés: admet el trànsit de l’aplicació al seu túnel i després descarta els paquets o es nega a reenviar-los, així que la interfície és la mateixa i la direcció de la política s’inverteix.
La feina darrere d’aquesta inversió no és un indicador de configuració. Llegiu paquets IP del descriptor del túnel, decidiu per flux i o bé els reenvieu per un sòcol protegit o bé els descarteu. Tot el que no gestioneu simplement s’atura, i per això un túnel mig fet sembla una xarxa espatllada i no un filtre que funciona. Si l’objectiu és bloquejar, pressuposteu gestió de paquets, un servei en primer pla i una política escrita per al trànsit que no podeu classificar.
Què es trenca quan el construïu vosaltres
Android generalment permet un sol VPN actiu alhora, així que el vostre túnel de filtratge i un túnel de privadesa competeixen pel mateix lloc, tret que els productes admetin encadenament. El VPN sempre actiu amb bloqueig de connexions canvia el mode de fallada d’una manera que aquí importa: el trànsit que no pot entrar al túnel es descarta en lloc d’enviar-se directament, que és el que vol un disseny contra fuites i el que una sessió de depuració poques vegades espera.
La visibilitat dels paquets és la segona trampa. Resoldre el nom de paquet d’una aplicació pot fallar amb NameNotFoundException, i a les versions més noves d’Android el conjunt de paquets que veieu depèn de les consultes que hàgiu declarat. Gestioneu l’excepció en lloc de suposar que tot nom es resol, i torneu a llegir la llista quan s’instal·len o es treuen aplicacions en lloc d’emmagatzemar-la per sempre.
Els dispositius gestionats afegeixen un tercer propietari. Una política de mobilitat empresarial pot fixar un VPN per aplicacions o un perfil sempre actiu, i una aplicació corrent no ho pot anul·lar. Comproveu si el dispositiu està gestionat abans de depurar el vostre codi, perquè en aquest cas la llista que intenteu canviar potser no la pot editar ningú que tingui el telèfon.
Proveu-ho amb una aplicació que controleu
No proveu amb l’aplicació que intenteu filtrar. Feu servir una segona aplicació el comportament de xarxa de la qual pugueu observar, i comproveu si el seu trànsit surt pel vostre túnel mentre que el de l’objectiu no. Si totes dues queden a dins, la política funciona i l’objectiu està exclòs; si no en surt cap, el túnel mateix és incorrecte i la llista d’aplicacions no és el problema.
Després decidiu quina de les tres coses esteu construint de debò. Un túnel per aplicacions és l’API de builder, amb la llista com a part del vostre perfil. Un tallafocs de dispositiu és gestió de paquets més un cicle de vida que pugueu defensar. Canviar el VPN d’algú altre no és cap camí suportat, i la resposta honesta allà és que la configuració pertany a aquell producte.