Как завернуть приложение на local host

[edis]

В Windows есть файл "host", в котором доменному имени ставится в соответствие ip адрес. Это позволяет перенаправлять на local host те приложения, которые лезут в интернет используя доменное имя (например, браузеры, icq ). С этим всё понятно. А что делать с приложением, которое лезет в интернет на конкретный ip адрес. Как его завернуть на local host (127.0.0.1)? Это нужно для того, чтобы сделать туннель при помощи программы httport, которая "слушает локальный хост". Сижу за шлюзом, практически все порты закрыты, даже сокс-порты. Программы, которые выполняют соксификацию не вкатывают. Поэтому большая просьба к специалисту в этом вопросе помочь с решением данной проблемы. Заранее благодарен.

 

[okun]

В Windows есть файл "host", в котором доменному имени ставится в соответствие ip адрес. Это позволяет перенаправлять на local host те приложения, которые лезут в интернет используя доменное имя (например, браузеры, icq ).

Не совсем так. Это позволяет явно задать соответствие ip-адреса доменному имени, например в случае, когда DNS-сервер недоступен.

А что делать с приложением, которое лезет в интернет на конкретный ip адрес. Как его завернуть на local host (127.0.0.1)? Это нужно для того, чтобы сделать туннель при помощи программы httport, которая "слушает локальный хост"

Конкретнее, какое именно приложение? В htpport есть же возможность port mappinga. В нем настраивается удаленный ip-адрес и порт, на который перенаправить запрос от приложения. Здесь же указывается и локальный порт, слушающий эти запросы. А в приложении вместо конкретного ip-адреса и порта указывается 127.0.0.1 и локальный порт, открытый httport для mappinga запросов на тот адрес.

Также httport может запустить и локальный socks-прокси. Тогда в приложении указывается адрес этого локального прокси и тогда весь трафик такого приложения будет идти через этот прокси на любые адреса.

Если приложение не умеет работать с сокс-прокси, тогда надо использовать программу-соксификатор, например freecap.

 

[edis]

Когда в приложении есть возможность указать адрес 127.0.0.1 и локальный порт, то проблем никаких нет. Приложение обращается на локальный хост, httport перехватывает запросы приложения, запаковывает и посылает по http-протоколу на htthost, где они распаковываются и посылаются дальше. Например, WebMoneyKeeper Classic у меня прекрасно работает. Хотя в программе и нет возможности указать адрес 127.0.0.1, но выручает файл финдовоза "host", где явно задаётся соответствие ip-адреса доменному имени.
Проблемы начинаются с приложением, которое: 1. используют не доменные имена, а конкретный ip-адрес; 2. в настройках программы нет возможности указать адрес 127.0.0.1. Сразу же на ум приходит попробовать соксификацию. Взять FreeCap (или SocksCap или ... - программ много), который запакует пакеты в socks протокол. У нас сокс порты на шлюзе закрыты, как следствие встроенный сокс-прокси в httport'у не используешь (если стоит галочка "использовать сокс-прокси", то httport отправляет сокс-пакеты не по туннелю, а напрямую) . Поэтому надо указать FreeCapу адрес 127.0.0.1. и сокс порт. Указываем httport'у слушать локальный сокс-порт и всё должно заработать. Но не тут-то было. Многие приложения не работают с родными серверами по сокс-протоколу. Например программы интернет казино. Все отосланные приложением пакеты, должны дойти в первозданном виде. В связке httport-htthost не помешала бы возможность отправлять по туннелю сокс-пакеты, а на htthost'у распаковывать их в исходный вид.
ПОЭТОМУ нужна программа, которая бы перехватывала всё посланное приложением и не изменяя заворачивала бы на 127.0.0.1, а httport посылал бы всё по туннелю. (Удивляюсь, почему ни в одном файерволе нет такой опции). ЛИБО нужно воспользоваться средствами Виндовоза, но я так подозреваю, что в Виндовозе нет такой возможности (а в Линуксе есть). Т.О. вопрос так и остаётся открытым:
КАК ЗАВЕРНУТЬ ВСЕ ПАКЕТЫ ПРИЛОЖЕНИЯ НА 127.0.0.1 НЕ ИЗМЕНЯЯ ИХ?
Помоему проблему описал хорошо. Жду ваших предложений. С нетерпением, поскольку покапавшись во всемирной паутине два месяца, я не нашёл решения данного вопроса и начинаю уже отчаиваться.

 

[okun]

Давайте разбираться ...

Для начала читаем.

Встроенный в httport SOCKS-модуль предназначен для приложений, для работы которых недостаточно одного отображаемого порта.

Httport использует два метода для обхода прокси: SSL (CONNECT) и Remote Host (TCP-over-HTTP). Когда выбрано Auto — пробует сначала первое, при неудаче — второе.

