VPN перед Tor: що насправді змінює порядок

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

Ніщо в цьому ланцюгу не змінює того, що сайт дізнається з вашого облікового запису, файлів cookie або введених даних.

Що змінює порядок

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

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

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

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

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

На запит SOCKS через порт 9150 відповідає власний клієнт Tor Browser, тому відповідь IsTor true підтверджує ланцюг браузера, а не те, що його використовує кожна інша програма. Варто записати вивід резолвера, бо DNS може вийти шляхом, який тунель не покриває. Зберігайте обидва виводи з позначкою часу. Вони — база для наступного порівняння.

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

Спостерігайте, що відбувається, коли тунель падає

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

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

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

Вирішіть, чи заслуговує додатковий шар довіри

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

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

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