Tethering inverso para Android por USB: comandos, comprobaciones y reversión
El tethering inverso envía el tráfico del teléfono a través de un relé en el host. Construya la ruta del teléfono al host, mantenga la VPN del host en el bucle y verifique cada salto.
El tethering inverso traslada el tráfico de un teléfono a un ordenador y lo saca por la conexión del ordenador. Un cable USB por sí solo no lo hace: el teléfono necesita un servicio de captura que asuma su enrutamiento, y el ordenador necesita un relé que lleve esos paquetes más allá. La ruta tiene cuatro saltos: aplicación, captura en el teléfono, relé USB y salida del host, y cada uno tiene un propietario distinto. Este manual construye esa ruta, coloca la VPN del host donde corresponde y comprueba cada salto antes de fiarse del resultado.
Trace los saltos antes de ejecutar nada
Cada salto aplica su propia política, por eso un resultado que funciona en un extremo no dice nada del otro. La aplicación elige un destino y un resolutor, el servicio de captura decide qué tráfico entra en el relé, el relé reenvía a los sockets del host, y el enrutamiento y la VPN del host deciden la dirección que el destino acaba viendo.
| Hop | Owner | What it decides |
|---|---|---|
| Application request | The app | Destination, resolver, address family |
| Capture service | Phone VpnService app | Which traffic enters the relay at all |
| ADB relay | Host process | Forwarding phone flows to host sockets |
| Host egress | Host routing and VPN | Exit address and host policy |
Solo un cliente del servicio VPN puede ocupar a la vez el papel de captura del teléfono, así que una segunda aplicación VPN corriente no se apila sobre el relé. Si la VPN pertenece al ordenador, el servicio de captura es el enlace de acceso hacia ese ordenador, no la prueba de que un túnel remoto ya protege el resultado.
Prepare el relé antes de tocar el teléfono
Gnirehtet es el ejemplo documentado de esta arquitectura: un cliente del servicio VPN sin root en el teléfono más un relé transportado por ADB en el host, con soporte de TCP y UDP sobre IPv4. Su repositorio también indica que el proyecto ya no se mantiene activamente, así que trátelo como el diseño de referencia y una herramienta funcional para un laboratorio, no como un producto con soporte para estandarizar en una flota gestionada.
adb devices
adb shell getprop ro.build.version.release
gnirehtet run
Ejecute primero adb devices. Un teléfono que no ha aceptado la clave de depuración del host se declara como no autorizado, y el relé no se conectará hasta que se acepte el aviso en el dispositivo. gnirehtet run instala el cliente, inicia el relé y activa la captura; en una versión que separa los pasos, use en su lugar los subcomandos documentados install, relay y start.
El acceso ADB es una relación de control del dispositivo, no un ajuste de red. Autorice solo un ordenador que controle, y prevea revocar esa autorización cuando termine la tarea.
Devuelva la VPN del host a la ruta
El relé es un proceso corriente del host, así que sus conexiones posteriores siguen la tabla de enrutamiento del host. Un perfil de túnel completo las transporta; un túnel dividido puede que no. Si la VPN del host usa controles por aplicación, añada el binario del relé al conjunto permitido, de lo contrario el relé sigue usando la interfaz física mientras el navegador parece protegido.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay
Ejecute los dos primeros comandos antes y después de conectar la VPN del host. Si la dirección no cambia, el relé no está en el túnel, diga lo que diga la ventana del cliente. Un túnel solo para redes privadas también deja los destinos públicos en la salida normal del host, lo que parece una fuga pero es la política que ha configurado.
El DNS se resuelve en el host para el tráfico que pasa por el relé, así que el resolutor del host decide qué servidor ve los nombres. Un ajuste de DNS privado en el teléfono no cruza el relé, y una prueba de resolutor en el teléfono no describirá las consultas del host.
Verifique cada salto por separado
Tres comprobaciones, en este orden: el teléfono llega al relé, el relé llega al destino bajo la política del host, y la aplicación resuelve y usa correctamente ese destino. Deténgase en el primer fallo en lugar de recargar páginas y adivinar.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V
Una entrada de red VPN en el volcado de conectividad muestra que el servicio de captura está activo; el registro propio del relé muestra si llegan flujos. La ausencia en uno de los dos divide el problema con claridad: sin captura es el lado del teléfono, sin flujos es el lado del host.
Un navegador que funciona en el host demuestra la ruta del navegador del host, no la del proceso del relé. Compare las direcciones que notifica cada uno, y pruebe un recurso privado y también una página pública, porque un túnel solo para redes privadas puede encaminar uno y no el otro.
Desmonte y elija el comportamiento ante fallos
La reversión forma parte del manual. Detenga y elimine el relé, desinstale el cliente de captura y revoque la autorización de depuración del host desde las opciones de desarrollador del teléfono cuando termine la tarea.
gnirehtet stop
gnirehtet uninstall
adb kill-server
Decida qué debe hacer el teléfono cuando el relé desaparece. Sin una elección explícita puede volver a los datos móviles y filtrar el tráfico que intentaba encaminar, así que fije a propósito el comportamiento de bloqueo de conexiones o la política de VPN y pruebe el desmontaje antes de confiar en él.
Anote el host que se autorizó, la versión del relé, la política de túnel del host y los pasos de desmontaje. Ese registro es lo que hace repetible la siguiente configuración de tethering inverso en lugar de otra tarde de redescubrimiento.