Возникла необходимость управлять несколькими устройствами от одного компьютера через интернет,
как по GPRS так и просто по интернет.

Подобные темы обсуждались на этом форуме, например http://electronix.ru/forum/index.php?showt...&st=75&

Но так и не увидел конечного решения для протокола PPP.

Для компьютерных игр через интернет часто используют программу Хамачи:
http://www.google.com/search?client=opera&...-8&oe=utf-8

Она создает некую вертуальную сеть. Зная имя сети и пароль можно зайти в нее. При этом устанавливается соединение точка-точка и ПК начинают видеть друг друга.

Вопросы:
1. Не понятен алгоритм работы проги, может кто-нибудь осветить это?
2. Возможно ли сделать аналог этой проги в железе и связать устройства через сеть, которую создает хамачи?

вы всё-таки попробуйте сформулировать более конкретно - что у вас есть и чего вы хотите добиться.

непонятно, насколько "разумные" железки, как подключены и т.д.

ps: подозреваю, что вам будет достаточно заказать у оператора постоянный белый ip.

Если не ошибаюсь, то эта прога создает VPN опредленно настроенный.
PPP тут абсолютно не причем. Протокол PPP используется только для связи между своим компом и компом провайдера поверх телефонного соединения. Протокол используется ОС, а для программ он абсолютно прозрачен, так как они общаются на протоколах более высокого уровня...

Не только поверх телефонного соединения и не только для связи между своим компом и компом провайдера. AFAIK VPN-соединения бывают трех типов: PPTP, L2TP и IP-over-IP. Первый есть вариация PPP, равно как и PPPoE.

Формулирую точнее:

Есть Пк, подключенный к интернету через прокси сервер (не столь важно). Есть три железки, в состав которых входит GSM модем и микроконтроллер. Задача, сделать связь между компьютером и этими тремя устройсвами. Существует три способа.
1. Сидеть с компа через телефон, у которого статический IP, но за это надо платить абонплату
2. Сидеть с телефона с динамическим IP. В этом случае надо использовать DDNS сервер типа dyndns.com, для того, чтобы устройсва узнавали IP адрес сервера.
3. Использовать туннелирование (PPP).

Интересует версия 3.

Немного начитался про хамачи. Вроде как он при старте заходит на свой сервер, регистрируется и получает некий IP адрес, при этом на сервере остается путь к этому компьютеру. Допустим на другом компьютере происходит тоже самое. После этого одному из пользователей нужно создать виртуальную сеть. Тогда второй может в нее зайти и между компьютерами устанавливается точка-точка.
Что в действительности происходит не понятно. Посмотрел сниффером Ethernet пакеты. От моей машины идут пакеты протокола PPP, а ко мне два типа пакетов PPP и GTM. Пока разбираюсь что к чему.

Может кто ссылку подкинет по теме

то есть инициируют соединение железки, а проблема в том, что у компьютера нет постоянного ip?

Да

Вернее у него вообще нет IP для доступа к нему из вне. Доступ через прокси.

самый простой и правильный вариант - найти сервер с постоянным адресом и передавать данные на него. а к нему уже цепляться со своего ПК.
сейчас глянул для интереса - сходу нашёл VDS с freebsd за 6 баксов в месяц.

так может быть просто попросить админа, чтобы пробросил порт снаружи


или у сети тоже нет реального внешнего адреса?

резюмируя: информации недостаточно. да и вопрос не для этого форума скорее. может в аську переместимся?

Тема на границе между этой и сетями. Так как решаю задачу для GSM устройств, решил остаться здесь.
Задача такая. Возможно устройство пойдет в серию. У клиентов может быть разный уровень доступа в интернет. Программе Хамачи все равно, каким способом пользователь получает доступ в интернет. Всегда можно соединить два компа. Собственно и хочу узнать, как это можно сделать из любой сети с любым уровнем иерархии.

--------------------------------------------------------------------------
Про аську, если интересно, стучитесь

передавать данные на клиентский компьютер, непонятно как подключенный к сети - зачем? устройства собрались передавать - а компьютер выключен. или недоступен.

проще поднять свой сервер, собирать данные на нём, а клиентам предлагать доступ к нему за символическую плату.

Не проще. Зачем создавать клиентам проблемы. Протокол: запрос - ответ. Устройства будут в некотором интервале времени отсылать маленький пакетик серверу. Если ответа нет, значит сервер не доступен. Если доступен, начнется обмен.

Для такого можно использовать практически любой хостинг, т.е. отсылать на него пакеты через HTTP или FTP. А с компа это потом забирать регулярно.

В любом случае нужен сервер с внешним адресом. В случае с хамачи, если не удается установить прямой контакт(оба компа за NAT или Proxy), он использует свои сервера. Поскольку это бесплатно - качество и стабильность соответствующее.
А реализовывать в желязках ради такого ВПН - смысла не вижу.

