Proxy SOCKS SSH su Android: perché si connette solo metà delle tue app

Accedi via SSH, aggiungi -D 1080 e il comando riesce. Ora sul telefono esiste un listener SOCKS, e metà delle app esce ancora dai dati mobili. È il risultato normale, non un tunnel rotto: ssh -D crea un endpoint proxy, e le app Android usano un proxy solo se qualcosa le costringe. Percorrere la catena passo per passo mostra dove vive davvero ogni pezzo del lavoro.

Parti da dove parte il traffico

Scegli un'app che dovrebbe usare il tunnel e controlla se ha un'impostazione proxy propria. Un browser con un campo SOCKS è il caso facile: puntalo su 127.0.0.1:1080, abilita il DNS remoto se l'impostazione esiste, e la richiesta passa. Un client di chat, un'app di mappe o un gioco senza quel campo non hanno modo di usare il listener, e niente di ciò che scrivi nel comando SSH lo cambia.

Prima di coinvolgere qualsiasi altra cosa, dimostra che il listener funziona dalla shell del telefono con un client che parla SOCKS direttamente:

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

L'indirizzo che torna dovrebbe essere quello del server SSH, non del telefono. Se lo è, la metà proxy è fatta e il resto del lavoro riguarda la copertura. Se non lo è, sistema prima il lato SSH: autenticazione con chiave, capacità del server di raggiungere la destinazione e uscita propria del server SSH.

Aggiungi il pezzo che serve ad Android

Le app senza impostazione proxy hanno bisogno di qualcosa che catturi i loro pacchetti e li trasformi in connessioni proxy. Su un dispositivo senza root è un adattatore di servizio VPN: un'app che prende l'interfaccia virtuale e inoltra il traffico selezionato al listener SOCKS locale. La catena diventa app, adattatore, listener SOCKS, connessione SSH, destinazione.

Installa l'adattatore, concedigli l'autorizzazione VPN e scegli le app o le rotte che deve catturare. L'icona della chiave nella barra di stato rappresenta allora l'adattatore, non una VPN commerciale separata. Android consente una sola connessione di servizio VPN attiva per profilo utente, quindi avviare una seconda app VPN non aggiunge uno strato alla catena: compete per lo stesso ruolo.

È anche il passo in cui un test riuscito può ingannarti. Se l'adattatore è configurato per catturare solo il browser che hai già puntato al proxy, tutto funziona e nient'altro è coperto. Leggi l'elenco di cattura prima di concludere che il dispositivo è in tunnel.

Tieni il trasporto SSH fuori dalla cattura

La connessione SSH stessa non deve essere reimmessa nel tunnel SOCKS che mantiene. Se l'adattatore cattura il traffico dell'app SSH, il tunnel dipende da una connessione che aspetta il tunnel, e il risultato è un ciclo che si blocca o fallisce appena l'adattatore parte.

Le implementazioni integrate proteggono il proprio socket di trasporto. Con app separate serve un'esclusione supportata: lascia l'app SSH fuori dalla cattura, oppure escludi l'endpoint SSH per indirizzo. Entrambe hanno un costo. Escludere un'intera app di terminale toglie dal tunnel anche la sua attività di rete non correlata, e un'eccezione di indirizzo si rompe quando l'indirizzo del server cambia o quando il nome si risolve diversamente alla connessione successiva.

Verifica l'esclusione dall'esterno: ricollega l'adattatore, poi conferma che la sessione SSH sopravvive e che la richiesta via proxy riporta ancora l'indirizzo del server. Una sessione che funziona finché l'adattatore non parte e poi si blocca è il ciclo.

Segui DNS e UDP fino alla fine della catena

L'inoltro dinamico di OpenSSH trasporta connessioni TCP. Non è un trasporto UDP-associate né ICMP, e un adattatore non può inventare l'inoltro UDP accettando pacchetti UDP. Tutto ciò che insiste su UDP, compresi QUIC e i media WebRTC, fallirà o ricadrà su TCP a seconda dell'app.

Il DNS ha bisogno di una decisione propria. Un'app che risolve un nome localmente invia la query tramite il resolver normale prima di connettersi, quindi il tunnel trasporta la connessione ma non la ricerca. Un client consapevole del proxy con opzione DNS remoto lo evita; un'app catturata senza quell'opzione no. Controlla quale resolver ha risposto invece di dare per scontato che l'adattatore l'abbia cambiato.

Tieni il listener SOCKS legato al loopback, verifica la chiave host del server SSH al primo uso e lascia in piedi la normale validazione HTTPS per il sito finale. SSH protegge il tratto telefono-server; non cifra ciò che il server fa dopo.

Controlla le due vite e decidi

L'adattatore e la sessione SSH hanno vite separate. Se SSH cade mentre l'adattatore continua a catturare, le app possono bloccarsi senza un errore evidente, perché i loro pacchetti entrano ancora in un'interfaccia virtuale che non ha più un'uscita funzionante. Se l'adattatore si ferma, le app o vanno dirette o vengono bloccate, secondo la politica VPN del dispositivo.

Prova entrambe le direzioni di proposito: uccidi la sessione SSH con l'adattatore in funzione, poi ferma l'adattatore mentre SSH resta attivo. Quello che il telefono fa in ciascun caso è la politica che stai davvero distribuendo, qualunque cosa affermassero le istruzioni di installazione.

Se il flusso di lavoro richiede copertura dell'intero dispositivo con una modalità di guasto prevedibile, una vera VPN IP, o un adattatore mantenuto e progettato per questa catena, è la risposta onesta. Una sessione shell lasciata attiva accanto a un'app di cattura non correlata non è un tunnel di dispositivo mantenuto; sono due componenti senza accordo su cosa succede quando uno dei due finisce.