> Программа работает с M$ SQL сервером через ADO. > Объекты ADO-подключений, насколько я знаю, не умеют > работать через SOCKS-прокси.
Не имеет значения, в каком виде представлен драйвер, будь то ADO/OLEDB или ODBC. За некоторым исключением, все они лезут на SQL сервер, порт TCP 1344.
> Задача: заставить. > Насколько я знаю, есть внешние программы-"соксификаторы", > которые прозрачно для процесса обволакивают его вызовы к > винсоксу, и программа думает, что TCP соединения она делает > как обычно, а на самом деле всё идёт через прокси. > Нужно сделать это для конкретной программы изнутри. > Как я это вижу в идеале: подключаю "соксифицирующую" dll, > дёргаю из неё функцию "socksify" с параметрами нужного > SOCKS-прокси, и после этого ВСЕ TCP-соединения, которые > откроет программа, будут идти через SOCKS-прокси. > Заранее всем спасибо за советы
Зачем заставлять драйверы работать через socks прокси, если подобная технология прекрасно может работать через NAT или мапинг порта?
Существуют ли 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
Интересует же вариант, чтобы ничего в систему не ставя, получить нужный эффект, программа сама "просит" об этом скажем некую dll.
Та же FreeCap использует технологию внедрения DLL в процесс...
А тут ничего внедрять не надо, прога сама говорит: "Ну пожалуйста..." ;)
У фрикапа доступны исходники, ща ковыряем их, скорее всего, подойдёт.
Не имеет значения, в каком виде представлен драйвер, будь то...09.11.09 19:53 Автор: Den <Денис Т.> Статус: 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 <Денис Т.> Статус: 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
Во-первых, с помощью 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
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
