TOR over VPN
Возможно, данный вопрос уже обсуждался и ответы на него есть, но я не нашел и у самого не хватает ума как правильно впнировать (openvpn) TOR чтобы на выходе в сеть был тор, а не впн?
клиент(я) – ВПН – ТОР – инет
судя по тому какой видят IP у меня получается: клиент – ТОР (если он вообще работает) – ВПН – инет :(
комментариев: 17 документов: 0 редакций: 0
Даже два раза было написано. Но одно дело внимательно прочитать, а другое понять и уметь применить. Большое спасибо, что потратили свое время и расписали ответ, как для полного дауна.
Даже не обладая технической грамотностью, можно вынести 2 момента для себя:
- Это не так просто, из коробки работать не будет (иначе эти сложности никто бы не наворачивал).
- Запуск из коробки с умолчальными настройками приводит к зацикливанию.
Кстати, радуйтесь, что сейчас есть guard'ы, которые редко меняются. Если бы их не было (как несколько лет назад), я даже не представляю, как можно было бы дёшево избежать нескольких таблиц маршрутизации. Писать скрипт, который распарсит статистику Tor'а, выудит оттуда все тысячи entry-нод и добавит их в качестве отдельных маршрутов в route? А если противник поднимет свой сервис на одной из таких нод, то вы соединитесь с ним напрямую, минуя как Tor, так и VPN, то есть, всё совсем плохо, так что никак без продвинутых плясок не обошлось бы.Пожалуйста. Отпишитесь, если вам помогло и у вас заработало.
Не у всех есть Linux в обычной инсталляции, который можно курочить. Дело не столько в амнезии, сколько в том, что окружение ОС в Tails у всех одно и то же (чего не сказать про железо), в то время как обычный ваш домашний Linux содержит массу косвенной информации о вашей неанонимной деятельности.
Сразу не сообразил, что в случае guard-нод проблема именно та же. Если противник подсунет вам ссылку (методов — миллион) вида http://XXX.XXX.XXX.XXX, где XXX.XXX.XXX.XXX — номер ему подконтрльного guard'а, то, пройдя по ней, вы сконнектитесь напрямую, а не через Tor+VPN, это даёт полный деанон.
Защититься от этого можно, если фильтровать трафик по юзерам, запретив от своего пользователя соединяться с guard-узлами вообще. В Tails, должно быть (но надо проверять), Tor из-под служебного юзера запущен, а ICMP и трафик от рута во внешку забанены, так что их это ограничение не коснётся. Вполне может быть, что в Tails и по умолчанию настроено всё ОК, но надо курить правила iptables и думать, возникнет такая проблема после нашего вмешательства, или она надуманная.
Правда, эта метода всё равно опасная: даже если не будет деанона, может возникнуть профилирование. Если TBB в Tails работает не через прокси, а через настройку «прозрачная торификация», то можно получить идеальное профилирование при глупо написанных правилах iptables: если подсунуть любому юзеру ссылку http://XXX.XXX.XXX.XXX, то он по ней пройдёт, коннектясь из-под того же IP, что и всегда, а вы не пройдёте вообще, т.к. файерволл заблочит соединение. Впрочем, если в TBB весь трафик идёт через сокс, то всё должно быть ОК (а все другие приложения/программы надо рассматривать отдельно). Может, и при прозрачной торификации TBB всё ОК, но над этим нужно внимательно подумать, что и как будет работать. Мне сходу сложно сказать, на что добавленные правила для статического роутинга могут повлиять и каким образом.
Тема заставляет ещё раз серьёзно подумать о том, насколько уязвимыми являются системы, собранные на коленке без тщательного продумывания и перестраховок. Всё же лучше потратить время и разобраться с поддержкой нескольких таблиц маршрутизации в Linux. Это будет непросто, но можно. Естественно, с этим лучше играться и настраивать не под Tails, чтобы не рушить его уже встроенные автоматику и страховку анонимности.
В соседнем топике уже давали совет, что «вообще не надо так делать», и вы хотите неправильного, но с технической точки зрения вопрос интересный, да и могут быть конкретные ситуации, когда именно такая конфигурация — наименьшее зло (другие не работают, или ещё какие тонкости есть).
Кстати, оно неправильное не только с точки зрения анонимности, а вообще, с точки зрения и производительности и логики работы.
Для простоты можно вначале рассмотреть VPN поверх TCP и VPN поверх UDP. Отличие:
- VPN поверх UDP: работает быстро, почти без оверхеда, некритичен к сетевым задержкам, но бывают проблемы с mtu и с тем, что UDP ограничивается провайдером.
- VPN поверх TCP: работает всегда, но не всегда быстро, критичен к задержкам, очень критичен к потерям пакетов.
Однако, на идеальном интернете с малым пингом и без потерь пакетов оба варианта работают одинаково хорошо. Что касается критичности к потерям пакетов, есть такое наблюдение при 5% потерь и при среднем пинге 500ms:- VPN поверх UDP работает, потерь так же 5%.
- VPN поверх TCP подключается с десятой попытки, потери переваливают за 20%, практически ничего не работает.
Мораль: TCP следует использовать только тогда, когда провайдер порезал UDP.Следует соблюдать принцип «не мешать в одну кучу пакетные и потоковые уровни, соблюдать строгую очередность: сначала пакетные, потом потоковые», где потоковые — это протоколы и сервисы с гарантированной доставкой и с внутренней очередностью доставки данных (например, TCP, Tor, все виды проксей), а пакетные — протколы и сервисы, не гарантирующие доставку и очередность (IP, UDP, DNS, ICMP, VPN). Потоковые протоколы в норме строятся поверх пакетных, поэтому эту очередность всегда следует соблюдать: сначала наслаиваем друг на друга пакетные протоколы, а затем наслаиваем сверху потоковые, если же используется обратная очередность, то проблемы взаимно умножаются.
Теперь что касается Tor через VPN: VPN через Tor — страшный изврат, который будет работать крайне плохо. Даже если сильно хочется чего-то такого, лучше использовать прокси вместо VPN. VPN поверх Tor не взлетит из-за тормозов, а если и взлетит, то пользоваться этим без содрогания будет нельзя. Грубо говоря, для полноценного VPN канала важны не килобайты, а миллисекунды, с чем у Tor всё очень плохо. Даже 20% потерь пакетов будет означать, что практически ничего не работает. И потери эти не условные: скорость и стабильность связи внутри VPN-канала напрямую зависят от пинга между клиентом и VPN-сервером, а пакет, не дошедший вовремя, приравнивается к потерянному. Секунда — это самый край, когда еще что-то шевелится.
В Tor идет поток, а внутри потока находится пакетный уровень, где внутри пакетного — еще один потоковый. Второй потоковый уровень считает задержки в первом потоковом уровне за потери, начинает перезапрашивать пакеты, и всё умирает, отрицательные эффекты накладываются и умножаются.
Если хочется решать проблему кардинально, то нужно разрабатывать не просто другой VPN-проткол, а новый TCP-протокол и обновлять все сервера в интернете, потому что именно TCP-протокол считает сильные задержки за потери. Таймауты тоже придется менять везде, а не только у себя.
Когда трафик идет через Tor, это фактически один сквозной поток от нас к цели соединения. Этот поток делится на сегменты: от нас до первой ноды, от первой до второй, от второй до третьей, от третьей — до цели. Каждый сегмент — сам по себе, сам управляет потоком и пересылает потерянные пакеты, т.е., при потере пакета или задержке между нодой-2 и нодой-3 повторная пересылка будет именно между ними, а не по всей цепочке между нами и целью. Если же мы заворачиваем VPN внутрь Tor, то у нас получается потоковый уровень из одного сегмента — между нами и целью (всё, что ниже, от него скрыто). Соответственно, если в таком случае идет задержка, то повтор будет идти по всей цепочке. Потеря пакета между Tor-нодами вызовет пересылку только между ними, задержка же трафика VPN вызывает пересылку по всей цепочке от нас до цели. Из-за этого крайне важен пинг. Вот и получается, что VPN внутри Tor'а может работать только чудом, тогда как простые соединения через него могут идти нормально, с приличной скоростью и без проблем.
Кстати, VPN-сервер вообще никак не относится к этой проблеме: пакет считается потерянным не самим VPN-сервером, а TCP/IP-стеком (нашим либо удаленным). Если мы вешаем прокси поверх Tor, то потеря пакетов в любом сегменте ведет к пересылке внутри этого сегмента, вешаем VPN поверх Tor — потеря пакета где угодно ведет к пересылке от начала до конца. К тому же, придет еще и лишний пакет, который на самом деле не потерян а задержался. Оверхед второго варианта намного выше первого. Даже Tor с двойным заворачиванием работать будет, поскольку свойства такой сетевой среды остаются прежними (пересылки по-прежнему идут в том месте, где потери), и навесь даже 10 проксей поверх — все равно пересылки будут идти только между ними. Как выше сказано, есть разные сетевые уровни, и они решают разные задачи, и складывать их надо друг с другом в правильном порядке, чтоб всё работало.
Заметьте, что узкое место здесь не в том TCP, который между нами и Tor-нодами, между самим Tor-нодами, а также между Tor-экситом и VPN-сервером. Проблема именно в том TCP, который между нами и целью соединения (конкретным сайтом в интернете). Заствить все сайты сменить протокол не получится («Уважаемый гугл, замените, пожалуйста, у себя TCP на другой протокол, а то я не могу использовать поиск через Tor+VPN»?). Трафик до VPN-сервера будет доходить без проблем (тут мы всё можем сделать), но нужно, чтобы он пошел дальше и дошёл вовремя. Грубо говоря, корень проблемы в том, что VPN-сервер пересылает пакеты прозрачно, один к одному, он не пересоздаёт TCP-сессию, как прокси, поэтому и проблемы с потерью пакетов не могут быть решены локально, задействуя только тот участик сети, где они потерялись. И всё это из-за того, что VPN пересылает пакеты, а Tor — TCP-поток.
Казалось бы, можно на стороне VPN-сервера поставить прозрачную прокси, т.е., сделать так, чтобы до VPN-сервера трафик шёл обычно, а там уже VPN-сервер сам создавал новую TCP-сессию с сайтом. Действительно, это несколько умешьшило бы проблему, но тогда возникает вопрос «почему бы просто не поставить на него прокси?» — достаточно установить прокси на собственном сервере, и он будет создавать TCP-сессию с сайтом без лишнего оверхеда на пакетный уровень. Более того, можно использовать даже стандартный ssh -D, и ничего ставить не надо. Можно, конечно, сказать, что есть элемент удобства — у клиентов стоял бы стандартный VPN, а на сервере можно было бы установить intercepting proxy, но такое проксирование всё равно не будет полностью прозрачным: если сервер сам устанавливает TCP-сессию, он искажает пакеты, вмешивается в передачу служебной информации, что где-то может привести к глюкам. Есть, конечно, куча intercepting proxy, многое работает даже в ынтырпрайзе (те же CISCO), но оно всё не очень прямое, всё же правильное решение — использовать сетевые протоколы в правильном порядке: сначала VPN через UDP, потом Tor, потом прокси (если нужно), а VPN через TCP вообще не рекомендуется.
К слову, обсуждаемая проблема возникает, и если использовать VPN внутри VPN по TCP-протоколу. И даже простой VPN по TCP неидеален по этой же причине, но проблема не настолько серьезно вылазит, т.к. задержки низкие, на каналах же с длинными задержками VPN по UDP работает намного быстрее. Кстати, I2P работает через UDP протокол, поэтому по идее через него можно без ущерба пускать VPN, но с этим нужно разбираться и тестировать такую связку, потому что здесь могут вылезти другие скрытые проблемы.
комментариев: 17 документов: 0 редакций: 0
Помогло, спсб. Сделал по Методу 2, VPN перестал падать.
Перед заданием маршрутов:
После:
После #proxichains openvpn --config ...
Теперь трафик от юзера идет через Tor в обход VPN. Я так понимаю, что трафик от рута должен идти через VPN->Tor. Как настроить браузер Iceweasel, чтобы запустить его через VPN командой sudo iceweasel? Сейчас в настройках стоит
комментариев: 17 документов: 0 редакций: 0
Мне проще курочть готовый продукт Tails, который всегда вернется в первоначальное состояние и без следов в компе. И не хочется по "всяким VPN/SSH/proxy" лазить со своей рабочей оси – знания не те.
Схема VPN сквозь Tor мне теоретически интересна потому, что IPS никак не узнает, куда и почему идет траф. При этом exit-node не может снифать.
По поводу
Зачем sudo? Просто пропишите socks в настройках. Хотя если там прозрачная торификация, оно и без каких-либо прописываний должно заработать.
комментариев: 17 документов: 0 редакций: 0
Сделано.
К сожалению, если запускаю браузер из-под нормального юзера (из меню или терминала), то он обходит VPN и работает через Tor напрямую. Соксификация в браузере прописана Socks5 127.0.0.1 9063.
Попробуйте отключить все сетевые настройки в браузере (сокс), пусть он работает напрямую. И посмотрите, через что он пойдёт в сеть.
Интересно, во что система завернёт трафик браузера. Там, скорее всего, стоит прозрачное заворачивание всего юзерского трафика в Tor, то есть на прописанные маршурты системе пофиг, надо или менять правила iptables или, да, запускать прогу не от имени стандартного юзера.
Напишите вывод iptables-save (из-под рута), кстати.
комментариев: 17 документов: 0 редакций: 0
комментариев: 17 документов: 0 редакций: 0
В меню Tails есть возможность "Unsafe Web Browser". Этот браузер пошел в сеть из-под юзера через VPN-канал. Проверено по IP 93.115.84.194 на whoer.net
Значит, проблема решена? VPN-то работает через Tor.
Судя по iptables, в системе есть пользователь clearnet. Если под ним куда-то ходить, то iptables вмешиваться в роутинг не будет, то есть, всё должно пойти как Tor → VPN &rarr сайт. Но, может у вас уже и так всё работает.