Proxy SOCKS prin SSH pe Android: de ce se conectează doar jumătate dintre aplicații

Te autentifici prin SSH, adaugi -D 1080 și comanda reușește. Acum există un ascultător SOCKS pe telefon, iar jumătate dintre aplicații ies în continuare prin datele mobile. Acesta este rezultatul normal, nu un tunel stricat: ssh -D creează un punct final de proxy, iar aplicațiile Android folosesc un proxy doar dacă ceva le obligă. Parcurgerea lanțului pas cu pas arată unde se află de fapt fiecare parte a muncii.

Începe de unde începe traficul

Alege o aplicație care ar trebui să folosească tunelul și verifică dacă are propria setare de proxy. Un browser cu câmp SOCKS este cazul simplu: îndreptă-l spre 127.0.0.1:1080, activează DNS la distanță dacă setarea există, și cererea trece. Un client de chat, o aplicație de hărți sau un joc fără un astfel de câmp nu au cum să folosească ascultătorul, și nimic din ce scrii în comanda SSH nu schimbă asta.

Înainte de a implica orice altceva, dovedește că ascultătorul funcționează din shell-ul telefonului însuși, cu un client care vorbește SOCKS direct:

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

Adresa care se întoarce ar trebui să fie a serverului SSH, nu a telefonului. Dacă este, jumătatea de proxy este gata și restul muncii ține de acoperire. Dacă nu, repară mai întâi partea SSH: autentificarea cu cheie, capacitatea serverului de a ajunge la destinație și ieșirea proprie a serverului SSH.

Adaugă partea de care are nevoie Android

Aplicațiile fără setare de proxy au nevoie de ceva care să le prindă pachetele și să le transforme în conexiuni proxy. Pe un dispozitiv fără root, aceea este un adaptor de serviciu VPN: o aplicație care preia interfața virtuală și trimite traficul selectat către ascultătorul SOCKS local. Lanțul devine aplicație, adaptor, ascultător SOCKS, conexiune SSH, destinație.

Instalează adaptorul, acordă-i permisiunea VPN și alege aplicațiile sau rutele pe care trebuie să le prindă. Pictograma cu cheie din bara de stare reprezintă atunci adaptorul, nu un VPN comercial separat. Android permite o singură conexiune activă de serviciu VPN per profil de utilizator, așa că pornirea unei a doua aplicații VPN nu adaugă un strat lanțului: concurează pentru același rol.

Acesta este și pasul în care un test reușit te poate induce în eroare. Dacă adaptorul este setat să prindă doar browserul pe care l-ai îndreptat deja spre proxy, totul funcționează și nimic altceva nu este acoperit. Citește lista de captură înainte de a concluziona că dispozitivul este în tunel.

Ține transportul SSH în afara capturii

Conexiunea SSH în sine nu trebuie realimentată în tunelul SOCKS pe care îl întreține. Dacă adaptorul prinde traficul aplicației SSH, tunelul depinde de o conexiune care așteaptă tunelul, iar rezultatul este o buclă care se blochează sau eșuează imediat ce adaptorul pornește.

Implementările integrate își protejează propriul socket de transport. Cu aplicații separate ai nevoie de o excepție acceptată: lasă aplicația SSH în afara capturii sau exclude punctul final SSH după adresă. Ambele au un cost. Excluderea unei aplicații de terminal întregi scoate din tunel și activitatea ei de rețea nelegată, iar o excepție de adresă se strică atunci când adresa serverului se schimbă sau când numele se rezolvă altfel la următoarea conexiune.

Verifică excepția din exterior: reconectează adaptorul, apoi confirmă că sesiunea SSH supraviețuiește și că cererea prin proxy raportează în continuare adresa serverului. O sesiune care funcționează până pornește adaptorul și apoi îngheață este bucla aceea.

Urmărește DNS și UDP până la capătul lanțului

Redirecționarea dinamică a OpenSSH transportă conexiuni TCP. Nu este un transport UDP-associate sau ICMP, iar un adaptor nu poate inventa redirecționare UDP acceptând pachete UDP. Orice insistă pe UDP, inclusiv QUIC și media WebRTC, fie eșuează, fie revine la TCP în funcție de aplicație.

DNS are nevoie de propria decizie. O aplicație care rezolvă un nume local trimite interogarea prin resolverul obișnuit înainte de a se conecta, așa că tunelul transportă conexiunea, dar nu căutarea. Un client conștient de proxy cu opțiune de DNS la distanță evită asta; o aplicație capturată fără această opțiune nu. Verifică ce resolver a răspuns în loc să presupui că adaptorul l-a schimbat.

Ține ascultătorul SOCKS legat de loopback, verifică cheia de host a serverului SSH la prima utilizare și lasă validarea HTTPS normală la locul ei pentru site-ul final. SSH protejează segmentul telefon-la-server; nu criptează ce face serverul după aceea.

Verifică cele două durate de viață și decide

Adaptorul și sesiunea SSH au durate de viață separate. Dacă SSH cade în timp ce adaptorul continuă să prindă, aplicațiile pot rămâne blocate fără o eroare evidentă, pentru că pachetele lor intră în continuare într-o interfață virtuală care nu mai are o ieșire funcțională. Dacă adaptorul se oprește, aplicațiile fie merg direct, fie sunt blocate, în funcție de politica VPN a dispozitivului.

Testează ambele direcții intenționat: omoară sesiunea SSH cu adaptorul pornit, apoi oprește adaptorul în timp ce SSH rămâne sus. Ce face telefonul în fiecare caz este politica pe care o implementezi cu adevărat, orice ar susține instrucțiunile de instalare.

Dacă fluxul de lucru cere acoperirea întregului dispozitiv cu un mod de eșec previzibil, un VPN IP real, sau un adaptor întreținut proiectat pentru acest lanț, este răspunsul onest. O sesiune de shell lăsată să ruleze lângă o aplicație de captură nelegată nu este un tunel de dispozitiv întreținut; sunt două componente fără înțelegere despre ce se întâmplă când una dintre ele se termină.