У нас сокс порты на шлюзе закрыты, как следствие встроенный сокс-прокси в httport'у не используешь (если стоит галочка "использовать сокс-прокси", то httport отправляет сокс-пакеты не по туннелю, а напрямую) .

Но Вы же и не должны подключаться к удаленному сокс-прокси, так как он у Вас работает локально в httport.
По идее должно быть так - если напрямую присоединиться к удаленному порту, используя метод CONNECT, не получается, тогда должен быть задействован режим HTTHost.

Многие приложения не работают с родными серверами по сокс-протоколу. Например программы интернет казино. Все отосланные приложением пакеты, должны дойти в первозданном виде. В связке httport-htthost не помешала бы возможность отправлять по туннелю сокс-пакеты, а на htthost'у распаковывать их в исходный вид.

Некоторые порты блокированы на публичных серверах HTTHost:

If you are using "Remote host" bypass mode AND you are using free public HTTHost, some of the services/ports are blocked.

Specifically, the following ports are open for tunneling on public HTTHost:
25, 80, 110, 119, 143, 1024+ except ports for well known P2P applications, such as Gnutella.

On the privileged HTTHosts available for registered users, all the ports are open except for those for P2P applications.

А может Ваше приложение использует UDP-протокол, который полностью не поддерживается HTTPort и из-за этого не работает?

По поводу невозможности указать ip в приложении, вот выдержка из FAQ:

Q: What if my software does not allow me to edit the address to connect to ?

1. If your software tries to connect to "some.host.on.the.net" (just like Napster does), you should append the following line

127.0.0.1 some.host.on.the.net

to the file
c:\winnt\system32\drivers\etc\hosts (for NT)
c:\windows\hosts (for 9x)

This will allow a local name resolution for this host, and it will be resolved to localhost. Just what we need.
Note: you may not have 'hosts' file, but 'hosts.sam' instead, which is a 'sam'ple file. You just copy 'hosts.sam' to 'hosts' and edit the new file.

2. If your software tries to connects to a predefined address like 123.45.67.89, this is much harder to fix. Please make sure that you are familiar with TCP/IP setup before proceeding. Or ask a guru friend for help

In brief - you should edit your TCP/IP parameters and add a new IP address to your network adapter. Thus your local machine will host two (or more) IP addresses: your previous IP address and 123.45.67.89. From this point TCP/IP layer will not route packets to 123.45.67.89 any farther than localhost.

Note, that this may prevent other local software from functioning. Do not touch except for the strongest need.

Удачи!

 

[edis]

Спасибо большое Okun за желание помочь. Я и не знал, что Httport не умеет работать с приложениями, использующими udp-протокол. В качестве примера приведу приложение "Hamachi". При работе программа для соединения с центральным сервером использует порты по протоколу TCP, для связи с другими пользователями используются порты по протоколу UDP. Теперь понятно, почему она у меня не работает.
Я никак не могу понять, как работает встроенный Socks-сервер в httport'у. Возьмём например программу WebMoneyCeeper. Htthost стоит у моего друга. Я настроил httport "классически" и всё замечательно работает. Если же я запускаю WMCeeper из под FreeCap или SocksCap, с настройкой "использовать сокс4-сервер 127.0.0.1:1080" и ставлю галочку в httport "запустить socks4 сервер" (в настройках httport больше ничего не меняя), то нифига не работает. Я не могу понять почему?
У меня в настройках httport стоит: "bypass mode - remote host".
По идее путь следования пакетов WMCeeper должен быть такой. WMCeeper отправляет пакеты "в своём родном виде", FreeCap перехватывает их, запаковывает в сокс-протокол и направляет пакеты на встроенный httport сокс-сервер по сокс-протоколу, на выходе с сокс-сервера эти пакеты находятся снова "в своём родном виде". Далее всё должно происходить также как и без использования FreeCap и встроенного сокс-сервера: httport запаковывает пакеты в http-протокол, отправляет их htthost'у, который их распаковывает и они уже идут по назначению "в своём родном виде". Так ли это? Почему не работает WMCeeper через сокс-сервер httport'а?
Если мы используем встроенный сокс-сервер httport (с участием FreeCap), то на выходе с сокс-сервера (до запаковки в http-протокол)пакеты находятся "в своём родном виде" или уже в другом?
Ну и глобальный вопрос, можно ли как нибудь протунелировать протокол UDP? Если бы у httport был встроенный сокс5-сервер, а не сокс4-сервер, то тогда httport поддерживал бы работу с протоколом UDP. Но встроенного сокс5-сервера нет, соответственно возникает исконно русский вопрос "Что делать?" Или мне закатать губу и пользоваться толко аськой, браузером и скайпом?

 

[x-smerch]

FreeCap от SocksCap чем отличается?

 

[okun]

Возможности FreeCap

 

[x-smerch]

+) возможности-то я читал, но багов прочитал на форуме еще больше. =(