Proxy SSH SOCKS a Android: per què només es connecta la meitat de les aplicacions

Inicieu sessió per SSH, afegiu -D 1080, i la comanda s’executa. Ara hi ha un oient SOCKS al telèfon, i la meitat de les aplicacions continuen sortint per dades mòbils. Aquest és el resultat normal, no un túnel trencat: ssh -D crea un punt final de proxy, i les aplicacions d’Android només fan servir un proxy si alguna cosa les hi obliga. Recórrer la cadena pas a pas mostra on viu realment cada peça de la feina.

Comenceu on comença el trànsit

Trieu una aplicació que hagi d’usar el túnel i comproveu si té una configuració de proxy pròpia. Un navegador amb un camp SOCKS és el cas fàcil: apunteu-lo a 127.0.0.1:1080, activeu el DNS remot si l’opció existeix, i la petició passa. Un client de xat, una aplicació de mapes o un joc sense aquest camp no tenen manera d’usar l’oient, i res del que escriviu a l’ordre SSH ho canvia.

Abans de fer res més, demostreu que l’oient funciona des del propi shell del telèfon amb un client que parli SOCKS directament:

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

L’adreça que torna ha de ser la del servidor SSH, no la del telèfon. Si ho és, la meitat del proxy està feta i la resta és cobertura. Si no, arregleu primer la banda SSH: autenticació per clau, la capacitat del servidor d’arribar a la destinació i la sortida pròpia del servidor SSH.

Afegiu la peça que Android necessita

Les aplicacions sense configuració de proxy necessiten alguna cosa que capturi els seus paquets i els converteixi en connexions de proxy. En un dispositiu sense root, això és un adaptador de servei VPN: una aplicació que pren la interfície virtual i envia el trànsit seleccionat a l’oient SOCKS local. La cadena passa a ser aplicació, adaptador, oient SOCKS, connexió SSH, destinació.

Instal·leu l’adaptador, doneu-li permís de VPN i trieu les aplicacions o rutes que ha de capturar. Aleshores la icona de clau de la barra d’estat representa l’adaptador, no un VPN comercial a part. Android només permet una connexió activa de servei VPN per perfil d’usuari, així que engegar una segona aplicació VPN no afegeix una capa sobre la cadena; competeix pel mateix paper.

Aquest és també el pas on una prova reeixida us pot enganyar. Si l’adaptador només captura el navegador que ja heu apuntat al proxy, tot funciona i no hi ha res més cobert. Llegiu la llista de captura abans de concloure que el dispositiu és dins del túnel.

Manteniu el transport SSH fora de la captura

La connexió SSH mateixa no s’ha de retroalimentar dins del túnel SOCKS que manté. Si l’adaptador captura el trànsit de l’aplicació SSH, el túnel depèn d’una connexió que espera el túnel, i el resultat és un bucle que s’encalla o falla tan bon punt arrenca l’adaptador.

Les implementacions integrades protegeixen el seu propi socket de transport. Amb aplicacions separades cal una exclusió suportada: deixeu l’aplicació SSH fora de la captura o excloeu el punt final SSH per adreça. Totes dues tenen un cost. Excloure una aplicació de terminal sencera també treu del túnel la seva activitat de xarxa no relacionada, i una excepció per adreça es trenca quan canvia l’adreça del servidor o quan el nom es resol diferent a la connexió següent.

Comproveu l’exclusió des de fora: reconnecteu l’adaptador i confirmeu que la sessió SSH sobreviu i que la petició amb proxy encara informa de l’adreça del servidor. Una sessió que funciona fins que arrenca l’adaptador i llavors es congela és el bucle.

Seguiu DNS i UDP fins al final de la cadena

El forward dinàmic d’OpenSSH transporta connexions TCP. No és una associació UDP ni un transport ICMP, i un adaptador no pot inventar reenviament UDP acceptant paquets UDP. Tot el que insisteix en UDP, inclosos QUIC i els mitjans WebRTC, o falla o cau a TCP segons l’aplicació.

El DNS necessita la seva pròpia decisió. Una aplicació que resol un nom localment envia la consulta pel resolutor normal abans de connectar-se, així que el túnel porta la connexió però no la cerca. Un client conscient del proxy amb opció de DNS remot ho evita; una aplicació capturada sense aquesta opció no. Comproveu quin resolutor ha respost en lloc de suposar que l’adaptador l’ha canviat.

Manteniu l’oient SOCKS lligat a loopback, verifiqueu la clau d’amfitrió del servidor SSH al primer ús i deixeu la validació HTTPS normal per al lloc final. SSH protegeix el tram del telèfon al servidor; no xifra el que el servidor fa després.

Reviseu les dues durades i decidiu

L’adaptador i la sessió SSH tenen durades separades. Si SSH cau mentre l’adaptador continua capturant, les aplicacions es poden penjar sense cap error evident, perquè els seus paquets encara entren en una interfície virtual que ja no té sortida operativa. Si l’adaptador s’atura, les aplicacions o van directes o queden bloquejades, segons la política VPN del dispositiu.

Proveu les dues direccions a propòsit: mateu la sessió SSH amb l’adaptador en marxa i després atureu l’adaptador mentre SSH segueix viu. El que fa el telèfon en cada cas és la política que realment desplegueu, digui el que digui la guia de configuració.

Si el flux de treball necessita cobertura de tot el dispositiu amb una fallada previsible, la resposta honesta és un VPN IP real o un adaptador mantingut i dissenyat per a aquesta cadena. Una sessió de shell al costat d’una aplicació de captura no relacionada no és un túnel de dispositiu mantingut; són dos components sense acord sobre què passa quan un d’ells acaba.