SSH SOCKS прокси на Android: защо се свързва само половината от приложенията ви

Влизате по 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 до края на веригата

Динамичният forward на OpenSSH пренася TCP връзки. Той не е UDP асоциация или ICMP транспорт и адаптерът не може да измисли UDP препращане, като приема UDP пакети. Всичко, което настоява за UDP, включително QUIC и WebRTC медия, или се проваля, или пада към TCP според приложението.

DNS изисква собствено решение. Приложение, което разрешава име локално, изпраща заявката през нормалния resolver преди да се свърже, така че тунелът носи връзката, но не и търсенето. Клиент, който познава прокси и има опция за отдалечено DNS, избягва това; прихванато приложение без такава опция не. Проверете кой resolver е отговорил, вместо да приемате, че адаптерът го е сменил.

Дръжте SOCKS слушателя вързан към loopback, проверете host ключа на SSH сървъра при първа употреба и оставете нормалната HTTPS проверка за крайния сайт. SSH защитава отсечката от телефона до сървъра; той не криптира това, което сървърът прави след това.

Проверете двата жизнени цикъла и решете

Адаптерът и SSH сесията имат отделни жизнени цикли. Ако SSH падне, докато адаптерът продължава да прихваща, приложенията могат да увиснат без ясна грешка, защото пакетите им все още влизат във виртуален интерфейс, който вече няма работещ изход. Ако адаптерът спре, приложенията или излизат директно, или се блокират, според VPN политиката на устройството.

Тествайте двете посоки умишлено: убийте SSH сесията при работещ адаптер, после спрете адаптера, докато SSH е жив. Това, което телефонът прави във всеки случай, е политиката, която наистина внедрявате, каквото и да твърдят инструкциите.

Ако работният процес изисква покритие на цялото устройство с предвидим режим на отказ, честният отговор е истински IP VPN или поддържан адаптер, проектиран за тази верига. Shell сесия до несвързано приложение за прихващане не е поддържан тунел на устройство; това са два компонента без споразумение какво става, когато единият свърши.