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

Почніть із порядку, а не з продукту

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

Між ними змінюється те, яка адреса стоїть на далекому кінці найзовнішньої ланки. Кожен спостерігач бачить лише попередній крок, ніколи весь шлях: сторожовий релей бачить того, хто до нього підключився, а VPN-сервер бачить того, хто до нього підключився. Tor не виносить вашу локальну адресу тунелю назовні, і в протоколі немає поля, де він міг би це зробити.

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

Що бачить вхідний релей Tor

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

Це відповідає на IP-половину питання, але лише якщо тунель справді проніс з'єднання. Процес Tor досягає сторожового релею своїм власним сокетом, і цей сокет не підкоряється налаштуванням проксі Tor Browser. Браузер говорить із вбудованим процесом tor через SOCKS на 9150, і далі tor відкриває власне з'єднання, використовуючи таблицю маршрутизації ядра. Рядок Socks5Proxy у torrc або клієнтський транспорт змінюють цей шлях. Ніщо інше.

У Linux відповідь можна прочитати з машини. Запитайте ядро, який інтерфейс воно використало б для довільної публічної адреси, потім подивіться на локальну адресу встановленого з'єднання:

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

Якщо маршрут каже dev wg0 або dev tun0, а локальна адреса встановленого з'єднання є адресою тунелю, Tor усередині VPN. Якщо маршрут називає ваш фізичний інтерфейс, він зовні, що б не стверджував власний індикатор клієнта.

Що може бачити ваш VPN-провайдер

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

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

Мости з obfs4 змінюють пошук, а не топологію. Адреси моста немає в публічному списку релеїв, а трафік формується так, щоб не виглядати як Tor, тому оператор, який лише порівнює адреси, його не позначить. Сесія досі йде від вашого VPN-клієнта, і провайдер досі бачить одну кінцеву точку, один обсяг і один розклад.

Можливість — не політика зберігання

Оператор, який може спостерігати з'єднання, не обіцяв його зберігати. Логування — окреме рішення, записане в політиці, обмежене юрисдикцією і перевірюване лише тими доказами, яким ви вже довіряєте. Позначка «без логів» не змінює описаної вище мережевої ролі.

Особа облікового запису зазвичай важливіша за адресу виходу. Якщо ви увійшли за адресою електронної пошти або сплатили карткою, провайдер може пов'язати сесію з вами, не записавши жодного призначення. Ротація вихідних IP-адрес на це не впливає.

Перевірте покриття, перш ніж довіряти котрійсь із двох відповідей

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

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

Порядок, у якому я перевіряю, зупиняючись на першій невдачі:

  • ip route get 203.0.113.10 повертає пристрій тунелю.
  • ss -tnp | grep -i tor показує з'єднання зі сторожем із локальною адресою тунелю.
  • ip -6 route не має маршруту за замовчуванням поза тунелем, або в клієнті вимкнено IPv6.
  • Опускання VPN завершує або перенаправляє з'єднання tor замість того, щоб залишити його на фізичній ланці.

Який порядок пасує тому, що ви захищаєте

Обидва порядки щось приховують і щось розкривають, тому відповідь — це вибір спостерігача, який вам важливий.

ObserverTor over VPNVPN over Tor
Your ISP or local networkSees a VPN connection, not TorSees a Tor guard connection
Your VPN providerSees Tor use, and your home addressSees a Tor exit as the client, not your home address
Tor entry relaySees the VPN exitSees your home address
Destination websiteSees a Tor exitSees a Tor exit

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

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

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

Схожі статті