id: Гость   вход   регистрация
текущее время 07:56 29/03/2024
создать
просмотр
ссылки

TOR over VPN


Возможно, данный вопрос уже обсуждался и ответы на него есть, но я не нашел и у самого не хватает ума как правильно впнировать (openvpn) TOR чтобы на выходе в сеть был тор, а не впн?
клиент(я) – ВПН – ТОР – инет
судя по тому какой видят IP у меня получается: клиент – ТОР (если он вообще работает) – ВПН – инет :(


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— Serpentador (01/06/2013 11:56)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
всё написано, спецом для даунов, так даже прочитать не могут


Даже два раза было написано. Но одно дело внимательно прочитать, а другое понять и уметь применить. Большое спасибо, что потратили свое время и расписали ответ, как для полного дауна.
— Гость (01/06/2013 15:16)   <#>
Запускаем Tails 0.18, Vidalia зеленеет, прописываем:
имхо. непонятно зачем вообще курочить готовый продукт? там по дефолту не предусмотрено использование VPN. причем, это LiveCD "амнезия", по окончании сеанса пользования все затирается и возвращается в исходное состояние.
— Гость (01/06/2013 22:40)   <#>
одно дело внимательно прочитать, а другое понять и уметь применить.

Даже не обладая технической грамотностью, можно вынести 2 момента для себя:
  1. Это не так просто, из коробки работать не будет (иначе эти сложности никто бы не наворачивал).
  2. Запуск из коробки с умолчальными настройками приводит к зацикливанию.
Кстати, радуйтесь, что сейчас есть guard'ы, которые редко меняются. Если бы их не было (как несколько лет назад), я даже не представляю, как можно было бы дёшево избежать нескольких таблиц маршрутизации. Писать скрипт, который распарсит статистику Tor'а, выудит оттуда все тысячи entry-нод и добавит их в качестве отдельных маршрутов в route? А если противник поднимет свой сервис на одной из таких нод, то вы соединитесь с ним напрямую, минуя как Tor, так и VPN, то есть, всё совсем плохо, так что никак без продвинутых плясок не обошлось бы.

Большое спасибо, что потратили свое время и расписали ответ, как для полного дауна.

Пожалуйста. Отпишитесь, если вам помогло и у вас заработало.

непонятно зачем вообще курочить готовый продукт?

Не у всех есть Linux в обычной инсталляции, который можно курочить. Дело не столько в амнезии, сколько в том, что окружение ОС в Tails у всех одно и то же (чего не сказать про железо), в то время как обычный ваш домашний Linux содержит массу косвенной информации о вашей неанонимной деятельности.
— Гость (02/06/2013 02:54)   <#>
А если противник поднимет свой сервис на одной из таких нод, то вы соединитесь с ним напрямую, минуя как Tor, так и VPN, то есть, всё совсем плохо

Сразу не сообразил, что в случае 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, чтобы не рушить его уже встроенные автоматику и страховку анонимности.

В соседнем топике уже давали совет, что «вообще не надо так делать», и вы хотите неправильного, но с технической точки зрения вопрос интересный, да и могут быть конкретные ситуации, когда именно такая конфигурация — наименьшее зло (другие не работают, или ещё какие тонкости есть).
— Гость (02/06/2013 05:15)   <#>
В качестве общего замечания: роутить трафик в Tor на основе маршрутов, само собой, нельзя, ибо маршруты могут быть и в обход. Тут нужно либо заворачивать трафик по юзерам, либо делать несколько таблиц маршрутизации, либо использовать соксификаторы. Если же трафик заворачивается в Tor по маршрутам, можно и другие атаки придумать, — например, давать ссылку http://192.168.1.1/, после чего запросы по ней пойдут в локалку, что спалит локальных пользователей Tor. В общем, уязвимость со ссылками на guard'ы — это только если ограничились тупо заворачиванием трафика через маршрутизацию, чего не стоило делать.

«вообще не надо так делать», и вы хотите неправильного

Кстати, оно неправильное не только с точки зрения анонимности, а вообще, с точки зрения и производительности и логики работы.

Для простоты можно вначале рассмотреть 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, но с этим нужно разбираться и тестировать такую связку, потому что здесь могут вылезти другие скрытые проблемы.
— Гость (02/06/2013 08:28)   <#>
fix:
Теперь что касается Tor через VPN: VPN через Tor — страшный изврат
Читать как «VPN через Tor» в обоих случаях.
— Serpentador (02/06/2013 13:10)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
Стараюсь внимательно разобраться со всем, что здесь написано.

Отпишитесь, если вам помогло и у вас заработало.


Помогло, спсб. Сделал по Методу 2, VPN перестал падать.

Метод 2:


Перед заданием маршрутов:



После:



После #proxichains openvpn --config ...



Теперь трафик от юзера идет через Tor в обход VPN. Я так понимаю, что трафик от рута должен идти через VPN->Tor. Как настроить браузер Iceweasel, чтобы запустить его через VPN командой sudo iceweasel? Сейчас в настройках стоит

— Serpentador (02/06/2013 15:52)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
непонятно зачем вообще курочить готовый продукт?


Мне проще курочть готовый продукт Tails, который всегда вернется в первоначальное состояние и без следов в компе. И не хочется по "всяким VPN/SSH/proxy" лазить со своей рабочей оси – знания не те.

Схема VPN сквозь Tor мне теоретически интересна потому, что IPS никак не узнает, куда и почему идет траф. При этом exit-node не может снифать.
— Гость (02/06/2013 16:44)   <#>
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
Вот этот маршрут лишний. У вас сейчас 2 дефолтных gw в таблице (это те, у кого 0.0.0.0 в первом столбце), а должен быть один. Попробуйте выполнить после запуска openvpn команду
# route delete default gw 192.168.1.1
В общем, цель — получить такую же таблицу, только без того маршрута, что я выше процитировал. Если delete вдруг убьёт в том числе и нужные маршруты, добавьте их снова руками.

По поводу
/sbin/route add -net YOUR_GUARD netmask 255.255.255.255 gw 192.168.1.1
я тут ступил немного. Можно писать короче:
/sbin/route add YOUR_GUARD gw 192.168.1.1
Если вдруг будет ругань на команду, перед YOUR_GUARD добавьте ещё опцию -host
— Гость (02/06/2013 16:46)   <#>
Как настроить браузер Iceweasel, чтобы запустить его через VPN командой sudo iceweasel? Сейчас в настройках стоит

Зачем sudo? Просто пропишите socks в настройках. Хотя если там прозрачная торификация, оно и без каких-либо прописываний должно заработать.
— Serpentador (02/06/2013 17:03, исправлен 02/06/2013 17:04)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
этот маршрут лишний
Можно писать короче

Сделано.


без каких-либо прописываний должно заработать

К сожалению, если запускаю браузер из-под нормального юзера (из меню или терминала), то он обходит VPN и работает через Tor напрямую. Соксификация в браузере прописана Socks5 127.0.0.1 9063.

— Гость (02/06/2013 17:56)   <#>
если запускаю браузер из-под нормального юзера (из меню или терминала), то он обходит VPN и работает через Tor напрямую. Соксификация в браузере прописана Socks5 127.0.0.1 9063.

Попробуйте отключить все сетевые настройки в браузере (сокс), пусть он работает напрямую. И посмотрите, через что он пойдёт в сеть.

Интересно, во что система завернёт трафик браузера. Там, скорее всего, стоит прозрачное заворачивание всего юзерского трафика в Tor, то есть на прописанные маршурты системе пофиг, надо или менять правила iptables или, да, запускать прогу не от имени стандартного юзера.

Напишите вывод iptables-save (из-под рута), кстати.
— Serpentador (02/06/2013 18:14)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
вывод iptables-save


— Serpentador (02/06/2013 18:40, исправлен 02/06/2013 19:31)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
Попробуйте отключить все сетевые настройки в браузере

В меню Tails есть возможность "Unsafe Web Browser". Этот браузер пошел в сеть из-под юзера через VPN-канал. Проверено по IP 93.115.84.194 на whoer.net

— Гость (02/06/2013 20:28)   <#>
Этот браузер пошел в сеть из-под юзера через VPN-канал.

Значит, проблема решена? VPN-то работает через Tor.

Судя по iptables, в системе есть пользователь clearnet. Если под ним куда-то ходить, то iptables вмешиваться в роутинг не будет, то есть, всё должно пойти как Tor → VPN &rarr сайт. Но, может у вас уже и так всё работает.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3