Dónde debe vivir una regla de cortafuegos de Android cuando el VPN está activo

Tiene una sola frase de política: esta aplicación puede llegar al servicio de trabajo y a nada más. La siguiente pregunta parece una elección de producto, pero es una pregunta de lugar, porque cada punto de aplicación posible ve una parte distinta del tráfico del teléfono. La puerta de enlace solo ve lo que entra en el túnel. El filtro del lado del teléfono solo ve lo que se le permite observar. Pasar una solicitud por ambos hace obvia la respuesta.

Empiece por la frase, no por el producto

Descomponga el requisito antes de elegir nada. Eso significa el paquete y el perfil en el que se ejecuta, porque una aplicación del perfil de trabajo es un usuario distinto de la misma aplicación en el perfil personal. Significa el destino: host, puerto y protocolo, no un nombre de servicio. Significa la ruta DNS que resuelve ese nombre, y significa qué debe ocurrir cuando el túnel no está disponible.

Escrita, la política del ejemplo tiene cuatro líneas: la aplicación de trabajo puede llegar al servicio de trabajo; no puede llegar a nada más; las demás aplicaciones quedan igual; sin túnel, se deniega la aplicación de trabajo en vez de caer a una ruta directa. Cada línea tiene un dueño, y no todas son el mismo dueño.

Paso 1: qué puede aplicar el propio teléfono

Un cortafuegos de Android sin root es un VpnService que captura el tráfico localmente, incluso cuando no hay ningún túnel remoto detrás. Android permite un solo servicio VPN activo por perfil de usuario, así que una segunda aplicación de cortafuegos no se encadena detrás de la primera. La sustituye, y la interfaz que filtraba la primera aplicación desaparece.

Por eso instalar un cortafuegos junto a un cliente VPN rara vez produce la combinación que la gente espera. Si el cortafuegos arranca y el VPN se desconecta, no se combinó nada; los dos intercambiaron su lugar. Sustituir una interfaz no es cooperar, y el síntoma es un túnel que cae una y otra vez cada vez que se abre la otra aplicación.

Existen disposiciones compatibles: filtrado integrado en el cliente VPN que ya usa, controles de plataforma gestionados mediante un controlador de políticas del dispositivo o un perfil de trabajo, o una arquitectura que el fabricante documente. Cualquier otra cosa es un experimento que hay que volver a verificar tras cada actualización de la aplicación.

Paso 2: qué puede aplicar la puerta de enlace

Una vez que el tráfico se descifra en el extremo remoto, la puerta de enlace puede restringir los paquetes reenviados a direcciones, servicios o identidades VPN autenticadas aprobadas. Eso es aplicación real para todo lo que sale por ella, y es el lugar correcto para limitar el acceso a subredes privadas.

Lo que no recibe es la identidad de la aplicación del teléfono unida a cada paquete IP ordinario. Varias aplicaciones que comparten una dirección de túnel son un solo sujeto para la puerta de enlace, salvo que el diseño les dé direcciones separadas o identidades autenticadas separadas. Por eso una regla por usuario en la puerta de enlace no es una regla por aplicación en el teléfono, diga lo que diga la consola de administración.

Paso 3: enumere lo que nunca llega

Una aplicación excluida del VPN que contacta un dispositivo cercano nunca llega a la puerta de enlace, así que un cortafuegos de salida no puede denegar un paquete que nunca recibe. Lo mismo vale para una ruta directa no deseada durante una caída y para la exposición entrante en la red de acceso local. Son límites locales por definición.

Lo contrario también es cierto: una regla local que permite una conexión no concede acceso a través de la ACL de red privada de la puerta de enlace. Una solicitud puede estar sujeta a ambos límites, y satisfacer uno no dice nada del otro.

Paso 4: asigne cada regla a una ruta

Ponga la decisión en una tabla antes de configurar nada, porque las celdas vacías son donde fallan los diseños.

La forma que funciona son dos límites con dos trabajos. Un límite local consciente de las aplicaciones gobierna el comportamiento del teléfono, incluida la caída directa, y un límite de puerta de enlace gobierna los recursos remotos. El lado de la puerta de enlace puede permitir el servicio de trabajo y denegar cualquier otra subred privada, mientras la política del teléfono decide por su cuenta sobre una ruta directa que la aplicación podría tomar de otro modo.

Paso 5: mantenga vivo el transporte y luego verifique

Sea cual sea la política local que elija, debe permitir el transporte que establece y mantiene el VPN. Bloquear ese transporte deja el teléfono sin túnel y sin política, lo que no aplica nada de forma coherente y es difícil de diagnosticar, porque la aplicación simplemente no tiene red.

Luego verifique cada línea de la frase original en lugar de la impresión general: la aplicación de trabajo llega al servicio de trabajo, la misma aplicación es denegada en otro destino, una aplicación que no es de trabajo se comporta como antes, y con el túnel detenido la aplicación de trabajo no cae a una conexión directa. Compruebe la ruta DNS por separado, porque un DNS privado o un resolutor cifrado pueden saltarse un filtro que solo inspecciona direcciones.

Si uno de esos pasos no puede satisfacerse en el teléfono, el requisito es una cuestión de arquitectura y no un ajuste de cortafuegos. Repartir la política entre un dispositivo que usted controla y una puerta de enlace que usted controla suele ser la respuesta honesta, y la documentación de conectividad VPN de Android es el lugar donde confirmar qué permitirá y qué no permitirá la plataforma a un solo servicio.