Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Потому что есть конторы, где нету NAT, но есть SOCKs. 09.11.09 20:46 Число просмотров: 3575
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 09.11.09 21:05 Количество правок: 3
|
> Не имеет значения, в каком виде представлен драйвер, будь
> то ADO/OLEDB или ODBC. За некоторым исключением, все они
> лезут на SQL сервер, порт TCP 1344.
Полезут они на тот порт, какой скажешь в строке подключения, по умолчанию он 1433, M$ TDS протокол. Но это всё не важно. Важно то, что созданием TCP соединения я не занимаюсь, а занимается библиотека M$, и ничего с этим не поделать.
> Зачем заставлять драйверы работать через socks прокси, если
> подобная технология прекрасно может работать через NAT или
> мапинг порта?
Потому что сабж. Поставят старый юзергейт и радуются -))
А если бы была возможность использования SOCKS в программе -- было бы фичастее.
|
|
<networking>
|
Существуют ли 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 <Денис Т.> Статус: 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
|
|
Про маппинг порта можно поподробнее? Смогут ли с его использованием несколько человек с разных машин одновременно ломиться на сервер?
|
| | | | |
В Керио винроуте -- да. Сомневаюсь, что в Юзергейте иначе. 09.11.09 22:48
Автор: Lurga Статус: Elderman
|
|
|
| | | | | |
Млин! Че вы гоните? ) 10.11.09 04:33
Автор: Den <Денис Т.> Статус: 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
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
