- Место встречи двух клиентов, сидящих за НАТами.,
 SergeiZz, 13:36 , 11-Апр-05 (1)>Кто-нить писал такое? Какие-нить идеи?
Если на обоих шлюзах Web серверы; клиенты из-за NAT обращаются к
виртуальному хосту по SSL; срабатывает сценарий на Perl, Ruby (PHP, eRuby),
который устанавливает соединение в локальную сеть.
По сравнению с прокси преимущества будут, если на Web сервер переносится
часть функциональности, иначе разница не велика (механизм сессий, например,
реализовывать самому не так уж и долго), да и обмен данными будет по HTTP.>p.s. пока что думаю написать некое подобие прокси (на яве, из удобства).
>будет принимать соединение с одного из концов, ставить его в стек,
>когда придет соединение с другой стороны начнет в цикле передавать траффик
>с одного соединения на другое и обратно.
Клиент соединяется с прокси; прокси клонирует себя для поддержки клиента;
клон дозванивается в локальную сеть и читает-пишет туда-сюда (есть
несколько стандартных схем для читать-писать).
Если писать на Ruby, то на Gserver минут эдак за 15-20 можно набросать
работоспособную версию (с пулом потоков, журналированием, et caetera).
На Java, думаю тоже есть столь же крутая библиотека.
- Место встречи двух клиентов, сидящих за НАТами., Tim, 14:16 , 11-Апр-05 (3)
>>p.s. пока что думаю написать некое подобие прокси (на яве, из удобства).
>>будет принимать соединение с одного из концов, ставить его в стек,
>>когда придет соединение с другой стороны начнет в цикле передавать траффик
>>с одного соединения на другое и обратно.
>Клиент соединяется с прокси; прокси клонирует себя для поддержки клиента;
>клон дозванивается в локальную сеть и читает-пишет туда-сюда (есть
>несколько стандартных схем для читать-писать). Клон не сможет получить доступ во внутреннюю сеть. Сеть за НАТом. Моя схема предполагает третью сторону: [Админ]---[НАТ1]-->[proxy]<--[НАТ2]---[Клиент]
- Место встречи двух клиентов, сидящих за НАТами., SergeiZz, 15:10 , 11-Апр-05 (5)
>Моя схема предполагает третью сторону:
>
>[Админ]---[НАТ1]-->[proxy]<--[НАТ2]---[Клиент]
Это не прокси тогда, а сервер.
Админ тогда просто привилигерованным клиентом становится.Я думал, есть клиент и сервер, работающие в локальной сети, а нужно одного
из них вытащить за NAT.
А тут что за прокси такой?
- Место встречи двух клиентов, сидящих за НАТами., StSphinx, 13:49 , 11-Апр-05 (2)
>Написали софтинку для работы руководства с персоналом (ремот админ по сути). Но
>на практике оказалось что и руководство и персонал сидят за НАТом.
>Ни там, ни там преодолеть это условие нельзя (разные провайдеры, дебилы
>в службе поддержки). Поэтому требуется програмное решение. (Пробросить порт на НАТе
>не предлагать, это решение уже отмели).
>
>Кто-нить писал такое? Какие-нить идеи?
>
>p.s. пока что думаю написать некое подобие прокси (на яве, из удобства).
>будет принимать соединение с одного из концов, ставить его в стек,
>когда придет соединение с другой стороны начнет в цикле передавать траффик
>с одного соединения на другое и обратно. Чем плохи уже готовые решения - desproxy, stunnel ?
- Место встречи двух клиентов, сидящих за НАТами., Tim, 14:19 , 11-Апр-05 (4)
>Чем плохи уже готовые решения - desproxy, stunnel ? Ещё не знаю. Счас сижу читаю их описания, но что-то мне подсказывает что эти решения не для моего случая. Я ищу решение с применением третьей стороны т.к. хоть убей не понимаю как 2 клиента из-за НАТа могу содиниться напрямую. Установка какого либо софта у клиентов исключена.
- Место встречи двух клиентов, сидящих за НАТами., SergeiZz, 15:29 , 11-Апр-05 (6)
>Я ищу решение с
>применением третьей стороны т.к. хоть убей не понимаю как 2 клиента
>из-за НАТа могу содиниться напрямую.
Напрямую -- никак, на то NAT и нужен.>Установка какого либо софта у клиентов
>исключена.
Дошло. То есть нужен промежуточный сервер.
Так, есть сервер (proxy) к нему подключаются клиенты, сервер идентифицирует
соединения по номерам портов, и пишет-читает. Жаль только, что ему придётся
ждать пока оба партнёра подключатся.
Но такая схема не похожа на Радмин? Чтобы управлять клиентом, сервер должен
дождаться, когда тот захочет стать управляемым. Это приемлемо? - Место встречи двух клиентов, сидящих за НАТами., MaximKuznetsov, 18:55 , 11-Апр-05 (7)
>>Чем плохи уже готовые решения - desproxy, stunnel ?
>
>Ещё не знаю. Счас сижу читаю их описания, но что-то мне подсказывает
>что эти решения не для моего случая. Я ищу решение с
>применением третьей стороны т.к. хоть убей не понимаю как 2 клиента
>из-за НАТа могу содиниться напрямую. Установка какого либо софта у клиентов
>исключена.
да, остается только третья сторона ;-)
если есть возможность изменения кода клиентов, то в качестве третьей стороны можно поставить jaber (или irc или что-то подобное)..но придется переделывать протоколы обмена и авторизации..
Если же есть желание сделать собственный сервер под свои нужды,
(и не желательно трогать клиентов) то поискать в сети тексты на тему man-in-the-middle, с минимальными переделками (по поводу соединений) должно подойти.P.S. кстати стоило бы в теме добавить по каким протоколам идет обмен.
- Место встречи двух клиентов, сидящих за НАТами., Tim, 07:06 , 12-Апр-05 (8)
> да, остается только третья сторона ;-)
> если есть возможность изменения кода клиентов, то в качестве третьей
>стороны можно поставить jaber (или irc или что-то подобное)..но придется переделывать
>протоколы обмена и авторизации..
>P.S. кстати стоило бы в теме добавить по каким протоколам идет обмен.
>
Решил пойти по этому пути (после того как прочитал про Джаббер).
Т.е. пишу сервер передачи сообщений.
Ессно клиентские тулзы придется полностью переписывать... а что делать?
Вопрос - как хранить информацию на сервере? Информация это: координаты мышки, коды клавы, снимки экрана (т.е. может быть и объемной). Запихивать это в базу - долго... Держать в памяти?
- Место встречи двух клиентов, сидящих за НАТами., Moralez, 10:27 , 14-Апр-05 (9)
не проще на выделенном сервере поднять vpn и цепляться из-за НАТа и там уже имея серые IP-ы работать как угодно... тогда вообще не надо писать никакой софт... vpn-сервер использовать TCP-based, а не GRE/ESP/итп....
- Место встречи двух клиентов, сидящих за НАТами., Tim, 11:11 , 14-Апр-05 (10)
>не проще на выделенном сервере поднять vpn и цепляться из-за НАТа и
>там уже имея серые IP-ы работать как угодно... тогда вообще не
>надо писать никакой софт... vpn-сервер использовать TCP-based, а не GRE/ESP/итп.... Это опять же требует определенных действий со стороны пользователей. А они идиоты. Администратор иногда объясняет куда на сайте нужно ткнуть мышкой.... А вы VPN! Хотя решение интересное. Попробую из чисто спортивного интереса.
|
Версия для распечатки
Место встречи двух клиентов, сидящих за НАТами., 
