VPN через Tor: спершу перевірка транспорту

Tor першим означає, що клієнт VPN стоїть за проксі SOCKS, тому сам тунель будується через Tor, а трафік застосунків виходить із кінцевої точки VPN. Це один конкретний порядок, і це не те, що будує більшість. Відкриття Tor Browser поруч зі звичайним клієнтом VPN не змушує жодну з двох програм використовувати шлях іншої.

Проходьте перевірки по порядку. Кожна вирішує, чи варто починати наступну.

Який порядок ви насправді будуєте

Два порядки плутають в одній розмові. Tor першим означає, що клієнт VPN досягає свого сервера через проксі SOCKS, тому тунель будується поверх Tor. VPN першим означає, що трафік Tor виходить через тунель, що більшість будує випадково, а потім описує як інший варіант. Перший зосереджує межу пересилання в оператора VPN, другий зосереджує її на вході та виході Tor. Жоден не є тим, що отримуєте, тримаючи обидві програми відкритими одночасно.

Запишіть, який порядок потрібен завданню, перш ніж щось налаштовувати, бо обидва вимагають різних програмних налаштувань і зазнають невдачі в різних місцях. Неправильно названий порядок відправляє вас на годину шукати помилку не в тому рівні. Усе нижче припускає Tor першим.

Перевірте транспорт раніше за все інше

Інтерфейс SOCKS у Tor передає потоки TCP і не надає загальної асоціації UDP. VPN, чий транспорт — UDP, не може розглядати цей проксі як звичайний мережевий інтерфейс, і жодне налаштування клієнта не змінює того, що проксі готовий передати. WireGuard у своїй звичайній формі — очевидна жертва. Профіль OpenVPN у режимі TCP — звичайне рішення, і йому все ще треба явно вказати використовувати проксі.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

Перш ніж налагоджувати тунель через нього, переконайтеся, що проксі слухає і може передати один звичайний запит HTTPS. Якщо звичайний запит не проходить, клієнт VPN ніколи не досягне успіху, і його журнали не скажуть вам чому.

Перепишіть карту спостерігача

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

Він також не створює заново розподілений шлях до кожного пункту призначення. Tor Browser будує свіжу схему для кожного сайту; VPN, який переноситься через Tor, будує один тунель, і кожен сайт за ним поділяє цю кінцеву точку. Ставтеся до різниці як до факту проєктування, а не як до обмеження, яке треба усунути.

Порахуйте рівні відмови, коли щось ламається

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

Зафіксуйте перший рівень, що зазнав збою, і зупиніться там. Відмова проксі та відхилений ключ — не варіанти однієї події.

Зупиніться, якщо модель загроз потребує захисту Tor Browser

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

Сам Tor Project попереджає проти комбінацій, які користувачі не можуть правильно налаштувати, і ця стосується більшості людей. Це навмисний дизайн для вузької моделі загроз, а не короткий шлях до анонімного трафіку всього пристрою.