Подключение к устройству с неизвестным/локальным адресом

[alexf]

И так имеем некое очень не тривиальное устройство с ethernet'ом, живущее под управлением Linux. На этом устройстве на определённом порту висит демон. Соответственно для него существует клиентское приложение, написанное уже под Windows.

Устройство условно говоря не настраиваемое на стадии эксплуатации - доступ к нему только через клиентскую прогу.

Соответственно существует несколько вариантов подключения:

1. Клиентский компьютер подключается напрямую к устройству.

Соответственно это компьютер под управлением Windows. Соединяем напрямую (даже не кроссовером, т.к. карты современные). Винда врубает autonet и сама выбирает себе адрес в диапазоне 169.254.x.y. Можно и в ручную поставить, но так удобнее для динамических подключений (в том смысле что потом этот комп для другого использовать). На устройстве зашит некий IP из того же диапазона. И он же зашит в клиентское приложение. В общем всё работает само, без малейших напрягов и настроек клиентом.

Это уже реализовано и работает.

2. Клиентский компьютер находится или в локальной сети или где-то в глубинах интернета. Устройство подключается в некую локальную сеть.

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

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

3. Клиентский компьютер находится или в локальной сети или где-то в глубинах инета. Устройство подключено напрямую к некому произвольному компьютеру. Этот компьютер имеет ещё один сетевой интерфейс, через который подключен к интернету. Причём возможно как часть локалки.

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

Какие есть оптимальные варианты для создания 3-го варианта эксплуатации? Как я понимаю, это должен быть некий софт (хорошо бы существующий на нескольких платформах, хотя не обязательно) установленный на тот компьютер, плюс небольшие изменения в клиентском приложение.

Кто может подсказать варианты?

[Ленивая Бестолочь]

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

[Voral]

Какие есть оптимальные варианты для создания 3-го варианта эксплуатации? Как я понимаю, это должен быть некий софт (хорошо бы существующий на нескольких платформах, хотя не обязательно) установленный на тот компьютер, плюс небольшие изменения в клиентском приложение.
кто может подсказать варианты?

Мутновато как то.
Т.е. окончательная задача передать пакеты от клиента на железяку, ну и обратно....
Т.е. на комп к которому подключена железяка и который имеет выход интернет. должен знать айпи железяки.

На клиенте настраиваем на адрес второго компа и на какой либо порт. Там прокси сервер (?) по заданному правилу, при получении пактов на определенный порт (и, возможно, с определенного адреса). Передает их на железяку......

[Red Gremlin]

Там прокси сервер (?)

я бы сказал, иптаблеса, примерно такая:

iptables -t nat -A PREROUTING -p tcp -s $FROMIP --dport $DEVPORT -j DNAT --to-destination $DEVIP

[danger08]

Я бы использовал сторонний vpn-сервер (железки регистрируются на нем), через него подключаться к железке.
Или службу, аналогичную DynDNS.

[alexf]

Так, я много всего посмотрел, обдумал варианты и кажется пришёл к решению. Сейчас опишу свой вариант и при этом выделю жирным те места, где не помешала бы подсказка. Ну и если будут какие-то идеи получше, то тоже буду рад. )

Предположительный вариант:

- Пишем и кидаем в автозагрузкиу устройства микропрограммку. Она должна сидеть на определённом порту и ждать сообщений. Если сообщение приходит и в нём находится MAC адрес устройства, то программка отсылает в ответ свой IP.
- При загрузке устройство должно в начале пытаться подключиться к DHCP серверу, а если его не видно, то должно включиться APIPA. Кто-нибудь может подсказать как настроить такое поведение (на устройстве Slackware)?
- Клиентское приложение про работе в одной физической сети не запрашивает IP устройства, а находит его само через широковещаетельное сообщение на нужный порт.

Из этого получаются следующие схемы:
1. Режим работы на прямую. Типа втыкаем провод от устройства в ноут и больше никаких сетей у нас вообще нет.
Работает всё автоматом, без каких либо настроек. Адрес устройства назначается через APIPA и узнаётся клиентом через нашу схему (широковещательный запрос).

2. Включение устройства в некую локальную сеть.

2.а. Работа с устройством с какого-то комп из этой же физической сети.
Работает всё автоматом, без каких либо настроек. Адрес устройства назначается через DHCP и узнаётся через нашу схему.

2.б. Работа с устройством из глубин интернета.
Адрес устройства назначается через DHCP. На каком-то из компьютеров локальной сети запускаем клиентскую программу, видим IP адрес в ней, выключаем программу, сообщаем IP человеку в глубинах инета и тот подключается обычным способом из клиентского приложения, просто указав нужный IP в его настройках.

3. Работа с устройством подключённым к некоторому компьютеру, который находится в нужной сети. Полезно например в случае подключение устройства к ноуту по ethernet, а ноут в нужной сети по wimax и т.п.

Адрес устройства назначается через APIPA. Запускаем на промежуточном компе входящее VPN (реализация этого есть даже в WinXP, делается в 5 кликов), сообщаем далёкому человеку свой IP. Тот настраивает VPN соединение с этим компом и подключается как будто бы находится на нём. Вот только вопрос, пройдёт ли широковещательный запрос через VPN или нет? Если нет, то надо будет ещё сообщить удалённому человеку IP устройства, что чуть-чуть менее удобно, поскольку требуется наличия клиентского приложения на том промежуточном компе.
-----------------------------------
Вот такая схемка - кажется весьма удобно для пользователей. )

Да, и ещё... Как я понимаю, если описываема локальная сеть находится за NAT'ом по обычной схеме и у нас нет возможности поправить его настройки, то доступ из интернета работать не будет. Или всё же есть какие-то идеи для обхода?