Proxy SOCKS por SSH en Android: por que só se conecta a metade das túas aplicacións

Inicias sesión por SSH, engades -D 1080 e o comando funciona. Agora existe un escoitador SOCKS no teléfono, e a metade das aplicacións seguen saíndo polos datos móbiles. Ese é o resultado normal, non un túnel roto: ssh -D crea un punto de proxy, e as aplicacións Android só usan un proxy se algo as obriga. Percorrer a cadea paso a paso mostra onde vive realmente cada peza do traballo.

Comeza onde comeza o tráfico

Escolle unha aplicación que debería usar o túnel e comproba se ten o seu propio axuste de proxy. Un navegador con campo SOCKS é o caso doado: apúntao a 127.0.0.1:1080, activa o DNS remoto se o axuste existe, e a petición pasa. Un cliente de chat, unha app de mapas ou un xogo sen ese campo non teñen forma de usar o escoitador, e nada do que escribas no comando SSH o cambia.

Antes de implicar nada máis, demostra que o escoitador funciona desde o propio shell do teléfono cun cliente que fale SOCKS directamente:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

O enderezo que volve debería ser o do servidor SSH, non o do teléfono. Se o é, a metade do proxy está feita e o resto do traballo vai de cobertura. Se non, arranxa primeiro o lado SSH: autenticación por clave, a capacidade do servidor de alcanzar o destino e a saída propia do servidor SSH.

Engade a peza que Android necesita

As aplicacións sen axuste de proxy necesitan algo que capture os seus paquetes e os converta en conexións proxy. Nun dispositivo sen root, iso é un adaptador de servizo VPN: unha app que toma a interface virtual e reenvía o tráfico seleccionado ao escoitador SOCKS local. A cadea pasa a ser app, adaptador, escoitador SOCKS, conexión SSH, destino.

Instala o adaptador, concédelle o permiso de VPN e escolle as apps ou rutas que debe capturar. A icona de chave na barra de estado representa entón o adaptador, non unha VPN comercial aparte. Android permite unha soa conexión de servizo VPN activa por perfil de usuario, así que abrir unha segunda app VPN non engade unha capa sobre a cadea: compite polo mesmo papel.

Este é tamén o paso onde unha proba exitosa pode enganarte. Se o adaptador está configurado para capturar só o navegador que xa apuntaches ao proxy, todo funciona e nada máis queda cuberto. Le a lista de captura antes de concluír que o dispositivo está tunelizado.

Mantén o transporte SSH fóra da captura

A propia conexión SSH non debe realimentarse ao túnel SOCKS que mantén. Se o adaptador captura o tráfico da app SSH, o túnel depende dunha conexión que espera ao túnel, e o resultado é un bucle que se atasca ou falla en canto arranca o adaptador.

As implementacións integradas protexen o seu propio socket de transporte. Con apps separadas necesitas unha exclusión admitida: deixa a app SSH fóra da captura ou exclúe o extremo SSH por enderezo. Ambas teñen custos. Excluír toda unha app de terminal tamén saca do túnel a súa actividade de rede non relacionada, e unha excepción de enderezo rompe cando cambia o enderezo do servidor ou cando o nome resolve distinto na seguinte conexión.

Comproba a exclusión desde fóra: reconecta o adaptador e despois confirma que a sesión SSH sobrevive e que a petición por proxy segue informando do enderezo do servidor. Unha sesión que funciona ata que arranca o adaptador e entón conxélase é o bucle.

Segue DNS e UDP ata o final da cadea

O reenvío dinámico de OpenSSH transporta conexións TCP. Non é un transporte UDP-associate nin ICMP, e un adaptador non pode inventar reenvío UDP aceptando paquetes UDP. Todo o que insiste en UDP, incluídos QUIC e os medios WebRTC, fallará ou caerá a TCP segundo a app.

DNS necesita a súa propia decisión. Unha app que resolve un nome localmente envía a consulta polo resolutor normal antes de conectar, así que o túnel transporta a conexión pero non a consulta. Un cliente consciente do proxy con opción de DNS remoto evítao; unha app capturada sen ela non. Comproba que resolutor respondeu en vez de supor que o adaptador o cambiou.

Mantén o escoitador SOCKS ligado a loopback, verifica a clave de host do servidor SSH no primeiro uso e deixa a validación HTTPS normal no seu sitio para o sitio final. SSH protexe o tramo teléfono-servidor; non cifra o que o servidor fai despois.

Revisa as dúas vidas e decide

O adaptador e a sesión SSH teñen vidas separadas. Se SSH cae mentres o adaptador segue capturando, as apps poden colgarse sen erro evidente, porque os seus paquetes seguen entrando nunha interface virtual que xa non ten saída funcional. Se o adaptador se detén, as apps ou van directas ou quedan bloqueadas, segundo a política VPN do dispositivo.

Proba ambas direccións a propósito: mata a sesión SSH co adaptador en marcha e despois detén o adaptador mentres SSH segue vivo. O que fai o teléfono en cada caso é a política que realmente estás despregando, digan o que digan as instrucións de instalación.

Se o fluxo de traballo necesita cobertura de todo o dispositivo cun modo de fallo previsible, unha VPN IP real, ou un adaptador mantido e deseñado para esta cadea, é a resposta honesta. Unha sesión de shell deixada funcionando xunto a unha app de captura non relacionada non é un túnel de dispositivo mantido; son dous compoñentes sen acordo sobre que pasa cando un deles remata.