Redirección de puertos en el punto de acceso Android: las tres entradas

Activó el punto de acceso, conectó la VPN, abrió un puerto en la aplicación y el otro dispositivo sigue sin poder conectarse. La pieza que falta casi nunca es el puerto en sí, sino qué máquina posee el socket que escucha y a qué dirección debe llegar el otro dispositivo. Voy del teléfono hacia fuera, porque la pantalla que tiene delante le dice cuál de las tres entradas está probando.

Empiece donde el servicio se ejecuta de verdad

Abra la aplicación que debe aceptar la conexión y lea su página de estado. Si dice que escucha, anote la dirección a la que se vinculó, porque ese solo detalle decide la mayoría de los casos de abajo. Una aplicación vinculada a 127.0.0.1 solo es alcanzable desde el teléfono, y no lo cambiarán ni el cliente del punto de acceso, ni la traducción del operador, ni la salida de la VPN.

Después confirme qué dispositivo ejecuta el servicio. Si es el teléfono, el socket pertenece a esa aplicación; si es un portátil detrás del punto de acceso, el oyente y su cortafuegos pertenecen al portátil y el teléfono solo reenvía paquetes. Son diseños distintos, y mezclarlos es la razón de que un puerto abierto en un sitio no haga nada en el otro.

En una compilación depurable, adb shell lista los sockets mediante /proc/net/tcp, pero para la mayoría el estado propio de la aplicación es la fuente honesta.

Primera entrada: otro dispositivo en el punto de acceso

Es el caso local y el más sencillo. El otro dispositivo llega al teléfono en la dirección que ve como su puerta de enlace, en el puerto donde escucha la aplicación, y nada fuera del punto de acceso interviene. No hace falta traducción del operador, porque el tráfico nunca sale del segmento local.

Dos cosas lo rompen: que la aplicación esté vinculada al loopback, o que la política de cliente del teléfono no permita la conexión local. Pruebe con el protocolo propio de la aplicación en lugar de un TCP desnudo, porque un oyente que acepta y luego rechaza se ve de lejos como un puerto cerrado.

Si el servicio corre en un portátil conectado, la dirección del punto de acceso del teléfono no es el destino en absoluto; necesita la dirección del portátil en la interfaz del punto de acceso y un oyente allí.

Segunda entrada: la ruta del operador

Llegar al teléfono desde la red móvil es otro problema, y casi siempre no funciona para IPv4. Los operadores colocan los terminales detrás de una traducción compartida, y por eso RFC 6598 reserva un rango de direcciones compartido justo para ese arreglo. Una conexión entrante no solicitada no tiene traducción por la que llegar, y ninguna configuración local crea una, porque el traductor no es su dispositivo.

El acceso root tampoco lo cambia; da control de la pila del teléfono, no del traductor del operador. Donde el operador ofrece un prefijo IPv6 público puede existir una ruta entrante, pero el oyente y el cortafuegos siguen necesitando una autorización deliberada.

Tercera entrada: la salida de la VPN

La dirección que un sitio web informa con el túnel activo es la dirección de salida para el tráfico saliente cubierto. No es una dirección que acepte conexiones entrantes en su nombre. Usarla hacia dentro exige una función que el proveedor ofrezca de verdad, como un puerto reenviado o una traducción entrante ligada a su cuenta, más una ruta utilizable desde la salida hasta el cliente.

Una regla local de permiso no puede fabricar esa traducción. Lo que sí hace es cambiar por qué ruta van las respuestas de la aplicación, lo que importa cuando la aplicación queda excluida del túnel: la petición y la respuesta pueden acabar en contextos de red distintos y la conexión falla como si fuera un problema de cortafuegos.

Pruebe una ruta de extremo a extremo y luego nombre al propietario

Escriba la tupla antes de probar: origen previsto, dirección de destino, transporte, puerto y la máquina que posee el socket que escucha. Si algún elemento es una suposición, la prueba no le dirá nada útil.

Luego pruebe esa única ruta autorizada con la autenticación de la aplicación intacta. No publique un oyente amplio ni desactive controles ajenos solo para que responda una comprobación ambigua de dirección, porque ambos cambios sobreviven a la prueba.

El subsistema de anclaje de Android reenvía el tráfico descendente por su propia ruta, separado de la captura normal de la VPN, así que un navegador que funciona en un portátil conectado no dice nada sobre el acceso entrante a un servicio del teléfono. Antes de decir que funciona:

• El oyente está en una dirección que el otro extremo puede alcanzar, no en loopback.
• El otro extremo usa la dirección de esa entrada, no la dirección de salida de una página de estado.
• Cualquier traducción del lado del operador o del proveedor es una función admitida, no una regla añadida localmente.
• Petición y respuesta viajan por el mismo contexto de red, y la autenticación sigue pasando.