TOR over VPN
Возможно, данный вопрос уже обсуждался и ответы на него есть, но я не нашел и у самого не хватает ума как правильно впнировать (openvpn) TOR чтобы на выходе в сеть был тор, а не впн?
клиент(я) – ВПН – ТОР – инет
судя по тому какой видят IP у меня получается: клиент – ТОР (если он вообще работает) – ВПН – инет :(
Ссылки
[link1] http://obsd.ru/8/?q=node/1705
[link2] http://www.obsd.ru/8/?q=node/1632
[link3] https://www.pgpru.com/comment64364
[link4] https://www.pgpru.com/comment65287
[link5] https://ru.wikipedia.org/wiki/Iproute2
[link6] https://www.pgpru.com/comment48431
[link7] https://www.pgpru.com/comment47334
[link8] https://www.pgpru.com/comment50392
[link9] https://www.pgpru.com/comment65356
[link10] https://www.pgpru.com/comment65392
[link11] https://www.pgpru.com/biblioteka/osnovy/fondpoleznyhpostov/anonimnostj
[link12] https://www.pgpru.com/comment40541
[link13] https://www.pgpru.com/comment22804
[link14] https://www.pgpru.com/comment6590
[link15] https://www.pgpru.com/novosti/2011/vtorbrowserpomeschenaeksperimentaljnajazaschitaotserjjoznojjstatisticheskojjataki
[link16] https://www.pgpru.com/comment65403
[link17] https://www.pgpru.com/comment35165
[link18] http://www.kd85.com
Клиент -> OpenVPN -> Tor:
Клиент -> Tor -> OpenVPN:
По-хорошему, задача называется "раскидать разных юзеров на машине по разным интернет-каналам". Эта тема гуглится по термину policy based routing. В чисто Windows не решается никак (если без дополнительного Tor-рутера с UNIX-системой). Удачи.
Помогите решить проблему, плз. Требуется запустить VPN через TOR. Соединение устанавливается, но потом обрывается.
Запускаем Tails 0.18, Vidalia зеленеет, прописываем:
Содержание xxx.ovpn:
В proxychains.conf прописан сокет
Соединение устанавливается, но через короткое время отваливается и больше не устанавливается. Как исправить?
В терминале видим:
И далее
Если сменить цепочку, коннектит? Похоже проблема на стороне впн провайдера, чекают адреса клиентов по блеклистам и добавляют в фильтр.
При смене идентиты коннкетит, но потом прерывается. А если присоединяться к ВПН напрямую, то соединение не падает.
Выше указано, что при соединении получено предложение:
в котором стоит опция ping-restart 30. По этой опции и отключилось в 10:02:26. Вопрос, почему не отлючается при прямом соединении в обход Тора, а через Тор отключается.
Где искать проблему?
Толку от поиска причины отключения, если сервер отклоняет все новые запросы на подключение. Этот фришный впн провайдер видимо так борется с подключением через прокси и etc, как считают в интернетах это настоящий honeypot от feds.
Может глупый вопрос – с этим ВПН удержать коннект через Тор не получится вообще? Если да, какие есть фришные ВПН, чтобы попробовать ВПН сквозь Тор?
Serpentador, закажите тест у
красныхкоммерческих сервисов. Не знаю как сейчас, раньше предоставляли. Стукните админу, попросите тестовый доступ. Бесплатно, иначе нет смысла. Тут пиарился недавно один серв, обратитесь, там же все чики-пуки?Хорошая подсказка, спасибо. Какой серв пиарился, плз? Я пропустил...
Например[link3].
Аналогичных сервисов достаточно. В Гугл и далее по списку выдачи.
спасибо
Проблема может объяснятся проще и естественней. VPN переписывает настройки роутинга, после чего весь трафик должен слаться на виртуальный gw VPN-сервера кроме того, который предназначен собственно VPN-серверу. Но чтобы Tor работал, такого происходить не должно, потому что трафик самого Tor тоже должен слаться напрямую в сеть. Грубо говоря, имеете проблему курицы и яйца: VPN должен работать через Tor, но VPN переписывает настройки так, чтобы Tor работал через VPN. Так яйцо в курице или курица в яйце? Естественно, через какое-то время после коннекта траф перестаёт правильно роутиться и возникает таймаут, а дефолтные настройки openvpn таковы, что через не очень большой таймаут он делает автоматический рестарт. Только вот рестартнуться не получается, поскольку VPN должен пойти бы через Tor, но Tor'у уже перекрыта дорога в сеть VPN'ом, перетянувшим настройки на себя.
Читаем внимательно первый комент, там всё по полочкам разложено. Конфиги ваши не читал, да и не очень хорошо синтаксис его логов знаю, но чтобы указать на вышеозначенную проблему, этого знать и не надо.
FUD.
Феерический дятел, ещё и советы раздаёт. Отмечу, что в первом же посте всё написано, спецом для даунов, так даже прочитать не могут:
Если есть толика разума: что, по-вашему, значит pull в конфиге? Поинтересуйтесь на досуге. Это вытяжка всех параметров роутинга с VPN-сервера. Что он вам даст, то и будет прописано. pull не при всех конфигуряциях будет полезен. Это раз.
- gw локалки — 192.168.1.1
- 10.9.1.146 — IP, который сажают на виртуальный сетевой интерфейс, tap, скорее всего.
- /sbin/route add -net 93.115.84.194 netmask 255.255.255.255 gw 192.168.1.1 — вот VPN-сервак сделал исключение для себя, чтобы трафик самого тунеля роутился правильно через gw провайдера.
- Fri May 31 10:01:53 2013 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.9.1.145 — это и последующие строчки значат прописывание дефолтным gw виртуальный gw тунеля 10.9.1.145.
Всё, на этом точка, п-ц маршрутизации. Любой пакет во внешку рождается с gateway'ем и будет кинут системой на дефолтный виртуальный интерфейс tap (0.0.0.0 — синоним default), потому что именно он связан с дефолтным gw (курите вывод route -n). При попытке уйти с виртуального интерфейса в сеть реально будет отправлен пакет на VPN-сервер, то есть на 93.115.84.194. Он бы туда и пошёл, да proxychains его заворачивает в Tor. Tor пытается отправить пакеты в сеть, но, блджад, не может, потому что дефолтный интерфейс теперь tap с IP-шником 10.9.1.146, поэтому пакеты Tor заворачиваются в VPN-тунель, а те, в свою очередь, опять в Tor. Вот вам и проблема курицы и яйца. В итоге ни один пакет в сеть уйти так и не может.Теперь включаем мозг и думаем, почему так получилось:
Инструкция по пофиксу для метода-2:
- Запускаете Tor и смотрите, с какими Tor-нодами он соединяется непосредственно. Это будут guard'ы, они первые в цепочке Tor. Их, кажется, не более трёх, и меняются они очень редко (раз в месяц?).
- Прописываете статическую маршрутизацию для этих IP статически, как выше указано, выполняя команды в командной строке. Проверить, что получилось, можно через route -n
- Запускаете VPN как и раньше с proxychains, ничего не меняя в настройках.
- После запуска VPN проверяем маршруты в route -n. Если какие-то из нам нужных продолбались, добавляем их снова руками. Для удобства советую создать скрипт, куда добавить список команд из пункта 2.
Метод этот грязный, но пофикс быстрый. Красивее и концептуальней — через методы в первом посте.Сответую почитать матчасть по роутингу здесь[link4].
Даже два раза было написано. Но одно дело внимательно прочитать, а другое понять и уметь применить. Большое спасибо, что потратили свое время и расписали ответ, как для полного дауна.
имхо. непонятно зачем вообще курочить готовый продукт? там по дефолту не предусмотрено использование VPN. причем, это LiveCD "амнезия", по окончании сеанса пользования все затирается и возвращается в исходное состояние.
Даже не обладая технической грамотностью, можно вынести 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. Это будет непросто, но можно[link5]. Естественно, с этим лучше играться и настраивать не под Tails, чтобы не рушить его уже встроенные автоматику и страховку анонимности.
В соседнем топике уже давали совет, что «вообще не надо так делать», и вы хотите неправильного, но с технической точки зрения вопрос интересный, да и могут быть конкретные ситуации, когда именно такая конфигурация — наименьшее зло (другие не работают, или ещё какие тонкости есть).
В качестве общего замечания: роутить трафик в 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, но с этим нужно разбираться и тестировать такую связку, потому что здесь могут вылезти другие скрытые проблемы.
fix:Читать как «VPN через Tor» в обоих случаях.
Стараюсь внимательно разобраться со всем, что здесь написано.
Помогло, спсб. Сделал по Методу 2, VPN перестал падать.
Перед заданием маршрутов:
После:
После #proxichains openvpn --config ...
Теперь трафик от юзера идет через Tor в обход VPN. Я так понимаю, что трафик от рута должен идти через VPN->Tor. Как настроить браузер Iceweasel, чтобы запустить его через VPN командой sudo iceweasel? Сейчас в настройках стоит
Мне проще курочть готовый продукт Tails, который всегда вернется в первоначальное состояние и без следов в компе. И не хочется по "всяким VPN/SSH/proxy" лазить со своей рабочей оси – знания не те.
Схема VPN сквозь Tor мне теоретически интересна потому, что IPS никак не узнает, куда и почему идет траф. При этом exit-node не может снифать.
По поводу
Зачем sudo? Просто пропишите socks в настройках. Хотя если там прозрачная торификация, оно и без каких-либо прописываний должно заработать.
Сделано.
К сожалению, если запускаю браузер из-под нормального юзера (из меню или терминала), то он обходит VPN и работает через Tor напрямую. Соксификация в браузере прописана Socks5 127.0.0.1 9063.
Попробуйте отключить все сетевые настройки в браузере (сокс), пусть он работает напрямую. И посмотрите, через что он пойдёт в сеть.
Интересно, во что система завернёт трафик браузера. Там, скорее всего, стоит прозрачное заворачивание всего юзерского трафика в Tor, то есть на прописанные маршурты системе пофиг, надо или менять правила iptables или, да, запускать прогу не от имени стандартного юзера.
Напишите вывод iptables-save (из-под рута), кстати.
В меню Tails есть возможность "Unsafe Web Browser". Этот браузер пошел в сеть из-под юзера через VPN-канал. Проверено по IP 93.115.84.194 на whoer.net
Значит, проблема решена? VPN-то работает через Tor.
Судя по iptables, в системе есть пользователь clearnet. Если под ним куда-то ходить, то iptables вмешиваться в роутинг не будет, то есть, всё должно пойти как Tor → VPN &rarr сайт. Но, может у вас уже и так всё работает.
Да, проблема решена:
1. VPN работает через Tor, приложение работает через VPN
2. познакомился с вопросом глубже, чем представлял себе
3. узнал о существенных особенностях схемы
Очень благодарю всех за неоценимую помощь в решении проблемы и желание помочь.
как то все перевернуто. вы уверены в своих утверждениях?
1. Tor через VPN – что по-вашему видит провайдер?
2. VPN через Tor – а в этом случае?
если честно, последний вариант мне вообще не понятен. зачем? ну да ладно..
Зы: сокр. ISP от англ. internet service provider.
хотелось бы уточнить следующее: у вас цепочка фиксированная? в заданный промежуток времени не меняет узлы? если меняет, то каким образом канал VPN не обрывается? или он каждый раз реконнектится, как только меняется выходная нода?
вот этот вопрос меня интересовал. а как быть с тем что Тор работает через ТСР? Тср через Udp?
в "японском проекте" рекомендуется использование TCP. это их особенность построения сети?
В первом случае видит факт использования Tor, во втором – VPN, очевидно. В обоих случаях фиксируется дата, время, направление объем переданных данных.
Tor работает через VPN. VPN это такая виртуальная сетевушка которая как-бы виртуально подключена к проводу где-нибудь в Амстердаме. Соответственно через VPN идет всё что может идти через сетевуху, а какой там ниже транспорт – скрыто от конечного приложения. UDP лучший транспорт для VPN с точки зрения качества связи.
Как было сказано, UDP работает хорошо если ему не создают искусственных трудностей, TCP работает всегда. Бывают говнопровайдеры режущие длинные UDP пакеты или выделяющие под них самый низкий приоритет в целях борьбы с торрентами, они конечно пидорасы, но не всегда есть альтернатива. VPN по TCP часто вешают на портах 80 и 443 чтобы наебать слишком хитрых провайдеров, как правило помогает.
да вижу )) 443, 995 и 465 (почтовые ssl\tls)
Если бы файерволл был отключен, он бы у всех так шёл, да, но файерволл (iptables) настроен так, чтобы не пускать напрямую в сеть никого (в том числе, root'а), кроме пользователя clearnet. Раз вы всё равно не пользуетесь подстраховкой от файерволла, его с таким же успехом можно не обходить через «Unsafe Web Browser», а вообще отключить.
Вы от Tails почти ничего не используете сейчас. С тем же успехом можно было бы взять почти любой Linux LiveCD и работать с него. Просто в Tails, если доводить до ума, надо сначала выполнять кучу команд с отключением того, что встроено, а потом дополнять новыми командами, которых не хватает, а в стандартном LiveCD отключать ничего не пришлось бы. Это, конечно, мелочи, но это так, на уровне общих замечаний. Есть ещё такой момент, как подборка «правильного для анонимности» софта. С этим на Tails, наверно, лучше, чем на других LiveCD.
В схеме «VPN-сервер → Tor-сеть → сайт» ISP тоже не узнает, причём VPN-сервер будет служить транзитом шифрованного трафика, поскольку Tor-клиент будет запущен у вас, а не на VPN-сервере. Если хочется избежать снифа на exit-нодах ценой лучшего профилирования, есть замечательная вещь, называется ssh. Запускаем proxychains ssh -D ПОРТ name@server, прописываем в браузере ПОРТ в качестве сокса и вперёд. Т.е. просто добавляем ещё один сокс с шифрованием на выходе из Tor-сети. Всё будет идти по ssh-протоколу, потому надёжно шифруется.
Есть куча сервисов, раздающих ssh даром, но потерпят ли они транзитный трафик в интернет, не знаю. Если есть собственный купленный VPS, то всё проще: ssh там будет включен по умолчанию, пароль на рута написан в личном кабинете.
Всегда пожалуйста.
Не забывайте, что в той схеме, которую используете, подстраховок никаких нет. В Tails настроено так, что анонимный пользователь (я так понимаю, amnesia) не может послать пакеты никуда, кроме как на локальные IP:порт, на которых слушает Tor-клиент. Все остальные попытки будут зарезаны. В вашем же случае настройкой iptables надо сделать так, чтобы amnesia (или какой другой пользователь, которым пользуетесь для серфинга по интернету), не мог послать ничего в обход VPN. В том, как у вас сейчас работает, этого не сделано. Т.е., amnesia страхуется, но вы пользуетесь не ей, а, по ходу, clearnet. Соответственно, любая опечатка в командной строке (забыли написать proxychains перед openvpn или ещё что) или ошибка в ваших действиях, или уязвимость в софте элементарно обеспечивают полный деанон. Т.е. риск таков, что трафик в случе ошибки пойдёт не как Tor-сеть → VPN-сервер, а просто напрямую на целевой сайт с вашего же IP.
Если цепочка не будет рваться длительный срок, анонимности вообще кирдык может прийти. Это одна из причин, по которой не рекомендуют[link7] качать большие файлы и даже запускать софт, который постоянно держит соединение:
Если вдруг цепочка всё же оборвётся по каким-то причинам, OpenVPN-клиент должен попытаться пересоединиться с VPN-сервером снова. Так оно по умолчанию работает.
Капитан очевидность хочет напомнить, что VPN делает универсальный ethernet-туннель и виртуальный сетевой инфтерфейс (обычно tap, но иногда tun) независимо от того, поверх чего этот VPN положили (UDP или TCP). Собственно, поэтому VPN и есть универсальный способ перенаправления всего трафика через хост.
Нет, это предположения.
1. VPN-трафик (и адрес получателя?)
2. Tor-трафик и ничего более (DNS, NTP опускаем)
Здесь смысл в попытке использовать готовое решение, которому я доверяю с позиции своих скудных знаний. Я не смогу засунуть Tails в VPN. Самостоятельно поднять "самодельный Tails" не хватит знаний. Показалось, что проще засунуть VPN в Tor.
Не фиксировал ее, все должно быть по дефолтным настройкам Tails.
Кажется, при смене выходной ноды VPN не обрывается. Раз в час выполняется
не слишком ли шоколадно получится vpn – tor – ssh ) ping не менее 500 ms? где-нибудь что-нибудь затеряется в передачи данных.
ну вот, значит и здесь провайдер не видит. только в этот канал вы еще и Тор запускаете. имхо, дополнительной шифрование, если vpn шифрует конечно.
а вот это как раз и не лучше. к vpn, по моему мнению, провайдер отнесется мнее подозрительно, чем к Тор, вокгруг которого последнее время столько возни.
Обходить ФВ это не цель. Выше предложили отключить сетевые настройки в браузере. Ковыряясь, нашел «Unsafe Web Browser» и попробовал, не зная, что творю. Вообще-то хотелось бы, чтобы браузер пошел в сеть не обходя ФВ. Не пойму, где долблюсь головой о стену:
– Vidalia заворачивает траф на 127.0.0.1 9050
– sudo proxychains заворачивает openvpn на Socks4 127.0.0.1 9050
– в браузере стоит Socks5 127.0.0.1 9063
По какой причине браузер нормально не проходит в VPN? Это же не в обход ФВ, кажется. Или ФВ "считает", что траф, предназначенный для VPN – это не тот, который предназначен для сокета Tor/Vidalia? Но, оба эти трафа, ведь, на одном сокете.
Извините, Вам, наверное, смешно такое читать.
Advanced – Tor Control: Use Unix domain socket (ControlSocket) – Path: /var/run/tor/control
так по умолчанию.
наверно потому, что ему явно указано идти на сокс5 127.0.0.1 9063
это iceweasel просто настроен не сохрянять куки, историю и т.д. без настроек proxy\socks поэтому то он у вас и проскакивает в VPN, ну теперь в proxychains -> тор
iptables-save видите? Трафик от amnesia разрешается только на порты Tor. Попытка прямой отсылки пакета в сеть (это надо для VPN) режется, поскольку ни одно правило под этот случай не подходит.
Адрес — нет. Только адрес VPN-сервера.
Это как?
Да, смена ключа в VPN должна происходить время от времени согласно протоколу OpenVPN. Сам канал при этом, естественно, не обрывается.
Тред не читай, сразу отвечай. Что сказать-то хотел, собственно? Всяко не хуже, чем VPN-сервак после Tor'а.
FUD, ни чуть не менее, особенно, если это не местный VPN-сервер, а IP какого-то сервиса за бугром для всех (VPN организации, который нужен бывает по работе, легко отличить от таковых). К тому же, если кто-то что-то натворит из клиентов VPN-провайдера, провести перебор всех его клиентов будет намного проще, чем перебрать всех пользователей Tor.
Обходить — значит, пускать трафик под тем юзером, к которому не применены блокирующие и страховочные политики. Для простоты считайте, что при использовании «Unsafe Web Browser» никакого файерволла нет. Советовал вам я.
Почему вы решили, что браузер должен идти в VPN? Его трафик видалия заворачивает на порт Tor'а, вы же сами это и пишете. Если же вы включаете соединение напрямую, его трафик будет заблокирован файерволлом, потому что там, по умолчанию, в Tails, такие правила iptables.
Да, не тот. Файерволл фильтрует по портам и IP. Для работы в VPN надо иметь право посылать пакеты на какой угодно IP:порт с сетевого интерфейса tun1 и IP=10.9.1.146. Для работы же с Tor надо иметь право посылать что угодно с интерфейса lo и IP=127.0.0.1 на всё тот же IP=127.0.0.1 и порт=9050. Разницу чувствуете?
Сокеты тут ни при чём.
Это не смешно, это скорее annoying. Человек ещё не научился ходить, но просит объяснить, как ему подготовиться к полёту в космос. Или человек, которые не представляет, что находится под капотом машины и никогда не работал руками, но хочет чтобы другие люди его руками поменяли ему движок и затюнинговали тачку, да ещё так, чтобы и безопасно было, и ездила она хорошо.
Я бы посоветовал изучить, как работает iptables, причём не браться сразу за амбициозные задачи, а порешать для начала простые примеры, чтобы понять, как он работает, научиться фиксить проблемы и искать ошибки. Ну, и заодного базовые понятия работы с сетью уяснить: что такое сетевой пакет, какие у него параметры, как по ним фильтрует файерволл. Что такое параметры пакета (src IP, dst IP, src порт, dst порт), сетевой интерфейс, как задаётся (хотя бы простейший) роутинг в сети. Ну, т.е. самые-самые основы компьютерной грамотности, иначе без этого вам не будет понятно, что такое файерволл вообще. На самом деле файерволл — это такая машинка, которая пропускает пакет или не пропускает в зависимости от вышеприведённых параметров пакета и сетевого интерфейса либо ещё, помимо того, модифицирует указанные поля в сетевом пакете. Математически iptables — конечный автомат.
Кстати, вам никто не мешает отключить iptables совсем, всё равно файерволлом не пользуетесь сейчас. В /comment50392[link8] в конце написано, что для этого надо выполнить. Если так сделаете, под стандартным браузером всё тоже будет идти в VPN, только сокс-прокси в настройках сети там отключите, т.е., чтоб был direct connection.
Гость[link9], таким образом, когда вы идете по подземному переходу, с вертолета видно вас, а не переход.
Тот Гость правильно написал, это разновидность фингерпринтинга. Не слышали? Иногда pgpru полезно почитывать.
Полезно[link10], не спорю. Почитываете?
По-моему, он видит VPN-соединение. А по-вашему?
В этом случае провайдер видит соединение с сетью Tor.
Так что там про фингерпринтинг сказать-то хотели?
Когда вы фигу в кармане держите, что
видит провайдервидно, карман или фигу?Задавая вопрос, думал, что будет не сложнее, чем "включить" PGP-шифрование в мэйловый клиент (условно, конечно). Благодаря дискусси уяснил себе комплекс требуемых знаний.
Не-а. Точней, бывает, но редко, в основном пишу[link11].
Хотели сказать, что ирония там ни к чему. Более того, часть атак по фингерпринтингу шифрованного трафика работают не только против VPN, но и против Tor. И если Tor хоть как-то затачивался на анонимность (хотя иные всё равно ругают[link12] его за padding), то openvpn — никогда. По умолчанию там пакеты разного размера, отправка идёт в слишком оптимизированные времена, поэтому самые упоротые модфиицируют OpenVPN так, чтобы размер пакетов был одинаковым, пакеты отправлялись по расписанию и т.д. Впрочем, если через OpenVPN гонится Tor-трафик, фингерпринтинг не так страшен.
Это уже радует :)
Вообще, есть много легко формулируемых задач, решение которых достаточно нетривиальны. Например: ПК подключен к двум провайдерам связи одновременно. На ПК заведено два пользователя. Надо сделать так, чтобы трафик одного пользователя шёл только через одного провайдера, а трафик другого — только через другого. И всё, ппц, без множественных таблиц маршрутизации и продвинутых фич в ядре такое не решить.
Гость (03/06/2013 20:32) вообще эти вопросы были адресованы господину-товаристчу Serpentador дабы он задумался над этими вопросами да почитал чего-нибудь. у него сложилось впечатление, что vpn через tor "секьюрней" чем наоборот, как бэ провайдер чего то там меньше видит.
в Винде?:)
И это у вас, стоит признать, хорошо получается.
Это верно, если развивать тему и вдаваться в детали. А вопрос-то был простой, на самом деле: "что видит провайдер". И в этом[link9] комментарии был дан принципиально неверный ответ, хотя для автора того поста "очевидный". А вы пишите, что Гость[link9] правильно написал. Зачем? Для чего?
ТроллингКонтрирония?Вот. И в случае, когда что-то гонится через что-то, фингерпринт "не так страшен", не важно, тор через впн, или наоборот. Мы же рассматриваем случаи с комбинацией впн и тор, так зачем отвлекаться на фингерпринт? Можно было еще иронизировать про мосты и обфускацию, чего ж вы?
Вы имеете ввиду через две сетевухи к ПК или ПК через роутер, роутер к двум провам? Второй вариант предпочтительнее, на мой взгляд.
Я же, как правило, склоняюсь к простым решениям на практике и такие задачи, как два прова на одном ПК можно рассмотреть в теории, но на практике зачем? Как правило, стандартная схема — один пров – несколько ПК. А один ПК (не роутер) – несколько провов – это легкий изврат. Нет, у каждого свои
тараканызадачи и свои варианты их решения, но нагромождать, усложнять, на мой взгляд, не самая лучшая затея. Сюда же относится схема "впн через тор".Гость[link16], в общем-то да. Предлагаю вынести вопрос на открытое голосование, что видит пров?)) Как видите, мнения немного разделились))
Не так много систем умеет несколько таблиц маршрутизации. Из мне известных: Linux, OpenBSD, FreeBSD. Например, NetBSD не умеет. Потом, как разруливать трафик по разным каналам в зависимости от юзера? Ну, допустим, pf в OpenBSD это умеет, но это же самое может не взлететь во FreeBSD. В Linux, конечно, работает, но там это делается чуть по-другому.
Ах, да, признаю. Я тоже ступил. Ну ответ-то правильный, за исключением того, что он случаи 1 и 2 местами перепутал (и, скорей всего, по случайности, а не по незнанию).
Да, две сетевухи в ПК.
К этой задаче элементарно своядтся куда более практические (но объяснять проще на двух сетевых, каждая к своему прову), такие как: провайдер один, ПК один, но трафик одного юзера надо пустить в интернет напрямую, а трафик другого — через VPN. Или, при таких же условиях, одного юзера через VPN, а другого через прозрачную торификацию.
Такое тоже бывает. В OpenBSD решить эту задачу даже проще, если на роутере и на ПК OpenBSD. На клиентах проставляем метки, дальше на роутере фильтруем по меткам (это так называемая «задача о раскраске трафика», если ничего не путаю), а вот когда пакет сразу рождается на роутере, присвоить ему правильный gw проблематично. Начинаются извраты (кажется, оно и в Linux так) типа тех, когда пакет рождается на одном интерфейсе с одним gw, а потом надо средствами firewall/ip/iproute2 перебросить его на другой интерфейс и сменить ему gw. Года 3 назад я с неделю мучился над этой задачей, но решить её так и не смог (OpenBSD была). Впрочем, там на тот момент это были совсем свежие опции, плохо документированные, глючные и т.д. и т.п. Сейчас, неверное, уже получилось бы. Тем не менее, разброс по разным провам для транзитного трафика я делал, всё было ОК. Интересно, что роутер может ретранслировать пакеты из одной сети в другую вообще буквально, т.е. не меняя у них ни MAC, ни src IP на свой собственный. В общем, машинерия внутренняя там не самая простая, что-то новое я понял, но явно не до конца.
«Спасибо за высокую оценку нашей работы...» ©
сейчас есть коробочные роутеры с 2-я wan, но по стоимости за эти деньги можно купить 3 отдельных роутера.
Адекватная оценка. Спасибо вам за ваши старания, опыт и документы с комментариями.
Спасибо всем, кто вносит свою лепту и развивает сайт, будь то комментарий, документ или топик.
Роутер можно собрать на старом ПК (0-100 баксов) да такой, что в принципе даст фору коробочным за $500 и выше.
А вообще есть SOHO-роутеры которые не монстры, но монстрики, я б так сказал. И по стоимости они сверхдемократичны. По функционалу – на уровне решения задач вплоть до ISP. По размеру – с пачку сигарет. Стоят они столько, что самое дешевое барахло, типа самых младших моделей D-link, возможно, уже снятых с производства, стоит лишь немногим дешевле, о каких 3 отдельных роутерах речь? Цена не дотягивает даже до 100 бакинских, в некоторых случаях и до 60-70.
Спасибо. Вклад других участников и гостей, которые задают продуманные и интересные вопросы, стимулируя дискуссию, не менее важен.
Помнится, какое-то время назад пиарились[link17] Soekris[link18]'ы в качестве железа под OpenBSD-роутеры. Правда, цена их на тот момент мне дешёвой не показалась.
А D-Link не может относится к классу SOHO? Мне кажется, это просто устройства, типа Small Office Home Office – малый офис, домашний офис, поэтому необходимо уточнение какие могут быть "мностриками". Микротик?