id: Гость   вход   регистрация
текущее время 15:06 29/03/2024
Автор темы: Гость, тема открыта 28/01/2012 22:53 Печать
Категории: софт, анонимность, приватность
создать
просмотр
ссылки

На форуме часто спрашивают одно и то же -


"Как указать произвольный exit node"
"Как подделать user-agent и другие заголовки"
"Как создавать цепочки тор-узлов и играть с настройками"


Если кто еще не в курсе, обратите внимание на этот опен-сорс проект:


http://sourceforge.net/projects/advtor/


Умеет все из вышеперечисленного + тонну других настроек.


 
На страницу: 1, 2 След.
Комментарии
— Гость (22/11/2012 15:08)   <#>
Конкретную ссылку на пруф, или не было.
То есть вы не потрудились почитать код прежде чем утверждать про отсутсвие специфичного кода, потом начали рассказывать про протоколы и пакеты. А ведь там всё проще, адрес назначения нужно как-то получить, в зависимости от фильтра делает это по разному и вполне себе специфично, даже по времени когда адрес необходимо извлекать. Почитайте пожалуйста код, прежде чем требовать пруфов. Или вам нужен линк к вебгиту?
— Гость (22/11/2012 15:32)   <#>

Ещё один "читатель кода"... Понимаете, если у вас системной картины в голове нет, вы можете хоть обчитаться коды на сях, ассемблерах, возмнить себя кулхацкером всей вселенной, но это вам не поможет, вы будете садиться в лужу постоянно.


Ничего не понял. Какой адрес назначения? 127.0.0.1? Понимаете, DNAT (rdr, redirections) работает для тысячи сервисов, как под виндой, так и под юниксами. Чем тут специфичен Tor, не ясно совершенно. Система и firewall сами отвечают за все internals, и в 999 случаев из тысячи там разумные дефолты, в которые лезть юзерам или прикладному софту нет никакой необходимости.

Например, тот же iptabels — это просто конечный автомат, который просто переписывает значения параметров IP-пакета, что-то запоминает, но не более того. В pf другая семантика (он сильно высокоуровнев, но не настолько универсален, как iptables), но суть та же: переписывание параметров IP-пакета, переброска его с интерфейса на интерфейс, изменение in на out. Всё.

Вы ещё расскажите тут, что проброс порта для ssh (это и есть DNAT/rdr) работает только потому, что ssh-сервер имеет специальную поддержку для таких случев. И проброс порта в DMZ на www-порт сервера с виндой работает потому, что виндовый http-сервер поддерживает специфику iptables, pf, ipfw, ipf и всех будущих ещё ненаписанных Unix-файерволлов.


Линк на конкретное указание специфики iptables и pf, хотя бы в коде (там же есть комментарии, да?). Но намного лучше — ссылку на указание на это в рассылке, где будет значиться «с другими fw это не заработает принципиально».
— Гость (22/11/2012 15:39)   <#>
Понимаете, если у вас системной картины в голове нет, вы можете хоть обчитаться коды на сях, ассемблерах, возмнить себя кулхацкером всей вселенной, но это вам не поможет, вы будете садиться в лужу постоянно.
Сейчас в луже вы, впрочем как всегда. И не надо навешивать ярлыков. Если вы думаете, что у вас системная картина по этому вопросу, то для вас это будет, несомненно, откровением, ибо это не так. Оставайтесь в этом состоянии, потому что переубеждать вас бессмысленно.
— Гость (22/11/2012 18:48)   <#>
Что и требовалось доказать. Ссылки нет, пруфов нет, объяснения нет, есть только голые заявления.

Мне под виндой никто не мешает написать собственную программу-обёртку, которая на лету будет делать что-то с выбранным пакетом и куда-то его перенаправлять. Файерволлы лишь автоматизируют этот процесс. Если завтра кто-то опубликует патч к tor на 5 строк и готовую инструкцию в Tor-wiki по прозрачной торификации, это ничему противоречить не будет. Строки в man tor
Requires OS support for transparent proxies, such as BSDs' pf or Linux's IPTables.
как бы намекают, что pf и iptables — лишь распространённые примеры файерволлов, умеющих нужный функционал, не более того.

Строго говоря, работа с пакетами подарзумевает 3 операции: заблокировать/пропустить (фильтрация), поменять параметры (трансляция адресов), поменять интерфейс/gw (рутинг). Удобно все три делать в рамках одной политики, и в pf, в общем-то, это так и делается, в iptables же, впрочем, рутинг вынесен вовне (man ip). Есть отличия между тем, как разные системы делают NAT (выбор диапазона портов и т.д.), но для приложений это абсолютно прозрачно. Если знаете соответствующее системное программирование, любую из этих операций можно применить к любому пакету руками, так что нет никакой магии и волшебных отличий. Более того, некоторые особо агрессивные программы под винду, как рассказывали, имеют даже собственную имплементацию TCP/IP-стека, независимую от системной.
— Гость (22/11/2012 19:26)   <#>
как бы намекают, что pf и iptables — лишь распространённые примеры файерволлов, умеющих нужный функционал, не более того.
Создаем коннект до гугла допустим, DNAT поменял адрес назначения, подключились к TransPort Tor'а. Откуда Tor узнает куда в оригинале был коннект? С точки зрения стандартного tcp стека и стандартных сокетов сеанс связи до 127.0.0.1, оригинал потерян. Вот тут и начинаются системно специфические особенности этих двух (с вариациями для pf) фильтров.

