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

TOR over VPN


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


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— Гость (03/11/2011 09:48)   <#>
Клиент -> OpenVPN -> Tor:
  • После запуска OpenVPN умолчальные настройки таковы, что все соединения с сетью идут через VPN. Если после запуска OpenVPN запустить Tor, последний пойдёт в сеть именно через VPN — т.е. то, что вам надо. Результат можно проверить снифером — должны ходить пакеты только между клиентом и VPN.

Клиент -> Tor -> OpenVPN:
  • После запуска Tor запускаем OpenVPN, указав ему в качестве прокси http или socks Tor. Но тут понадобятся нетривиальные игры с настройками OpenVPN, т.к. последний перепропишет себя умолчальным gw и траф "зациклится": OpenVPN будет пытаться работать через Tor, а Tor — общаться с нодами через VPN. Можно убрать "автоматику" из конфига, тогда после запуска OpenVPN он не будет портить настройки сети. Далее правильно добавляем руками новый gw в список, но не делаем его дефолтным. Далее нужным приложениям/программам надо будет указать вот этот OpenVPN'овский gw, а не Tor'овский. Во FreeBSD это можно сделать через setfib, в OpenBSD — через route (см. обсуждения здесь и здесь). Однако, это всё сложно — каждому приложению задавать. Я бы запустил какую-нибудь прокси, например, http-прокси (типа privoxy), указав ей работать через OpenVPN gw вышеуказанным способом. Потом всем приложениям можно указывать порт прокси.
  • Более красивое и чистое решение — делать либо виртуалку с рутером, либо выделенный Tor-рутер, тогда на его стороне всё можно прописать просто: запускаем Tor, запускаем OpenVPN через Tor как выше описано (без автоматического подняти gw), добавляем VPN gw руками, создаём дополнительную таблицу маршрутизации. Затем в pf.conf пакетам, получаемым из локалки, проставляем rtabel (routing table) и номер таблицы, и дальше они автоматически пойдут через нужный gw несмотря на то, что он не дефолтный (у меня это работало). Заодно и гайки средствами pf можно затянуть. Опции эти в pf относительно новые, но сейчас они должны быть лучше задокументированы, чем год назад...
  • Что касается Linux, там проставляются на пакеты какие-то флаги, а потом (на prerouting кажется) можно отсортировать по этим флагам средствами iptables — подробнее не знаю, но задача эта там точно решается.
  • Ещё один способ — настраиваем прозрачную торификацию через внешний Tor-рутер, после чего на клиенте запускаем VPN. Это, наверное, даже намного проще, чем всё вышеописанное, но потенциально менее безопасно.

По-хорошему, задача называется "раскидать разных юзеров на машине по разным интернет-каналам". Эта тема гуглится по термину policy based routing. В чисто Windows не решается никак (если без дополнительного Tor-рутера с UNIX-системой). Удачи.
— Serpentador (31/05/2013 13:39, исправлен 31/05/2013 13:50)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0

Помогите решить проблему, плз. Требуется запустить VPN через TOR. Соединение устанавливается, но потом обрывается.


Запускаем Tails 0.18, Vidalia зеленеет, прописываем:



Содержание xxx.ovpn:



В proxychains.conf прописан сокет



Соединение устанавливается, но через короткое время отваливается и больше не устанавливается. Как исправить?

— Serpentador (31/05/2013 14:22)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
В терминале видим:




И далее

— Гость (31/05/2013 14:55)   <#>
Если сменить цепочку, коннектит? Похоже проблема на стороне впн провайдера, чекают адреса клиентов по блеклистам и добавляют в фильтр.
— Serpentador (31/05/2013 15:13)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
При смене идентиты коннкетит, но потом прерывается. А если присоединяться к ВПН напрямую, то соединение не падает.
— Serpentador (31/05/2013 16:19)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
Выше указано, что при соединении получено предложение:



в котором стоит опция ping-restart 30. По этой опции и отключилось в 10:02:26. Вопрос, почему не отлючается при прямом соединении в обход Тора, а через Тор отключается.

Где искать проблему?
— Гость (31/05/2013 16:32)   <#>
Вопрос, почему не отлючается при прямом соединении в обход Тора, а через Тор отключается.

Где искать проблему?

Толку от поиска причины отключения, если сервер отклоняет все новые запросы на подключение. Этот фришный впн провайдер видимо так борется с подключением через прокси и etc, как считают в интернетах это настоящий honeypot от feds.
— Serpentador (31/05/2013 16:41)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
Может глупый вопрос – с этим ВПН удержать коннект через Тор не получится вообще? Если да, какие есть фришные ВПН, чтобы попробовать ВПН сквозь Тор?
— Гость (31/05/2013 16:59)   <#>
Serpentador, закажите тест у красных коммерческих сервисов. Не знаю как сейчас, раньше предоставляли. Стукните админу, попросите тестовый доступ. Бесплатно, иначе нет смысла. Тут пиарился недавно один серв, обратитесь, там же все чики-пуки?
— Serpentador (31/05/2013 17:03)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
Хорошая подсказка, спасибо. Какой серв пиарился, плз? Я пропустил...
— Гость (31/05/2013 17:46)   <#>

