La regla de una sola VPN en Android no bloquea un servidor SSH alojado

La creencia es lo bastante común como para tratarla como un hecho: Android solo permite una VPN, así que un servidor SSH que se ejecuta en el teléfono no puede funcionar a través de ese túnel. La primera mitad es cierta y la conclusión no se sigue. El límite de la plataforma tiene que ver con cuántas aplicaciones pueden ocupar la ranura del servicio VPN, no con cuántos sockets pueden existir ni con quién puede conectarse al teléfono. Un demonio SSH con un socket en escucha es una aplicación normal con un puerto normal, y el túnel es una de las rutas que puede tomar su tráfico.

Qué limita realmente la regla de una sola VPN

VpnService es un recurso de ranura única. Cuando una aplicación establece un túnel, se convierte en la VPN del dispositivo, y una segunda aplicación que intente establecer otro es rechazada hasta que la primera desaparezca. Esa es una regla sobre la propiedad del túnel, y explica por qué dos clientes VPN no pueden ejecutarse a la vez.

No dice nada sobre los sockets en escucha. El servidor SSH no llama a VpnService, no intercepta paquetes ni compite por esa ranura. Enlaza un puerto y acepta conexiones, que es lo mismo que haría sin ninguna VPN instalada. Así que el mito confunde un límite sobre los proveedores de túnel con un límite sobre las conexiones de red, y los dos no guardan relación.

El listener es un destino, no parte del túnel

Una vez que el túnel existe, el teléfono tiene una dirección en él y el dispositivo par tiene una ruta hacia esa dirección. Que algo responda lo decide el listener. Un demonio enlazado a loopback solo es alcanzable desde el propio teléfono; un demonio enlazado a la dirección antigua del túnel puede conservar su enlace tras una reconexión aunque la dirección a la que se enlazó haya cambiado.

Las reglas de enlace son configuración SSH corriente: la dirección y el puerto de escucha, y quién puede autenticarse. En Android esos ajustes viven en la configuración propia de la aplicación, y puede que el propietario del proceso de la app no tenga permiso para usar puertos privilegiados, de modo que la costumbre de escritorio de enlazar el puerto 22 como root no se traslada sin cambios.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Luego está el permiso sobre la propia ruta. Una VPN de consumo que transporta sin problema el tráfico web saliente no tiene por qué permitir conexiones entrantes hacia sus clientes; muchas no lo hacen, porque expondría a un cliente ante otro. Si el par no puede alcanzar la dirección de túnel del teléfono desde ningún sitio, el problema está en la política del servicio y no en el teléfono.

La ruta de respuesta es donde suele romperse

Supongamos que el par alcanza la dirección de túnel del teléfono y el SYN llega. Ahora la respuesta tiene que salir por la misma ruta, y esa es una decisión de enrutamiento dentro del teléfono. Si la respuesta sale por Wi-Fi porque esa es la red predeterminada, el par ve una conexión que nunca se completa, lo que se parece exactamente a un cortafuegos.

Android lo hace más complicado que un escritorio porque la red predeterminada se elige por proceso y la política de la aplicación VPN puede cambiarla. Un cliente VPN puede enrutar solo una lista de aplicaciones permitidas, así que una aplicación servidor que queda fuera de esa lista sigue usando la red física para sus respuestas mientras el par las espera por el túnel.

Una aplicación también puede enlazar sus propios sockets a una red concreta, lo que anula la predeterminada. Cuando lees un informe de que un servicio es alcanzable desde una dirección y no desde otra, normalmente este es el mecanismo que hay detrás.

Saltarse la VPN no repara un servicio entrante

El recurso popular, excluir la aplicación SSH de la VPN para que su tráfico deje de redirigirse, es una solución para el problema opuesto. Ayuda cuando el transporte de un cliente SSH saliente se rompe una y otra vez por culpa del túnel. Para un servidor alojado puede sacar las respuestas del túnel que usa el par, lo que convierte un fallo parcial en uno total.

Lo mismo se aplica a abrir un puerto público en el router. Si el requisito es que un dispositivo autorizado llegue al teléfono por la VPN, exponer SSH a internet es un modelo de amenaza distinto y no una reparación.

Decide primero la dirección del servicio: la dirección LAN del teléfono, su dirección de túnel o un extremo reenviado a propósito. Cada una tiene su propio contrato de alcanzabilidad y exposición, y mezclarlas es como un pequeño problema de acceso acaba convertido en un agujero permanente.

Diagnostica una dirección cada vez

Anota cuatro hechos antes de cambiar la configuración: la dirección a la que se conecta el par, el estado del listener en el teléfono, el contexto de aplicación y usuario que lo posee, y la ruta observada en cada dirección. Un informe que dice que la VPN desconecta SSH no contiene ninguno de ellos y no puede distinguir un problema de transporte del cliente de un servidor inalcanzable.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Ejecuta la comprobación del puerto desde el par, no desde el teléfono, y lee la salida detallada del cliente SSH para ver si falla antes o después del handshake TCP. Un socket que nunca conecta y un inicio de sesión rechazado son etapas distintas con responsables distintos.

Mantén intactas la verificación de la clave del host y las restricciones de cuenta mientras depuras. Restringir el listener y los usuarios permitidos es lo que hace aceptable un servidor alcanzable; aflojarlos para que funcione una conexión cambia un problema por otro peor. La referencia del servidor OpenSSH cubre los controles de escucha y acceso si tu implementación de Android sigue los mismos nombres de configuración.