Android SSH SOCKS прокси: зошто се поврзува само половина од твоите апликации

Се најавуваш преку SSH, додаваш -D 1080, и командата успева. Сега на телефонот има SOCKS слушач, а половина од апликациите сè уште излегуваат преку мобилни податоци. Тоа е нормален резултат, а не расипан тунел: ssh -D создава прокси крајна точка, а Android апликациите користат прокси само ако нешто ги принуди. Минувањето низ синџирот чекор по чекор покажува каде секој дел од работата навистина живее.

Започни таму каде што започнува сообраќајот

Избери една апликација што треба да го користи тунелот и провери дали има сопствено прокси поставување. Прелистувач со SOCKS поле е лесниот случај: насочи го кон 127.0.0.1:1080, вклучи далечински DNS ако поставувањето постои, и барањето поминува. Клиент за разговор, апликација за карти или игра без такво поле немаат начин да го користат слушачот, и ништо што ќе напишеш во SSH командата тоа не го менува.

Пред да вклучиш нешто друго, докажи дека слушачот работи од сопствената школка на телефонот со клиент што зборува SOCKS директно:

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

Адресата што се враќа треба да биде на SSH серверот, не на телефонот. Ако е така, прокси половината е завршена и остатокот од работата е за покриеност. Ако не е, прво поправи ја SSH страната: автентикација со клуч, способноста на серверот да стигне до дестинацијата и сопствениот излез на SSH серверот.

Додај го делот што му е потребен на Android

Апликациите без прокси поставување бараат нешто што ги фаќа нивните пакети и ги претвора во прокси врски. На уред без root тоа е адаптер за VPN услуга: апликација што го зема виртуелниот интерфејс и го препраќа избраниот сообраќај до локалниот SOCKS слушач. Синџирот станува апликација, адаптер, SOCKS слушач, SSH врска, дестинација.

Инсталирај го адаптерот, дај му VPN дозвола и избери ги апликациите или рутите што треба да ги фаќа. Иконата со клуч во статусната лента тогаш го претставува адаптерот, а не одделен комерцијален VPN. Android дозволува една активна врска за VPN услуга по кориснички профил, па стартувањето втора VPN апликација не додава слој врз синџирот: се натпреварува за истата улога.

Ова е и чекорот каде успешен тест може да те залаже. Ако адаптерот е поставен да го фаќа само прелистувачот што веќе си го насочил кон проксито, сè работи и ништо друго не е покриено. Прочитај го списокот за фаќање пред да заклучиш дека уредот е во тунел.

Држи го SSH транспортот надвор од фаќањето

Самата SSH врска не смее да се врати во SOCKS тунелот што го одржува. Ако адаптерот го фаќа сообраќајот на SSH апликацијата, тунелот зависи од врска што го чека тунелот, а резултатот е јамка што се заглавува или пропаѓа штом адаптерот ќе почне.

Интегрираните имплементации го штитат сопствениот транспортен сокет. Со одделни апликации ти треба поддржано исклучување: остави ја SSH апликацијата надвор од фаќањето или исклучи ја SSH крајната точка по адреса. Двете имаат цена. Исклучувањето на цела терминална апликација ја вади од тунелот и нејзината неповрзана мрежна активност, а исклучувањето по адреса се крши кога адресата на серверот ќе се смени или кога името при следната врска ќе се реши поинаку.

Провери го исклучувањето однадвор: поврзи го адаптерот повторно, потоа потврди дека SSH сесијата преживува и дека барањето преку прокси сè уште ја пријавува адресата на серверот. Сесија што работи додека адаптерот не почне, па замрзнува, е таа јамка.

Следи ги DNS и UDP до крајот на синџирот

Динамичното препраќање на OpenSSH носи TCP врски. Тоа не е UDP-associate или ICMP транспорт, и адаптерот не може да измисли UDP препраќање со прифаќање UDP пакети. Сè што инсистира на UDP, вклучително QUIC и WebRTC медиуми, или пропаѓа или паѓа назад на TCP, зависно од апликацијата.

DNS бара своја одлука. Апликација што решава име локално го праќа барањето преку обичниот резолвер пред да се поврзе, па тунелот ја носи врската но не и пребарувањето. Клиент свесен за прокси со опција за далечински DNS го избегнува тоа; фатена апликација без неа не. Провери кој резолвер одговорил наместо да претпоставиш дека адаптерот го сменил.

Држи го SOCKS слушачот врзан за loopback, провери го host клучот на SSH серверот при прва употреба и остави ја обичната HTTPS валидација на место за крајното мрежно место. SSH го штити делот телефон-до-сервер; тој не го шифрира она што серверот го прави потоа.

Провери ги двата животни циклуси и одлучи

Адаптерот и SSH сесијата имаат одделни животни циклуси. Ако SSH падне додека адаптерот продолжува да фаќа, апликациите може да висат без очигледна грешка, зашто нивните пакети сè уште влегуваат во виртуелен интерфејс што веќе нема работен излез. Ако адаптерот застане, апликациите или одат директно или се блокирани, зависно од VPN политиката на уредот.

Намерно тестирај ги двата правци: убиј ја SSH сесијата додека адаптерот работи, потоа запре го адаптерот додека SSH останува горе. Она што телефонот го прави во секој случај е политиката што навистина ја распоредуваш, што и да тврделе упатствата за инсталација.

Ако работниот тек бара покриеност на целиот уред со предвидлив начин на откажување, вистински IP VPN или одржуван адаптер дизајниран за овој синџир е чесниот одговор. Школка сесија оставена да работи покрај неповрзана апликација за фаќање не е одржуван тунел за уред; тоа се два дела без договор за тоа што се случува кога еден од нив завршува.