Проксі SOCKS через SSH на 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 до кінця ланцюга

Динамічне переспрямування OpenSSH переносить TCP-з'єднання. Це не транспорт UDP-associate чи ICMP, і адаптер не може вигадати переспрямування UDP, приймаючи UDP-пакети. Усе, що вимагає UDP, включно з QUIC і медіа WebRTC, або зірветься, або відкотиться на TCP залежно від застосунку.

DNS потребує власного рішення. Застосунок, який розв'язує ім'я локально, надсилає запит через звичайний розв'язувач до підключення, тож тунель переносить з'єднання, але не пошук. Клієнт, що знає про проксі, з опцією віддаленого DNS уникає цього; перехоплений застосунок без неї — ні. Перевірте, який розв'язувач відповів, замість припускати, що адаптер це змінив.

Тримайте слухач SOCKS прив'язаним до loopback, перевірте ключ хоста сервера SSH при першому використанні й залиште звичайну перевірку HTTPS на місці для кінцевого сайту. SSH захищає ділянку від телефона до сервера; він не шифрує те, що сервер робить далі.

Перевірте два життєві цикли й вирішіть

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

Навмисно перевірте обидва напрямки: убійте сеанс SSH, поки адаптер працює, потім зупиніть адаптер, поки SSH залишається піднятим. Те, що телефон робить у кожному випадку, — це політика, яку ви справді впроваджуєте, хоч би що стверджувала інструкція зі встановлення.

Якщо робочий процес потребує охоплення всього пристрою з передбачуваним режимом відмови, чесна відповідь — справжній IP VPN або підтримуваний адаптер, створений для цього ланцюга. Сеанс оболонки, залишений працювати поруч із не пов'язаним застосунком перехоплення, не є підтримуваним тунелем пристрою; це два компоненти без домовленості про те, що відбувається, коли один із них завершується.