Приветствую, друзья.
Это мой второй пост, первый был закидан тапками) Надеюсь тут будет лучше.
Итак, наша команда работает над проектом, в основе которого лежит библиотека для удаленных соединений за NAT. И мы решили дать возможность программистам, девопсам и сисадминам бесплатно использовать эту библиотеку.
Библиотеку мы назвали Heredes (HEadless REmote DEsktop System). Это библиотека для управления рабочим столом удаленного ПК из приложений - вроде не дает никто такого? Нам не жалко, а вам, надеемся, пригодится. Аналогов отдельных для решения конкретной задачи как бы и нет. Есть как часть какого-то сервиса, что далеко не всегда приемлемо. И то для пользователей и сисадминов. Ну а для разработчиков - это всегда делать все с нуля самим.
Возможности библиотеки:
- Простое установление прямого соединения между двумя ПК за NAT (в разных подсетях)
- Двусторонний обмен любыми пользовательскими данными.
- Оптимизация для простоты реализации таких повседневных задач как:
- Прямая передача файлов за NAT. Размер файлов ограничен вместимостью ваших жестких дисков
- Покадровое реалтайм видео с рабочего стола одной машины на другую. Возможность отрисовки рабочего стола как на виртуальном DC так и на реальном
- Реалтайм аудио с микрофона одной машины на колонки второй (в формате PCM) с возможностью записи аудио в файл.
- Проброс клавиатуры и мыши между двумя ПК за NAT.
- Шифрование пересылаемых данных с помощью необычного закрытого ключа.
- Наше решение для разработчиков, то есть это библиотека которую можно использовать в Вашем проекте
- Мы пробиваем NAT. И клиент и сервер могут не иметь белых адресов
Минусы:
- Логин на пк/сервере. Мы не логинимся, т.о. вход на ваши сервер или ПК должен быть выполнен.
- Два ПК в одной локальной сети, видя друг друга напрямую, тем не менее не смогут при помощи этой библиотеки установить соединение.
Сферы возможного использования:
- Удаленный доступ за NAT к любому ПК .
- Автоматизация процессов ПК за NAT, в т.ч нескольких машин одновременно, работу которых нужно согласовать (синхронизировать).
- Несколько рабочих столов можно отображать в одном интерфейсе.
- P2P мессенджер (с голосовым, видео, текстовым обменом и реальной возможностью передавать любые другие данные/файлы на выбор разработчиков).
Детальнее с тех. документацией вы можете ознакомиться тут. Пока только Windows, но скоро будет Linux.
Что мы ждем от вас:
1. Конструктивную критику. Возможно, мы давно видим однобоко свой продукт.
2. Конкретные предложения. Где что-то добавить, а где убрать.
3. Направление развития. По вашим отзывам будем формировать планы на будущее. Пока думаем работать над р2р файлопередавалкой и менеджером удаленных соединений (он вообще нужен?).
В следующих статьях (или статье) распишем более детально работу с C, C #, C ++, Python, PHP и JS (для десктопных приложений), Delphi и на примерах (просьба написать какие из этих вопросов актуальны, а какие не нужны):
- простая звонилка за NAT;
- простой обмен текстовыми сообщениями за NAT;
- простая передача файлов за NAT;
- простой RDP за NAT;
- фоновое сохранение скрина удалённого ПК за NAT;
- удаленная командная строка CMD за NAT.
Ссылки: на проект, скачать архив, документация.
Комментарии (39)
remzalp
24.08.2021 07:11- Шифрование пересылаемых данных с помощью необычного закрытого ключа.
Вы настолько круты, что умеете в свою криптографию?Ожидал какое-то интересное ноу-хау, но всё как обычно оказалось обвязкой вокруг "STUN-сервера HeReDeS (от разработчиков не требуется наличие собственного stun-сервера..."
Brodilla Автор
24.08.2021 11:04А почему нет? Всегда можно модифицировать стандарт приведя его к виду нестандартного и уже в этом смысле более надежного, сохранив при этом основную идею шифрования - "быстро зашифровывать, долго расшифровывать". Более того - это не обязано быть основным и единственным шифрованием. Вы, как разработчик, в праве шифровать поверх нашего шифрования только вам известным способом или применяя стандартные библиотеки для этого. мы ориентировались на приемлемую сложность расшифровки при максимальной скорости работы библиотеки.
Без ноу-хау не обошлось, на самом деле. Во-первых, своего stun-сервера не требуется разработчику. Во-вторых, не требуется разбираться в протоколах работы со stun сервером ни нашим, ни каким другим, т.к все сведено к вызову функций, которые взяли на себя работу с протоколами сетевого взаимодействия. Обвязка вокруг известной ранее техники пробоя NAT - безусловно, это она и есть.
Есть ли аналоги библиотеки - сомнительно. Ближайшим аналогом является другая "обвязка вокруг той же техники" - webrtc, которая, по ряду причин, не устроила нас и, возможно, не устроит еще кого-то.
Kotofay
24.08.2021 12:02Используется ли вашей библиотекой TURN сервер если два клиента находятся за симметричным NAT-ом?
Brodilla Автор
24.08.2021 15:47Turn не используется. В этом случае возможно использовать свой turn если произошел отказ соединения. Возможно в будущем, мы предложим ПО для своего turn сервиса, но вопрос под вопросом и зависит от спроса.
suns
26.08.2021 19:12"более надежного" - это вообще спорное утверждение. Наверное еще один раунд действительно не ослабит шифр, однако изменения в s-box вполне могут походить на закладку
Brodilla Автор
28.08.2021 13:03Идеологически мы сохранили RSA-идею в упрощенном виде. И, на самом деле, при использовании "по умолчанию" в сравнении со стандартным RSA мы выигрываем лишь по скорости многократно, но не по сложности расшифровки.
Так что утверждение не спорное - если использовать библиотеку не слишком заморачиваясь и, оставляя все по умолчанию то шифрование поверх или до нас, не будет лишним.Тем не менее, это все верно для параметров функций "по умолчанию", а основная идея конкретно шифрования в том, чтобы не согласовывать ключи ни в открытом и ни в закрытом виде не передавать ни их ни производные "подсказки", как бы не сложен был подбор ключей исходя из тех подсказок, а разделить ключи на "базовый ключ" который индивидуален, постоянен и заранее известен для каждого направления (не меня как пользователя и не вас как второго пользователя, а уникальность базового ключа именно для соединения между нами), что принципиально уже не может уступать тому же RSA. И к этому в плюс еще вольно-согласованной части на усмотрение разработчика.
Тема обширная и, наверное, ей будет стоить посвятить отдельную статью.
expertykt
24.08.2021 07:24+1Для VBA: простой обмен текстовыми сообщениями за NAT;
Brodilla Автор
24.08.2021 11:09А почему нет? В VBA тоже есть возможность использования вызовов функций из других dll. Функционал вполне встраивается в макросы приложений MS Office через Public или Private Declare. С оговоркой - это на данный момент 32-битные версия dll, и версия пакета MS office должна быть той же битности иначе или не выйдет или придется использовать самописную "прокладку", например для взаимодействия через pipe или файлы - накладно в плане реализации, но тем не менее тоже возможно если очень надо связать напрямую две удаленных таблицы в Excel, к примеру.
Stecenko
24.08.2021 08:35+1Мы пробиваем NAT. И клиент и сервер могут не иметь белых адресов
Хочется, чтобы этот момент был освещен подробнее.
Обычно реализация таких вещей заключается в том, что на этапе установления соединения есть третья сторона — сервер-маршрутизатор, от которого, собственно, клиенты и получают адреса друг друга.
fougasse
24.08.2021 09:14STUN уже лет 15 как в ходу, да.
Ra-Jah
24.08.2021 09:33+1На вопрос вы не ответили. Как это поможет с двумя restricted NAT, не понятно и вообще ничего не понятно без описания конкретных технологических приемов работы этого волшебного клиента.
fougasse
24.08.2021 12:31Как STUN работает с restricted cone NAT - публичная информация, там нет никакого rocket-science.
Для symmetric NAT можно попробовать TURN.
qw1
24.08.2021 13:25Сейчас я не знаю ни одного современного девайса, ни одной современной ОСи (в случае програмного NAT), ни NAT от интернет-провайдеров, которые были бы подвержены Hole Punching. Всё осталось далеко в 2000-х. А вы знаете?
Brodilla Автор
24.08.2021 15:31Боюсь, я с ходу не могу назвать пару разных провайдеров, между клиентами которых нельзя установить прямое соединение. По опыту - это скорее теоретическая невозможность.
qw1
25.08.2021 00:43Вот прямо сейчас проверил.
Проводной провайдер даёт мне белый IP (а переключаться я не хочу), поэтому его NAT проверить не получилось. Но домашний роутер основан на linux, и не допускает hole punching, тестирующая утилита определяет «port-restricted nat».
На мобильном провайдере (Megafon) тестирующая утилита определяет Symmetric Cone. Да и с какой радости провайдерам оставлять Full cone NAT, если при этом появляется лимит в 64K соединений через один публичный адрес, а потом порты кончатся. Лучше иметь полную таблицу трансляций и почти неограниченное число соединений через 1 публичный IP. Full cone был временным явлением из-за дороговизны памяти роутеров, чтобы сэкономить 2-4 байта на каждом соединении, не запоминая внешний IP. Сейчас память сильно подешевела.
Так что в моём случае прямое соединение за NAT-ами невозможно.
Ваш опыт, скорее всего, относится к случаям, когда клиенты находят внешний сервер, через который идёт трафик.Brodilla Автор
25.08.2021 12:19В ближайшие дни выйдет статья с примерами реализации на С++, а так же ссылки на скомпилированные примеры. Лучшего способа проверки, чем проверка на практике - нет. Попробуйте библиотеку в действии: например, стационарный ПК за роутером, а ноут через мобильного провайдера... а утилиты отлично покажут откуда и куда приходит трафик. И оставьте отзыв о практическом опыте - это будет полезно.
qw1
25.08.2021 17:04Можно попробовать, но случится чудо, если оно у меня заработает.
Brodilla Автор
25.08.2021 21:55Опуская тех подробности о вашем домашнем роутере, можно утверждать об успешном пробивании NAT у мегафона/йоты с одного конца (тесты в регионе - Краснодар) и lifecell/киевстар с другой (регион - Одесса).
Таким образом, когда хоть одна из сторон подхватывает прямое соединение - второй ничего не остается. Имеет смысл попробовать - шансы сильно отличны от нулевых. Хотя утверждать можно конечно же только после живого теста в виду возможных погрешностей в работе утилит, к примеру - время покажет так ли непробиваем ваш случай.
Brodilla Автор
24.08.2021 11:20Да. Именно эту технику мы реализовали в библиотеке, но реализовали прозрачно в виде вызовов функций библиотеки с минимально возможным набором параметров. Так, например, получение адресов друг-друга происходит и в нашем случае посредством нашего сервера-маршрутизации (далее - stun сервера), но он уже есть и не требуется от вас, а протокол сетевого взаимодействия на всех этапах не требует его понимания. В своем приложении вы можете сосредоточиться на своей задаче, оставив банальную, но трудоемкую обертку организации прямого взаимодействия нашей библиотеке. Более того - мы постарались предусмотреть наиболее частые варианты потребностей и облегчить их реализацию. В ближайшие дни опубликуем статью с примерами реализации таких частых потребностей на С++.
Vinni37
24.08.2021 15:12+2Я правильно по нимаю, что в случие если ваш сервер помашет ручкой, все труды по внедрению окажутся прахом? Или ваш сервер-маршрутизации можно поднять у себя?
Brodilla Автор
24.08.2021 16:46Все немного иначе. Если по каким-то причинам мы решим, что нецелесообразно более предоставлять наш stun-сервис в общий доступ, мы спросим здесь же на хабре кто хочет-может предоставить ради саморекламы или из добрых побуждений впс в качестве stun-сервера и получить права на домен heredes.org в придачу на добровольной основе.
Есть внутренняя уверенность, что выложить 50$ в год ради саморекламы смогут многие. Таким образом бесплатный stun маловероятно, что умрет.
qw1
25.08.2021 00:52+1Если у вас дейcтвительно STUN по RFC 8489, а не какой-то свой велосипед, то логично иметь возможность в API библиотеки указать адрес STUN-сервера. Нагуглить пяток действующих STUN-серверов вообще не проблема. И домен не нужно будет никому передавать.
Brodilla Автор
25.08.2021 11:51Все в строгом соответствии со спецификацией RFC 8489, из которой следует возможная несовместимость на уровне протоколов различных STUN-серверов в связи с расширяемым форматом пакетов.
Daar
25.08.2021 15:00Спасибо за ваш труд! Вашу библиотеку полгода бы назад. Сейчас сделан свой велосипед на бесплатных VNC. Но если все будет красиво как написано у вас, то можно подумать и о миграции. Интересуют такие вопрос:
Можно задавать свои STUN-сервера или ваши жестко вшиты?
Это только под windows или будут другие платформы, то какие?
Как понял бесплатно пока на тесте, а можно узнать примерно какая будет потом монетизация? А то может и не стоит пробовать :)))
Реалтайм видео - как понимаю есть возможность захвата с камеры? Но при этом пугает "Мы скриним весь экран", какие-то кодеки используются?
Brodilla Автор
25.08.2021 19:52на данный момент только под windows и только 32 бита для большей совместимости. следующим шагом, после перехода от бетты к версии, будет линукс реализация, затем в планах интеграция клиентской части с браузерами через webassembly (сторона ожидающая соединения скорее всего останется чисто десктопной всегда, т.е решение врядли перейдет в форму браузер-браузер) и только после этого возможно и 64 битные.
STUN-сервер жестко вшит на данный момент. связано это с тем что формат пакетов расширен с целью объеденить протоколы межклиентского взаимодействия и протокола обмена с STUN сервером, что облегчает обработку пакетов и уменьшает этот участок кода более чем в 2 раза, но напрочь убивает надежду на совместимость. вариант распространения кода stun сервера для корпоративных решений пока не рассматривается
это рекламный продукт и он будет бесплатен всегда. из недостатков возможно покажется невозможность установки исходящего соединения в фоновом режиме (а окно ввода ID принимающей стороны содержит рекламеый блок 150х150) рекламирующий другие, в т.ч платные продукты. это и есть плата за использование - небольшой квадрат в момент установки соединения на стороне 'клиента'. серверная (ожидающая часть) фоновая
функция захвата изображения работает с указанным hDC. в ряде случаев WinAPI работы с камерой предполагает так же отрисовку на указанном DC, что делает принципиально возможным и захват изображения с камеры. на сколько производительным будет такой проброс - не тестировали и соответственно не оптимизировали, но принципиально это возможно.
кодек. это самый интересный вопрос. мы пошли по пути GOOGLE в том смысле, что решили внести что то новое. кодек проприетарный.
почему так - библиотека разрабатывается с оглядкой на свои нужды среди которых жесткий реалтайм и между плавностью и актуальностью состояния изображения выбор в пользу последнего.
классическое же видео содержит беспорно гениальные решение в виде векторов движения и другие оптимизирующие факторы, которые требуют обработки нескольких (чем больше тем лучше сжатие) кадров. Хуже того, эти решения существенно замедляют сжатие видеопотока, т.к поиск векторов движения врядли можно отнести к быстрой по времени задаче, что делает реалтайм с хорошо оптимизированным по трафику видео невозможным. таким образом наш кодек это скорее проброс покадровых изображений в модифицированном гибриде - что то между jpg-gif с оптимизированным решением заменяющим громоздкое класическое косинусное преобразование, хорошо оптимизированным упором на различие в соседних кадрах и некоторыми другими решениями позволяющими добиться возможного минимума трафика при относительно статичных изображениях и приемлимых требованиях к ширине канала при динамике. такой алгоритм позволяет избежать постоянной синхронизации видеопотока а приводит к тому что в случае нестабильности канала или низкой пропускной способности просто пропускаются кадры, но разрыв с реалтаймом не превышает 20-30мс плюс время на загрузку кадра и что важно - с течением времени разрыв во времени не суммируется
в бетте кодек это самое сырое место - отнеситесь с пониманием. с другой стороны эта 'сырость' очень наглядно задемонстрирует и принципы идеи, не особо сглаживая/скрывая межкадровые переходные состояния - в определенном смысле недоработки бетты визуализируют алгоритмы
Daar
26.08.2021 08:53возможно покажется невозможность установки исходящего соединения в фоновом режиме
А вот это как раз для нас и будет главной причиной отказа от вашего продукта... Грубо, у нас будет список компов и пользователь просто выбирает какой ему нужен и нажимает "Подключиться" и сразу открывается окно УД, без ввода адресов/паролей и т.д. Я думал у вас эту информацию (ид, пароли и т.д.) можно было передать при вызове функций из библиотеки. Или возможно?
А это баннер он посередине экрана будет или где? Ну и если это баннер то получается ему требуется доступ в интернет и он будет выкачивать новые баннеры?
У нас просто продукт для внутреннего использования, желательно без выхода в интернет, почему и спрашивал о своих STUN серверах.Brodilla Автор
26.08.2021 19:12К сожалению, без интернета работать не будет. Вообще, Heredes это побочный продукт при разработке нашего основного - собственно основной будет использовать этот же стун. И идея выложить его для всех возникла недавно. Именно поэтому это бесплатно и как есть.
MGSpace
26.08.2021 23:49внутри локальной сети по моему проще организовать прямую рересылку изображения или я ошибаюсь? вплоть до вообще через pipe вида \\192.168....\pipe\... что б с сокетами не играться
Я вижу фишку как раз в том что две стороны за NAT и при том за разными NAT. в конкретно вашем случае, оставляю за собой право ошибаться.
MGSpace
26.08.2021 19:12Интересно было бы попробовать. жду примеров т.к пока не совсем ясна последовательность взаимодействия
Brodilla Автор
30.08.2021 23:38https://habr.com/ru/post/575442/ вот примеры. надеюсь, что-то да пригодится.
sHaggY_caT
Напишу только за себя. У кого-то могут быть другие мнения. Надеюсь, Вы не против.
Простите, но не нужно такое. Когда в прошлом решала похожие задачи, использовала VNC и VPN.
Я бы купила в таких случаях opencode(можно посмотреть сорцы, можно прислать PR и добиться мерджа), но не opensource (ну опенсурс лучше было бы), который бы каким-то образом удобно интегрировался с он-прем инфраструктурой. OpenCode нужно и для сервера и для клиента. А троян внутри инфраструктуры а-ля тимвьювер не нужен.
При этом сама по себе библиотека(при выполнении описанных выше условий), конечно, лучше блек бокс блоба вроде тимвьювера - можно интегрировать в большее число сервисов. Но нужны эталонные реализации.
Хочется, чтобы эталонная реализация умела k8s на серверной стороне, и имела линукс-клиент (это обязательно).
Brodilla Автор
Здравствуйте. Большое спасибо за ваш комментарий - мы действительно опасались обвинений в трояне или митм, но все же решили выложить данный проект. Это бетта и продавать бетту было бы верхом наглости. Но эта бетта содержит ряд собственных решений, реализацию которых не хотелось бы открывать до момента доведения до ума. После чего - все возможно, в т.ч и продажа opencode, о которой пока что говорить просто рано (продукт пока явно не на уровне для продаж). В данный момент мы - ноунейм и, конечно, с вашей стороны не должно быть к нам доверия, но в будущем надеемся его заслужить.
pyur
бетта зан насын.