Не знаю, как насчет хамачи, но есть китайский аналог Emule - Vagaа. Так вот он вроде как может устанавливать точка-точка, если оба клиента сидят за NAT.
В реальности не видно, откуда он что качает, но иногда работает лучше Емуля. Сам я, ессно, за NAT.

Может, используется UPNP на одном из NAT'oв ?
Все от настроек зависит.
Но в большиестве случаев если клиент сидит за НАТом, и уж тем более, за прокси - то достучаться к нему нет возмржности.
В таких ситуациях всегда нуже промежуточный внешний сервер. А будет то хамачи, ваш собственный, или как делает Skype - использует компы дугих пользователей с внешним адресом и широким каналом - это уже только вопрос реализации.

Наверное буду пробовать этот вариант. С хамачи не все так просто, для доступа на сервер используется RSA шифрование, дабы это сервер не использовали кто попало.

Похоже проблема в том что вы путаете между собой proxi , NAT и Firewall.
Это все разные вещи.

В случае когда оба конца за NAT-ом даю идею:

Исходные данные:
Оба дивайса имеют в памяти по два публичных адреса. Один считают своим, другой считают присвоенным удаленному дивайсу. Адреса эти им никто может официально не выдавать, они их используют как бы нелегально, но они должны быть публичными.
Также дивайсам известно с каких портов они будут выходить на связь.

Начало обмена:
Каждый из дивайсов с известного порта посылает UDP по фиктивному адресу своего удаленного партнера.
Эти UDP не доходят понятно до адресата, но дело сделано, с тем адресатом пробит UDP канал в NAT-е
После того как каналы пробиты на обих NAT-ах c двух концов дивайсы начинают в свои пакеты в поле адреса отправителя ставить свои фиктивные публичные адреса.
И эти пакеты уже дойдут к каждому
Есть NAT-ы где канал пробивается еще легче, просто можно послать пакет по любому адресу.
Тогда и TCP можно использовать.

Интересная идея, только вот если не ошибаюсь NAT на публичном интерфейсе совершенно не обязательно будет передавать от такого же порта, какой с которого получил от компа с внутреннего интерфейса.

В любом случае для данной задачи, а я так понял, необходимо ее решить в общем смысле - такой вариант не пройдет. Да и швыряться UDP трафом налево и направо через GPRS - тоже не очень хорошая мысль.

Оказывается возможно реализовать соединение между двумя компами.

Делается сервер в интернете. На который заходят участники сети. Получают пути друг для друга. Потом уже связываются между собой, используя эти пути. Т.е. происходить соединение между ПК и сервером. Далее, скажем, другой инициатор сети, зная путь, прикидывается сервером и работает.

вами, судя по всему, описана схема поиска друг друга хостами с динамическим ip.
если оба участника находятся за nat (как обычно это происходит в случае gprs), то такая схема работать не будет.

Да вот говорят за MTC-овским NAT-ом это работает.
Так у них и SIM карты до сих пор клонируют.
Видать левая контора с устаревшим оборудованием.

За нормальным NAT-ом конечно работать не будет.
Но вот схема с подстановкой публичного IP работать должна за любым NAT-ом
http://electronix.ru/forum/index.php?showt...mp;#entry411267

Как будет время, я конечно же проверю ваш вариант - но очень сильно сомневаюсь, что будет работать, а уж в нестабильности точно уверен.

лень расписывать подробно, вкратце.
предоположим вы "пробили" nat.
вы написали, с какого адреса и порта вы будете слать пакеты. а на какой адрес?
с портами вам уже указали - при прохождении nat порты обычно не сохраняются.
и напоследок: вы посылаете пакет с "левым" src ip. скорее всего он будет отброшен, но даже если и нет - nat подменяет src ip.

Нас это не остановит, ;-)
Хотя в каком-то моменте, стормозил вроде.

Тогда технология несколько меняется

Идея такая:
Усложним задачу предположив, что дивайсы не знают какой внешний IP или из какого пула внешних IP им присваивает оператор.
Тогда каждый дивайс узнает свой внешний IP адрес через какой-нибудь публичный STUN сервер.
Потом оставляет запись о себе где нить на публичном POP3 сервере или на HTTP майл сервере.

Найдя в общем каталоге через отдельный TCP коннект адрес своего партнера дивайс уже шлет ему пакеты. Но на какой порт? После сессии со STUN порт уже мог поменяться.
Тогда делаем ход конем.
NAT-ы не должны следить за сессиями они работают на уровне IP поэтому тупо шлем FTP команду PORT с запросом на активное FTP DATA соединение своему партнеру например на 21-й порт.
Команда не дойдет ясно, но как замечено NAT-ы не мапируют порт передаваеммый в этой команде.
Договорившись заранее о номере этого порта партнеры после обнаружения IP друг друга просто начинают что-то слать друг другу используя этот номер порта.

ключевое слово - пул

ничего не понял