El túnel dividido para clientes de punto de acceso no es una exclusión por aplicación

Dos requisitos que suenan equivalentes no lo son: «excluye esta aplicación de la VPN» y «envía este único destino fuera de la VPN para el portátil de mi punto de acceso». El primero cambia cómo un socket del teléfono elige una red. El segundo tiene que cambiar una decisión de reenvío para un paquete que llegó de otro dispositivo después de que el teléfono ya lo aceptó. Confundir los dos es lo que hace que un cliente de punto de acceso acabe con una excepción que solo se aplicaba al navegador del propio teléfono.

Dos subsistemas son dueños de las dos preguntas

Android mantiene separadas la red de las aplicaciones y el tethering. La pila de conectividad asigna los sockets de las aplicaciones a una red, y una aplicación VPN decide cuáles de sus propios sockets entran en el túnel. Los paquetes reenviados de un cliente conectado los maneja el subsistema de tethering, que pide a netd rutas, reglas de política y traducción en la interfaz descendente.

La exclusión por aplicación se evalúa cuando una aplicación abre un socket. Un paquete reenviado nunca llega a esa comprobación, porque no se originó en un socket de aplicación de este dispositivo. Esa es toda la razón por la que los dos ajustes no pueden sustituirse entre sí, y no es un fallo en ninguno de los dos.

Qué cambia realmente la exclusión por aplicación

Un constructor de VpnService puede nombrar los paquetes que quedan fuera del túnel con addDisallowedApplication, o nombrar los únicos paquetes permitidos dentro con addAllowedApplication. Esas aplicaciones abren entonces sockets en la red subyacente mientras la VPN sigue siendo dueña de la ruta predeterminada para todo lo demás.

El alcance es preciso: los sockets propios del paquete, en este dispositivo, mientras el túnel esté activo. No dice nada sobre el tráfico reenviado, nada sobre un segundo dispositivo y nada sobre los paquetes que el sistema envía en nombre del tethering.

Tampoco es un control de destino. Excluir un navegador excluye cada dirección que ese navegador alcanza, incluida la que querías mantener dentro del túnel. Cuando el requisito nombra un destino en lugar de una aplicación, el selector de aplicaciones es la herramienta equivocada por construcción.

Cómo ve el teléfono un paquete conectado

El paquete del cliente llega a la interfaz del punto de acceso con una dirección de origen privada asignada por el teléfono, digamos 192.168.43.20, y un destino público. Para reenviarlo, el teléfono necesita una ruta hacia un enlace ascendente y una regla de traducción para que las respuestas encuentren el camino de vuelta, porque la dirección privada del cliente no significa nada en la red celular.

Android lo expresa con reglas de política que seleccionan una tabla de enrutamiento, y netd reconstruye las tablas y reglas correspondientes cuando cambian las redes y las VPN. Un número de tabla, una prioridad de regla o un nombre de interfaz copiados de una publicación de foro, o del mismo modelo en una versión anterior, no establecen una propiedad duradera. Esa reconstrucción es también la razón por la que una regla escrita a mano puede funcionar una hora y detenerse tras la siguiente reconexión.

La política que una excepción de punto de acceso necesita de verdad

Escriba la decisión como origen, destino y ruta prevista antes de tocar ninguna regla. La forma mínima para un destino aprobado es esta:

Ambos sentidos tienen que estar completos. La rama directa necesita una ruta utilizable por el enlace ascendente celular que resulte ser el actual; la rama VPN necesita la ruta del túnel más permiso para reenviar. Cualquier traducción de origen debe coincidir con la salida que eligió, porque el NAT aplicado en una interfaz de túnel presenta la dirección del túnel y no la celular, y entonces el camino de vuelta no concuerda con el camino de ida.

Las respuestas deben llegar al mismo cliente descendente mediante estado seguido o una ruta explícita, y un contador de paquetes salientes no demuestra nada de eso. Mantenga también el transporte exterior propio de la VPN fuera del alcance de la excepción, o los paquetes portadores del túnel heredan una política escrita para una solicitud web de un cliente.

Una dirección capturada no es un destino

Una sola dirección IPv4 leída de un navegador es una instantánea. Los servicios grandes responden desde anycast o desde un conjunto rotatorio de direcciones de borde, muchos son de doble pila, y un flujo de inicio de sesión puede tocar hosts de autenticación y telemetría que la página nunca muestra. Una excepción construida alrededor de la dirección que vio por casualidad se rompe la próxima vez que el servicio reequilibra.

Use las direcciones documentadas por el propietario del servicio, o un rango que publique, y cuente con ambas familias de direcciones. Si el requisito no puede expresarse como un conjunto estable, probablemente sea una cuestión de política para el servicio y no un truco de enrutamiento en un teléfono.

Verifique desde el lado descendente

Tres comprobaciones, en este orden: el servicio seleccionado desde el portátil, un destino corriente que debe quedarse dentro de la VPN y una aplicación del teléfono que debe quedar sin afectación. Luego repita tras una reconexión y tras un cambio de enlace ascendente, porque es entonces cuando se reconstruyen las tablas de política.

Si la implementación de compartición del teléfono no puede mantener ese contrato durante una reconexión, mueva la política selectiva a un enrutador descendente compatible en lugar de acumular reglas root en el terminal. Un enrutador puede expresar la coincidencia de origen y destino con un propietario estable, y la documentación del módulo de tethering es la referencia correcta para lo que el teléfono hace en realidad.