VPN у Tor, Tor у VPN: чому ланцюг рветься
Коли VPN, Tor і проксі ставлять одне на одного, порядок вирішує, що розв'язується, а що переноситься. Знайдіть першу порушену межу, перш ніж змінювати всі три.
Накладання VPN, Tor і проксі застосунку одне на одного здається множенням приватності, а насправді множить кількість місць, де з'єднання може померти. Звичний результат — браузер, який крутиться, поки всі три інструменти повідомляють, що вони здорові. Якщо змінити всі три налаштування одразу, зникне єдина підказка про те, котрий із них бреше.
Спершу намалюйте передбачуваний шлях за порядком, назвавши, яка програма відкриває кожне з'єднання і яке ім'я розв'язується на кожному кроці.
Шари не додаються, вони взаємодіють
VPN перед Tor означає, що вхідне з'єднання клієнта Tor іде всередині тунелю. VPN, перенесений через Tor, означає, що власна кінцева точка клієнта VPN має бути доступною через Tor, а це зовсім інша вимога. Проксі браузера додає ще один стрибок, про який операційна система нічого не знає. Три схеми, три окремі списки залежностей.
Кожна схема змінює те, що можна розв'язати, що можна перенести і хто бачить перший пакет. Лише одна з них може бути тією конфігурацією, яку ви мали на увазі.
Додайте на схему і прямий шлях. Резервний маршрут, виняток для розділеного тунелю або обхід проксі можуть завантажити сторінку, тихо пропускаючи ланцюг, який ви хотіли перевірити, і такий успіх вводить в оману сильніше за невдачу.
Порядок вирішує, що можна перенести
Tor переносить потоки TCP через свій інтерфейс SOCKS, і клієнт, який просить проксі розв'язати ім'я хоста, залишає запит усередині кола. UDP у звичайних конфігураціях так не ходить, тому тунель WireGuard не можна вкласти в Tor без додаткового TCP-ретранслятора посередині.
OpenVPN можна примусово перевести на TCP, тож така схема принаймні описувана. Вона також повільніша й крихкіша, а картина відмови при обриві виглядає так само, як заблокований порт. Очікуйте, що на розрізнення цих двох піде більше часу, ніж на лагодження будь-якого з них.
Розв'язання — друга половина. З --socks5-hostname проксі розв'язує адресу призначення, тоді як звичайний --socks5 спершу питає локальний розв'язувач і витікає ім'я за межі кола. Саме цей один прапорець вирішує, чи запит імені належить ланцюгу, чи вашому провайдеру.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Як знайти першу порушену межу
Перевіряйте етапи в тому порядку, у якому йдуть пакети, нешкідливими запитами й зупиняйтеся на першій невдачі. Запишіть, яка команда виконалася першою, бо порядок є частиною доказу. Дві команди відділяють мертве коло від мертвого виходу:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Перша повідомляє, чи завершується запит через проксі SOCKS взагалі, а друга показує адресу, яку мережа подає зараз. Якщо перша не вдалася, а друга вдалася, проблема в клієнті Tor або перед ним. Якщо обидві вдалися, а браузер досі не працює, застосунок використовує інший шлях, ніж оболонка.
Сторінка публічної IP теж описує лише останній видимий вихід. Вона не може сказати, скільки стрибків йому передувало, тож поєднуйте її з підтримуваним виводом стану кожного інструмента, а не вважайте одне число схемою.
Коли перестати додавати шари
Якщо ви не можете однією фразою сказати, що дає шар, приберіть його. Ланцюг із неясною метою — це ланцюг, який ніхто не налагодить о третій ночі, а виграш у приватності від непоясненого стрибка зазвичай менший за втрачену доступність.
Якщо шар справді заслуговує на своє місце, спершу перевірте його окремо, потім додайте наступний і знову підтвердьте шлях тими самими двома командами. Відновіть повний ланцюг перед звичайним використанням і залиште перевірку TLS та автентифікацію увімкненими; попередження про сертифікат, прийняте заради завантаження сторінки, — це обхід маршрутизації, а не лагодження. Запишіть порядок, на якому ви зупинилися, поки він свіжий.
Запишіть цей порядок, включно з розв'язувачем, який відповідає на кожному етапі. Робочий ланцюг, який ви можете описати, переживе наступне оновлення, а робочий ланцюг, зібраний перебором, зникне разом із ним. Додайте дату й версії, щоб пізнішу відмову можна було порівняти з відомим добрим станом, а не сперечатися про неї з пам'яті. Десять рядків у текстовому файлі економлять вечір здогадів.