Per què el trànsit de depuració sense fil no demostra una fuita de VPN
Una sessió ADB aparellada per Wi-Fi demostra una relació de depuració, no una ruta de sortida a internet. Això és el que cobreix realment aquella observació.
Vau activar la depuració sense fil, vau connectar un portàtil i la sessió va continuar funcionant mentre la VPN era activa. Sembla que alguna cosa s'ha escapat del túnel. Gairebé amb tota seguretat no. Una sessió de depuració i la petició d'una aplicació a un lloc web són relacions de xarxa diferents, i només una d'elles ha de creuar el túnel.
M'he trobat amb aquesta lectura errònia dues vegades: una amb el telèfon i el portàtil a la mateixa Wi-Fi, i una altra després d'un reinici, quan l'aparellament va sobreviure. En tots dos casos la VPN feia exactament allò per a què estava configurada.
Anomeneu l'observació abans d'anomenar el defecte
Tres esdeveniments poden precedir una afirmació de fuita, i no són intercanviables. Una eina pot descobrir un servei, el dispositiu pot aprovar una estació de treball, o una sessió autoritzada pot portar realment ordres i bytes. Anoteu quin heu vist, perquè cadascun demostra menys del que la gent suposa.
El descobriment sol ser mDNS o un escaneig de ports. L'aparellament és una decisió d'enregistrament presa al telèfon, confirmada amb un codi que l'usuari escriu. Una sessió activa significa que el trànsit s'ha mogut entre dos extrems aparellats. Res d'això no descriu on va la petició HTTPS d'una aplicació.
Manteniu la destinació, la interfície, la família d'adreces, la marca de temps i el perfil d'usuari adjunts a l'esdeveniment. Sense aquests detalls, l'observació no es pot comparar amb la política de xarxa local prevista ni amb la versió de la VPN que s'executava aleshores.
Per què els dos camins no es troben mai
La depuració sense fil és una connexió entrant al dispositiu. adbd escolta en un port lligat a la interfície Wi-Fi, i l'estació de treball s'hi connecta després de l'aparellament. La direcció importa: el vostre portàtil arriba fins al telèfon, no a l'inrevés. Això és el contrari d'una fuita de sortida.
El trànsit d'internet d'una aplicació surt per la interfície de túnel que instal·la VpnService, aparellada per UID i regles d'encaminament. adbd és un dimoni del sistema que s'executa com a usuari shell, no una aplicació dins d'aquell conjunt d'encaminament. Es queda a l'enllaç Wi-Fi subjacent fins i tot quan cada aplicació està fixada al túnel.
El mode de bloqueig imposa el túnel per a les aplicacions cobertes. No converteix un sòcol d'escolta en una ruta de sortida.
Per això una sessió ADB funcional i un interruptor de seguretat funcional coexisteixen sense contradicció. Per demostrar una fuita, heu d'observar la direcció que hauria d'estar bloquejada.
Com és realment una prova de sortida
Proveu l'aplicació coberta, no el canal de depuració. Establiu la condició de fallada deliberadament, després feu una petició nova i anoteu què ha passat.
- Confirmeu que la VPN és l'únic camí: activeu la VPN sempre activa amb el bloqueig de connexions sense VPN.
- Atureu la VPN de la manera admesa i confirmeu que l'aplicació informa que no hi ha connectivitat.
- Feu una petició inofensiva des d'aquesta aplicació i anoteu si falla o té èxit.
- Repetiu amb la depuració sense fil activada i després desactivada, per aïllar la variable.
Una petició bloquejada en aquestes condicions és una prova. Una sessió ADB reeixida no ho és, i un sol ping des d'una aplicació de terminal tampoc.
Si la petició sí que té èxit mentre el bloqueig està activat, captureu l'UID de l'aplicació i la seva autorització de VPN, la xarxa activa i la versió del client. Aquesta combinació és una troballa real.
L'aparellament sobreviu a la sessió
L'aparellament és un estat persistent, no una encaixada de mans que pugueu oblidar després de la prova amb cable. La documentació de depuració d'Android descriu el flux de treball sense fil i assenyala que la relació dura fins que s'oblida explícitament o es revoquen les autoritzacions.
Comproveu què continua autoritzat abans de culpar el túnel. Obriu Depuració sense fil, mireu Dispositius aparellats i oblideu qualsevol cosa que ja no reconegueu. Executeu adb devices des de l'estació de treball per veure quines entrades encara responen, i adb disconnect per descartar-ne una d'obsoleta. Desactivar la depuració sense fil tanca del tot el port d'escolta.
En una xarxa compartida o no fiable, deixeu-la desactivada. Una autorització persistent en una xarxa que no controleu és un problema més gran que una suposada elusió del TUN.
Abans de presentar aquest error
Un informe útil anomena el límit exacte que ha fallat. Incloeu el model del dispositiu i la versió d'Android, el client VPN i la versió, si el bloqueig estava activat, el paquet de l'aplicació i l'UID, i la xarxa on era el telèfon. Afegiu l'ordre o la petició que va produir l'observació, més l'hora en què va passar. Sense això, ningú no pot reproduir el límit que assegureu que està trencat.
No desactiveu l'aplicació forçosa ni exposeu la depuració en una xarxa no fiable per fer que la prova sembli més dramàtica. Això canvia el sistema que mesureu i deixa proves que ningú no pot repetir.
Si la vostra única prova és que l'ADB es va connectar mentre la VPN era activa, heu mesurat el camí equivocat. Torneu a fer primer la prova a nivell d'aplicació; la resposta normalment arriba allà.