Почему вы требует пруфы, когда вы первый заявили:
Для вас это будет, несомненно, откровением, но Tor-клиент не содержит никакого iptables-специфичного или pf-специфичного кода.
Вот и доказывайте что это так, а не требуйте доказательств обратного.
— Гость (22/11/2012 21:44)   <#>

Ну хоть какой-то аругумент от вас услышал, а то всё вокруг да около. Tor — не единственная прозрачная прокси. Можно такими же правилами, как и для прозрачной торификации, завернуть трафик на localhost:8118 (privoxy, http-трафик) или на localhost:3128 (сквид, куча протоколов поддерживается). Как, по-вашему, сквид с этой задачей справляется?


То, что в винде это не будет работать принципиально, заявили вы, причём первый, а я только общий ответ гостю написал. Если по сути, то пусть ставит Proxifier и не мучается, получит свою прозрачную торификацию. Виндузятники подтверждают, что у них такая связка работает.
— Гость (22/11/2012 21:54)   <#>
Как, по-вашему, сквид с этой задачей справляется?
Так же как и Tor, пример получение адреса назначения для netfilter:

Для поддержки pf требуется больше кода, но заканчивается примерно так:

В Tor есть ещё поддержка natd из ipfw, там тоже по своему, впрочем и свой отдельный tcp-порт.
— Гость (22/11/2012 23:31)   <#>
Понятно. Да, я повспоминал и вспомнил, что, действительно, когда-то n лет назад этот функционал обсуждался в узком кругу, и народ тоже офигевал «как это Tor так умеет». Если не вру, ответ был в том, что Tor как-то выцепляет информацию из ядра.

Но мы отвлеклись от темы. Вопрос-то гостя был про то, как делать DNS-резолвинг через стандартный клиент Tor. Поскольку DNS будет всё равно резолвиться на exit-нодах, какой адрес для DNS-сервера укажет клиент, — совершенно неважно. Т.е. ваше возражение
Откуда Tor узнает куда в оригинале был коннект?
тут неприменимо. Но это и логично: в man tor никаких оговорок на ОС для опции DNSPort нет. Соответственно, заворачивание на 127.0.0.1:53 для каких-то прог (это винда умеет) тоже будет работать, равно как и заворачивание всех DNS-запросов искаропки. Называть ли такой DNS-резолвинг прозрачным или нет — вопрос чисто терминологический. Если системный резолвер — Tor (в качестве DNS-сервера значится 127.0.0.1), то для программ всё действительно прозрачно. Собственно, я об этом и написал:
прозрачная торификация для DNS-трафика.
Если замапить DNSPort на интерфейс/IP, смотрящий в локалку, то винда может работать и как DNS-сервер для всей локалки. Так что номинально всё в /comment58262 верно, а вашу последовавшую иронию я абсолютно не понял. Что вы этим хотели сказать? К чему претензия-то?
— Гость (22/11/2012 23:43)   <#>

Кстати, да, так и есть. За тем права на чтение для, например, /dev/pf и требуются.
— Гость (24/11/2012 00:52)   <#>

А, понятно: когда сел в лужу сам, можно сделать вид, что никто не заметил. Главное, вовремя успевать ловить момент, чтобы успеть сообщить
в луже вы, впрочем как всегда.
Хорошо, добавим на будущее этот пост в копилку. Два предыдущих топика там уже значатся.
— Гость (31/07/2013 06:12)   <#>
Proxifier для Windows отнюдь не панацея, так как он не умеет перенаправлять пакеты UDP и его разновидностей, гарантируется только TCP. Для себя надо держать в уме тот неприятный факт, что он продолжат справляться с DNS и завтра, после очередного обновления браузера или автоматического системного апдейта. По слухам с UDP лучше справится ProxyCap.
— Гость (31/07/2013 11:01)   <#>
что он продолжат справляться с DNS и завтра
Что вы этим хотели сказать?
— Гость (25/08/2013 02:49)   <#>
По слухам с UDP лучше справится ProxyCap.

через тор же нельзя пустить udp?
— Гость (25/08/2013 05:52)   <#>
Нельзя. Видимо, Гость имел в виду или заворачивание только DNS-трафика в Tor (он тоже UDP, его можно) или давал совет для случая использования в других целях (тот же VPN, например).
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3