Например.
Аналогичных сервисов достаточно. В Гугл и далее по списку выдачи.
— Serpentador (31/05/2013 17:48)   профиль/связь   <#>
комментариев: 17   документов: 0   редакций: 0
спасибо
— Гость (31/05/2013 18:00)   <#>
Проблема может объяснятся проще и естественней. VPN переписывает настройки роутинга, после чего весь трафик должен слаться на виртуальный gw VPN-сервера кроме того, который предназначен собственно VPN-серверу. Но чтобы Tor работал, такого происходить не должно, потому что трафик самого Tor тоже должен слаться напрямую в сеть. Грубо говоря, имеете проблему курицы и яйца: VPN должен работать через Tor, но VPN переписывает настройки так, чтобы Tor работал через VPN. Так яйцо в курице или курица в яйце? Естественно, через какое-то время после коннекта траф перестаёт правильно роутиться и возникает таймаут, а дефолтные настройки openvpn таковы, что через не очень большой таймаут он делает автоматический рестарт. Только вот рестартнуться не получается, поскольку VPN должен пойти бы через Tor, но Tor'у уже перекрыта дорога в сеть VPN'ом, перетянувшим настройки на себя.

Читаем внимательно первый комент, там всё по полочкам разложено. Конфиги ваши не читал, да и не очень хорошо синтаксис его логов знаю, но чтобы указать на вышеозначенную проблему, этого знать и не надо.

Этот фришный впн провайдер видимо так борется с подключением через прокси и etc, как считают в интернетах это настоящий honeypot от feds.

FUD.
— Гость (01/06/2013 04:57)   <#>

Феерический дятел, ещё и советы раздаёт. Отмечу, что в первом же посте всё написано, спецом для даунов, так даже прочитать не могут:

Но тут понадобятся нетривиальные игры с настройками OpenVPN, т.к. последний перепропишет себя умолчальным gw и траф "зациклится": OpenVPN будет пытаться работать через Tor, а Tor — общаться с нодами через VPN. Можно убрать "автоматику" из конфига, тогда после запуска OpenVPN он не будет портить настройки сети. Далее правильно добавляем руками новый gw в список, но не делаем его дефолтным. Далее нужным приложениям/программам надо будет указать вот этот OpenVPN'овский gw, а не Tor'овский. Во FreeBSD это можно сделать через setfib, в OpenBSD — через route (см. обсуждения здесь и здесь).

Если есть толика разума: что, по-вашему, значит pull в конфиге? Поинтересуйтесь на досуге. Это вытяжка всех параметров роутинга с VPN-сервера. Что он вам даст, то и будет прописано. pull не при всех конфигуряциях будет полезен. Это раз.
Fri May 31 10:01:51 2013 ROUTE default_gateway=192.168.1.1
Fri May 31 10:01:51 2013 TUN/TAP device tun1 opened
Fri May 31 10:01:51 2013 TUN/TAP TX queue length set to 100
Fri May 31 10:01:51 2013 /sbin/ifconfig tun1 10.9.1.146 pointopoint 10.9.1.145 mtu 1500
Fri May 31 10:01:53 2013 /sbin/route add -net 93.115.84.194 netmask 255.255.255.255 gw 192.168.1.1
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
Fri May 31 10:01:53 2013 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.9.1.145
Fri May 31 10:01:53 2013 /sbin/route add -net 10.9.0.1 netmask 255.255.255.255 gw 10.9.1.145
Всё чёрным по-белому написано:
  • 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. Вот вам и проблема курицы и яйца. В итоге ни один пакет в сеть уйти так и не может.

Теперь включаем мозг и думаем, почему так получилось:

  • Метод 1: Очевидно, потому что не надо давать openvpn'у право на pull, ему надо руками указать роутинг в конфиге, убрав правило
    /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.9.1.145
    Тогда VPN не будет гробастать под себя роутинг по дефолту, но и пакеты заворачиваться по умолчанию в него не будут. Каждой проге придётся руками указывать, что её пакеты надо слать именно на туннелевский gw. Как это сделать? Вот тут и начинаются ОС-спцифичные пляски с несколькими таблицами маршрутизации и прочая и прочая.

  • Метод 2: Другой возможный вариант настройки — мы каким-то образом узнаём IP guard-нод Tor'а и считаем, что никуда более, кроме как к ним, напрямую он не коннектится, поэтому добавляем статическое правило в таблицу маршуртизации
    /sbin/route add -net YOUR_GUARD netmask 255.255.255.255 gw 192.168.1.1
    и так для каждого guard'а. Теперь Tor должен работать даже при смене дефолтного gw. После этого можно запустить openvpn штатным образом, ничего не меняя, и всё должно сработать.

Инструкция по пофиксу для метода-2:
  1. Запускаете Tor и смотрите, с какими Tor-нодами он соединяется непосредственно. Это будут guard'ы, они первые в цепочке Tor. Их, кажется, не более трёх, и меняются они очень редко (раз в месяц?).
  2. Прописываете статическую маршрутизацию для этих IP статически, как выше указано, выполняя команды в командной строке. Проверить, что получилось, можно через route -n
  3. Запускаете VPN как и раньше с proxychains, ничего не меняя в настройках.
  4. После запуска VPN проверяем маршруты в route -n. Если какие-то из нам нужных продолбались, добавляем их снова руками. Для удобства советую создать скрипт, куда добавить список команд из пункта 2.
Метод этот грязный, но пофикс быстрый. Красивее и концептуальней — через методы в первом посте.
— Гость (01/06/2013 06:03)   <#>
Сответую почитать матчасть по роутингу здесь.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3