Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Существуют ли in-process соксификаторы? 09.11.09 10:40
Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 09.11.09 10:45 Количество правок: 3
|
Программа работает с M$ SQL сервером через ADO.
Объекты ADO-подключений, насколько я знаю, не умеют работать через SOCKS-прокси.
Задача: заставить.
Насколько я знаю, есть внешние программы-"соксификаторы", которые прозрачно для процесса обволакивают его вызовы к винсоксу, и программа думает, что TCP соединения она делает как обычно, а на самом деле всё идёт через прокси.
Нужно сделать это для конкретной программы изнутри.
Как я это вижу в идеале: подключаю "соксифицирующую" dll, дёргаю из неё функцию "socksify" с параметрами нужного SOCKS-прокси, и после этого ВСЕ TCP-соединения, которые откроет программа, будут идти через SOCKS-прокси.
Заранее всем спасибо за советы
|
|
была такая штука 12.11.09 16:29
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
hummingbird socksifier
ставится на систему и потом задаёшь ей фильтрами какой трафик заворачивать в socks
Правда последний раз я её использовал в 2003
коля
|
| |
Да их море -- FreeCap, WideCap и проч... 12.11.09 16:51
Автор: HandleX <Александр М.> Статус: The Elderman
|
Интересует же вариант, чтобы ничего в систему не ставя, получить нужный эффект, программа сама "просит" об этом скажем некую dll.
Та же FreeCap использует технологию внедрения DLL в процесс...
А тут ничего внедрять не надо, прога сама говорит: "Ну пожалуйста..." ;)
У фрикапа доступны исходники, ща ковыряем их, скорее всего, подойдёт.
|
|
Не имеет значения, в каком виде представлен драйвер, будь то... 09.11.09 19:53
Автор: Den <Denis> Статус: The Elderman
|
> Программа работает с M$ SQL сервером через ADO. > Объекты ADO-подключений, насколько я знаю, не умеют > работать через SOCKS-прокси.
Не имеет значения, в каком виде представлен драйвер, будь то ADO/OLEDB или ODBC. За некоторым исключением, все они лезут на SQL сервер, порт TCP 1344.
> Задача: заставить. > Насколько я знаю, есть внешние программы-"соксификаторы", > которые прозрачно для процесса обволакивают его вызовы к > винсоксу, и программа думает, что TCP соединения она делает > как обычно, а на самом деле всё идёт через прокси. > Нужно сделать это для конкретной программы изнутри. > Как я это вижу в идеале: подключаю "соксифицирующую" dll, > дёргаю из неё функцию "socksify" с параметрами нужного > SOCKS-прокси, и после этого ВСЕ TCP-соединения, которые > откроет программа, будут идти через SOCKS-прокси. > Заранее всем спасибо за советы
Зачем заставлять драйверы работать через socks прокси, если подобная технология прекрасно может работать через NAT или мапинг порта?
|
| |
Потому что есть конторы, где нету NAT, но есть SOCKs. 09.11.09 20:46
Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 09.11.09 21:05 Количество правок: 3
|
> Не имеет значения, в каком виде представлен драйвер, будь > то ADO/OLEDB или ODBC. За некоторым исключением, все они > лезут на SQL сервер, порт TCP 1344. Полезут они на тот порт, какой скажешь в строке подключения, по умолчанию он 1433, M$ TDS протокол. Но это всё не важно. Важно то, что созданием TCP соединения я не занимаюсь, а занимается библиотека M$, и ничего с этим не поделать.
> Зачем заставлять драйверы работать через socks прокси, если > подобная технология прекрасно может работать через NAT или > мапинг порта? Потому что сабж. Поставят старый юзергейт и радуются -))
А если бы была возможность использования SOCKS в программе -- было бы фичастее.
|
| | |
Ну да, с "1344" я очепятался - запамятовал. 09.11.09 21:30
Автор: Den <Denis> Статус: The Elderman
|
> Полезут они на тот порт, какой скажешь в строке > подключения, по умолчанию он 1433, M$ TDS протокол. Но это > всё не важно. Важно то, что созданием TCP соединения я не > занимаюсь, а занимается библиотека M$, и ничего с этим не > поделать.
Ну да, с "1344" я очепятался - запамятовал.
> > Зачем заставлять драйверы работать через socks прокси, > если > > подобная технология прекрасно может работать через NAT > или > > мапинг порта? > Потому что сабж. Поставят старый юзергейт и радуются -)) > А если бы была возможность использования SOCKS в программе > -- было бы фичастее.
Хы-хы. Недавно на amicon.ru терли похожую тему... Там проблема с подключением VPN клиента по UDP:87
Древний юзергейт, обычно, ставят на 32-битную XP. Так что же мешает поднять дополнительно Windows NAT? Еще было предложено использовать связку Windows NAT и форточные порты squid и wipfw. При использовании только старого юзергейта (v2.8), можно использовать мапинг порта TCP:1433
|
| | | |
У них используются пароли на проксятине, если включить стандартный вендовозный NAT -- тырнет откроется для всех, кто вкурит нужный "шлюз по умолчанию". 09.11.09 21:46
Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 09.11.09 21:48 Количество правок: 1
|
Про маппинг порта можно поподробнее? Смогут ли с его использованием несколько человек с разных машин одновременно ломиться на сервер?
|
| | | | |
В Керио винроуте -- да. Сомневаюсь, что в Юзергейте иначе. 09.11.09 22:48
Автор: Lurga Статус: Elderman
|
|
| | | | | |
Млин! Че вы гоните? ) 10.11.09 04:33
Автор: Den <Denis> Статус: The Elderman Отредактировано 10.11.09 12:44 Количество правок: 3
|
Во-первых, с помощью wipfw, возможность NAT можно открыть только для некоторых узлов-отправителей и узлов/портов-получателей.
Во-вторых, не слишком хорошо знаком с Entensys UserGate, но в современном исполнении, этот продукт немногим отличается от современного Kerio Winroute Firewall. Эти два продукта очень похожи... Оба продукта умеют проводить авторизацию пользователя как в локальной базе пользователей и групп, так и в домене Windows NT+ (в т.ч. AD) и предоставляют практически идентичные возможности, но Entensys UserGate сильно переигрывает KWF по цене.
|
| | | | | | |
Мы чо? Мы ничо... 10.11.09 16:19
Автор: Lurga Статус: Elderman
|
> Во-вторых, не слишком хорошо знаком с Entensys UserGate, но > в современном исполнении, этот продукт немногим отличается > от современного Kerio Winroute Firewall. Эти два продукта > очень похожи... Оба продукта умеют проводить авторизацию > пользователя как в локальной базе пользователей и групп, > так и в домене Windows NT+ (в т.ч. AD) и предоставляют > практически идентичные возможности, но Entensys UserGate > сильно переигрывает KWF по цене.
Я просто в своё время довольно плотно работал с Керио винроут, а Юзергейт видел пару раз, так что по его поводу ничего путного сказать не могу.Что он догнал винроут по возможностям -- совершенно логично, зачем бы он иначе был нужен? :))
|
| | | | | | |
Я воще гнать не хотел, от корневого топика мы сильно отдалились ;) 10.11.09 11:22
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|