форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Место встречи двух клиентов, сидящих за НАТами."
Сообщение от Tim (??) on 11-Апр-05, 12:04  (MSK)
Написали софтинку для работы руководства с персоналом (ремот админ по сути). Но на практике оказалось что и руководство и персонал сидят за НАТом. Ни там, ни там преодолеть это условие нельзя (разные провайдеры, дебилы в службе поддержки). Поэтому требуется програмное решение. (Пробросить порт на НАТе не предлагать, это решение уже отмели). Кто-нить писал такое? Какие-нить идеи? p.s. пока что думаю написать некое подобие прокси (на яве, из удобства). будет принимать соединение с одного из концов, ставить его в стек, когда придет соединение с другой стороны начнет в цикле передавать траффик с одного соединения на другое и обратно.
	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Место встречи двух клиентов, сидящих за НАТами."
Сообщение от SergeiZz on 11-Апр-05, 13:36  (MSK)
>Кто-нить писал такое? Какие-нить идеи? Если на обоих шлюзах Web серверы; клиенты из-за NAT обращаются к виртуальному хосту по SSL; срабатывает сценарий на Perl, Ruby (PHP, eRuby), который устанавливает соединение в локальную сеть. По сравнению с прокси преимущества будут, если на Web сервер переносится часть функциональности, иначе разница не велика (механизм сессий, например, реализовывать самому не так уж и долго), да и обмен данными будет по HTTP. >p.s. пока что думаю написать некое подобие прокси (на яве, из удобства). >будет принимать соединение с одного из концов, ставить его в стек, >когда придет соединение с другой стороны начнет в цикле передавать траффик >с одного соединения на другое и обратно. Клиент соединяется с прокси; прокси клонирует себя для поддержки клиента; клон дозванивается в локальную сеть и читает-пишет туда-сюда (есть несколько стандартных схем для читать-писать). Если писать на Ruby, то на Gserver минут эдак за 15-20 можно набросать работоспособную версию (с пулом потоков, журналированием, et caetera). На Java, думаю тоже есть столь же крутая библиотека.
Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от Tim (??) on 11-Апр-05, 14:16  (MSK)
	>>p.s. пока что думаю написать некое подобие прокси (на яве, из удобства). >>будет принимать соединение с одного из концов, ставить его в стек, >>когда придет соединение с другой стороны начнет в цикле передавать траффик >>с одного соединения на другое и обратно. >Клиент соединяется с прокси; прокси клонирует себя для поддержки клиента; >клон дозванивается в локальную сеть и читает-пишет туда-сюда (есть >несколько стандартных схем для читать-писать). Клон не сможет получить доступ во внутреннюю сеть. Сеть за НАТом. Моя схема предполагает третью сторону: [Админ]---[НАТ1]-->[proxy]<--[НАТ2]---[Клиент]
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от SergeiZz on 11-Апр-05, 15:10  (MSK)
	>Моя схема предполагает третью сторону: > >[Админ]---[НАТ1]-->[proxy]<--[НАТ2]---[Клиент] Это не прокси тогда, а сервер. Админ тогда просто привилигерованным клиентом становится. Я думал, есть клиент и сервер, работающие в локальной сети, а нужно одного из них вытащить за NAT. А тут что за прокси такой?
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Место встречи двух клиентов, сидящих за НАТами."
Сообщение от StSphinx (??) on 11-Апр-05, 13:49  (MSK)
>Написали софтинку для работы руководства с персоналом (ремот админ по сути). Но >на практике оказалось что и руководство и персонал сидят за НАТом. >Ни там, ни там преодолеть это условие нельзя (разные провайдеры, дебилы >в службе поддержки). Поэтому требуется програмное решение. (Пробросить порт на НАТе >не предлагать, это решение уже отмели). > >Кто-нить писал такое? Какие-нить идеи? > >p.s. пока что думаю написать некое подобие прокси (на яве, из удобства). >будет принимать соединение с одного из концов, ставить его в стек, >когда придет соединение с другой стороны начнет в цикле передавать траффик >с одного соединения на другое и обратно. Чем плохи уже готовые решения - desproxy, stunnel ?
Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от Tim (??) on 11-Апр-05, 14:19  (MSK)
	>Чем плохи уже готовые решения - desproxy, stunnel ? Ещё не знаю. Счас сижу читаю их описания, но что-то мне подсказывает что эти решения не для моего случая. Я ищу решение с применением третьей стороны т.к. хоть убей не понимаю как 2 клиента из-за НАТа могу содиниться напрямую. Установка какого либо софта у клиентов исключена.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от SergeiZz on 11-Апр-05, 15:29  (MSK)
	>Я ищу решение с >применением третьей стороны т.к. хоть убей не понимаю как 2 клиента >из-за НАТа могу содиниться напрямую. Напрямую -- никак, на то NAT и нужен. >Установка какого либо софта у клиентов >исключена. Дошло. То есть нужен промежуточный сервер. Так, есть сервер (proxy) к нему подключаются клиенты, сервер идентифицирует соединения по номерам портов, и пишет-читает. Жаль только, что ему придётся ждать пока оба партнёра подключатся. Но такая схема не похожа на Радмин? Чтобы управлять клиентом, сервер должен дождаться, когда тот захочет стать управляемым. Это приемлемо?
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от MaximKuznetsov on 11-Апр-05, 18:55  (MSK)
	>>Чем плохи уже готовые решения - desproxy, stunnel ? > >Ещё не знаю. Счас сижу читаю их описания, но что-то мне подсказывает >что эти решения не для моего случая. Я ищу решение с >применением третьей стороны т.к. хоть убей не понимаю как 2 клиента >из-за НАТа могу содиниться напрямую. Установка какого либо софта у клиентов >исключена.   да, остается только третья сторона ;-)   если есть возможность изменения кода клиентов, то в качестве третьей стороны можно поставить jaber (или irc или что-то подобное)..но придется переделывать протоколы обмена и авторизации..   Если же есть желание сделать собственный сервер под свои нужды, (и не желательно трогать клиентов) то поискать в сети тексты на тему man-in-the-middle, с минимальными переделками (по поводу соединений) должно подойти. P.S. кстати стоило бы в теме добавить по каким протоколам идет обмен.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от Tim (??) on 12-Апр-05, 07:06  (MSK)
	>  да, остается только третья сторона ;-) >  если есть возможность изменения кода клиентов, то в качестве третьей >стороны можно поставить jaber (или irc или что-то подобное)..но придется переделывать >протоколы обмена и авторизации.. >P.S. кстати стоило бы в теме добавить по каким протоколам идет обмен. > Решил пойти по этому пути (после того как прочитал про Джаббер). Т.е. пишу сервер передачи сообщений. Ессно клиентские тулзы придется полностью переписывать... а что делать? Вопрос - как хранить информацию на сервере? Информация это: координаты мышки, коды клавы, снимки экрана (т.е. может быть и объемной). Запихивать это в базу - долго... Держать в памяти?
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от Moralez (ok) on 14-Апр-05, 10:27  (MSK)
	не проще на выделенном сервере поднять vpn и цепляться из-за НАТа и там уже имея серые IP-ы работать как угодно... тогда вообще не надо писать никакой софт... vpn-сервер использовать TCP-based, а не GRE/ESP/итп....
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Место встречи двух клиентов, сидящих за НАТами."
	Сообщение от Tim (??) on 14-Апр-05, 11:11  (MSK)
	>не проще на выделенном сервере поднять vpn и цепляться из-за НАТа и >там уже имея серые IP-ы работать как угодно... тогда вообще не >надо писать никакой софт... vpn-сервер использовать TCP-based, а не GRE/ESP/итп.... Это опять же требует определенных действий со стороны пользователей. А они идиоты. Администратор иногда объясняет куда на сайте нужно ткнуть мышкой.... А вы VPN! Хотя решение интересное. Попробую из чисто спортивного интереса.
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ]

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.