Хочу поделиться с широкой общественностью одним нашим внутренним инструментом, совсем недавно выложенным в публичный доступ. Читатели заставшие ФИДО думаю обнаружат знакомые очертания ;)

Задача

Телепорта решает две простые, скучные и очень приземленные задачи:

• передача файлов между компьютерами

• передача буфера обмена

Разумеется на свете уже существует 1000 и одно готовое решение для этого, поэтому ниже опишу зачем нужно еще одно, которое вы тоже возможно начнете использовать после прочтения этой статьи.

А пока посмотрим как это выглядит в работе:

Для большего фана и в качестве демонстрации переносимости использовалась работающая Windows 98 в виртуальной машине с сетью.

Почему и зачем

На дворе 2024й год, по улицам вовсю катаются роботы-курьеры, по дорогам — электромобили с платными обновлениями а ваш смартфон давно стал считать себя умнее вас и вообще в шаге от осознания себя как личности.

Кругом искусственный интеллект, биткойны и боевые роботы,

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

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

Для большей конкретики стоит рассказать о типовых сценариях применения Телепорты в нашей компании:

• Безопасное перекидывание файлов между машинами разработчиков в команде, в том числе удаленных, работающих из самых невероятных и богом забытых мест;

• Выкладывание обновлений на тестовые сервера, в том числе чужие, защищенные и закрытые;

• Проброс файлов и буфера обмена в виртуальные машины.

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

Так что платежные поручения, счета фактуры и договора все также пересылаются обычной почтой.

Специфика

Поскольку занимаемся разработкой ПО, наши внутренние процессы сильно связаны именно с этим делом. Но с точки зрения применимости все тоже самое будет актуально и например для дизайн‑студии, типографии, бухгалтерии — в любом месте где есть «наколенный» документооборот, основанный на файлах и еще не доросший до масштабов применения ERP.

1. Файловый обмен между разработчиками

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

2. Выкладка обновлений

Выкладывание обновлений на сервер требует определенной автоматики, где сама передача файлов — лишь часть процесса. Поэтому решение должно быть управляемым снаружи — через внешние скрипты. Еще важно чтобы решение не требовало открытия отдельных входящих портов для своей работы, поскольку это рано или поздно приведет к попытке взлома или вывода из строя (DDoS).

3. Проброс файлов в виртуальные машины

Несмотря на то, что большинство решений по виртуализации вроде VMWare или VirtualBox уже содержат функционал для обмена файлами и буфером обмена — работает он далеко не всегда и регулярно ломается:

«kernel panic» в VMWare при копировании файлов через «Shared Folders» — в порядке вещей, к сожалению.

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

Все описанное выше (и немного больше) как раз и обеспечивает наша Телепорта.

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

FTP, SFTP и TFTP

Работающий по UDP и невероятно древний протокол передачи файлов TFTP — в 21м веке фактически мертв.

Нет, конечно если вы — сисадмин из ада и Unix-гуру в одном лице, то даже кирпич будет на ping отвечать.

Но в случае обычного пользователя и обычного или тем более корпоративного ноутбука с Windows/Linux и прочими MacOS начнется бодание с системными настройками, правами доступа, файрволлом, сетевым IDS, антивирусами и прочим — все эти замечательные штуки вам будут всеми способами намекать:

не надо так делать

И в какой‑то мере будут правы, поскольку TFTP для современного мира это одна сплошная дыра — в нем вообще отсутствует какая‑либо безопасность.

Чуть лучше обстоят дела у FTP, где хотя-бы есть авторизация и SFTP где есть шифрование и можно настроить работу с ключами.

Проблема в том что все это — серверное ПО, которое необходимо отдельно поднимать и настраивать на сервере, но не на каждой отдельной пользовательской машине.

Вот что вам надо знать для подключения и проведения копирования:

• IP-адрес или доменное машины

• порт (опционально)

• логин и пароль для входа

• приватный ключ (для SFTP)

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

Для полноты картины стоит добавить, что нынешний локомотив веба — Google Chrome не так давно удалил поддержку протокола FTP из браузера. С учетом масштаба и важности данного проекта — сие действие это такой неслабый намек на будущее данного протокола.

RSYNC и SCP

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

Проблемы все те же:

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

Давайте вместе посчитаем что надо знать, для того чтобы скопировать один файл:

• имя пользователя (логин)

• полный путь на сервере, каталог должен быть доступен на запись

• пароль к учетной записи или к файлу с ключом (или и то и другое - в зависимости от настройки)

• полный путь до локального файла

Всю эту техническую (для обывателя) ересь вам придется вводить каждый раз заново в консоли, для каждого отдельного файла и сервера.

SMB, NFS и общие папки

Уже теплее и корпоративнее:

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

Как только начинается «удаленка‑макбук‑аэропорт‑кафе‑далекая Мьянма» — все подобные технологии накрываются медным тазом.

И на то есть причины, примерно такие же как при попытке прокатиться на творении Лоренцо Феррари по родной деревне. Еще есть нюансы с портами (коих в случае NFS много), с блокировками файлов и настройкой доступа для каждого пользователя отдельно.

Файлообменники

Все эти Megaupload, Pastebin, Fileshare и так далее — тысячи их, используются в том числе сотрудниками компаний просто потому что «так проще», с чего являются постоянной головной болью для служб безопасности.

Риски? Вы о чем? Вы просто берете и дарите ваши данные непонятно кому и делать он может с ними все что угодно — от тренировки нейросетей до прямой продажи в даркнете.

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

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

Мессенджеры

Берется файл и отправляется самому себе в мессенджере, затем на другом компьютере (где установлен этот же мессенджер) файл скачивается:

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

Именно так и происходят утечки — из-за сиюминутного удобства.

Еще есть популярные варианты передачи файлов ююками в виде аттачей к электронному письму и классические «архив с паролем» — самое оно для секретного договора.

Все, считаю что я достаточно вас напугал и теперь можно рассказать о нашем проекте, который замечательно решает столь простую с виду, но столь сложную на практике проблему:

перекинуть файлики с одного компа на другой по сети

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

Схема работы

Замечу, что мы пришли к текущей схеме работы далеко не сразу и долго экспериментировали с разными технологиями и решениями:

TUN/STUN, вебсокеты, чистые UDP и TCP, броадкасты и торренты — все это было опробовано на практике и забраковано по тем или иным причинам.

Вот так выглядит итоговая схема работы, которую мы выбрали:

Суть ее в том что используется посредник — «релей» между клиентскими машинами — «порталами».

В начале файлы отправляются на этот самый релей, с указанием адресата — какому порталу файл предназначен. Затем эти файлы забираются второй стороной, которая периодически опрашивает релей банальным поллингом на тему «что нового».

Если «новое» действительно есть — клиентская сторона скачивает предназначенный ей файл с Релея и кладет в специальный каталог «входящие».

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

К сожалению времена прямого обмена данными между компьютерами даже в одноранговой сети прошли и на сегодняшний день существует по факту всего один легитимный (с точки зрения разнообразных средств защиты) вариант передачи данных:

Протокол HTTP/HTTPS с инициализацией соединения со стороны клиента

Когда браузер открывает страницу социальной сети или поисковика — это выглядит легитимно.

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

Чтобы не иметь этих проблем с оборзевшей автоматикой, Телепорта использует обычный HTTP, который ничем не отличается от работы браузера, спокойно проходит через любые прокси, не тревожит IDS и не требует открытия отдельных портов.

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

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

А все клиенты (порталы) это ни что иное как обычный HTTP‑клиент, примерно как ваш браузер, только сильно попроще.

Да, забыл сразу добавить один важный момент:

клиент (портал) не видит файлы ни на сервере (Релее) ни на другом клиенте

Иван Иванович может перекинуть файлы Станиславу Петровичу, но увидеть что еще есть в папке Станислава Петровича у него не получится. Никогда и никак.

Это важный момент и концептуальное отличие от сетевых файловых систем, общих папок и подобного.

Передаваемые данные разумеется шифруются, детально весь процесс описан ниже — в отдельном разделе.

Реакция на сбои

Использование HTTP, поллинга и релея для пересылки позволило достичь практически полной неубиваемости всей схемы работы:

пока работает клиентская часть (портал), она будет постоянно запрашивать сервер (релей), вне зависимости от изменений в сети.

Если релей недоступен — при его повторном появлении в сети все порталы автоматически повторно зарегистрируются.

Если портал был долгое время недоступен — он автоматически пропадет из списка доступных для отправки, все остальные порталы получат извещение и каталог отправки для этого портала будет удален.

При последующем появлении в сети, даже при большом периоде неактивности — произойдет автоматическая перерегистрация на Релее.

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

Если релей приватный — нужно дополнительноуказать файл с ключом (см.ниже)

После подключения порталы становятся постоянными и пока работает приложение Телепорты — можно закидывать файлы в каталог с исходящими и они будут отправляться автоматически.

Технологии

Теперь немного про используемые технологии и причинах их выбора.

Проект реализован на чистой Java, без каких‑либо внешних зависимостей и библиотек. И это одна из трех имплементаций данной идеи, которая оказалась самой живучей, пройдя три переписывания с нуля.

Две другие — на Golang и C++ не прошли проверку временем, несмотря на все возлагаемые надежды. У Golang нашлись серьезные проблемы с работой даже в немного устаревшем окружении, например в Windows XP или Linux 10-летней давности:

не существует никакого официального способа сборки и запуска проекта на Golang в устаревшем окружении

Нет ни кросс-компиляции ни проверки работоспособности — ничего, а для того чтобы собрать Golang даже в Windows 7 нужно... последовательно собирать все его версии начиная с последней поддерживаемой в Windows 7, вручную патчить и использовать предыдущую для сборки новой.

В общем пока у вас «гошечка» крутится на вашем родном, поддерживаемом и регулярно обновляемом сервере — проблем нет, как только начинается пользовательская среда — приходят крупные проблемы.

В случае с C++ все немного интересней.

Разумеется у C++ нет и быть не может никаких проблем с портируемостью, зато есть проблема летящих вперед как паровоз стандартов языка:

C++ 11, C++ 17 и C++ 20 — фактически три разных языка, с разным уровнем поддержки в разных ОС и окружениях.

В результате при практическом использовании народ ваяет вот такие костыли:

An implementation of C++17 std::filesystem for C++11 /C++14/C++17/C++20 on Windows, macOS, Linux and FreeBSD.

Потому что в старых ОС разумеется нет новых версий компилятора с поддержкой новых стандартов. С учетом специфики проекта, обеспечить переносимость можно только пересборкой, что потребовало бы поддержки множества подобных «костыльных» решений.

Поскольку Телепорта это прежде всего утилита, которая должна выполнять свою задачу минимальными усилиями — решили что версия на C++ будет отнимать слишком много сил и времени. Поэтому была выбрана Java.

Мы целенаправленно использовали самую старую версию Java из поддерживаемых — 1.8, чтобы обеспечить максимальную кроссплатформенность, думаю ролик выше с работой на Windows 98 яркое подтверждение правильности выбора ;)

На данный момент одна и та же версия спокойно работает в следующих окружениях:

Windows 7, Windows 8, Windows 10, Windows 11, CentOS, RHEL, Ubuntu, Arch, FreeBSD, NetBSD, OpenBSD, Nexenta и Oracle Solaris.

Как это работает

Телепорта представляет собой запускаемое консольное приложение (~200Кб), работающее «из коробки» на всех указанных выше ОС — используется технология комбинирования стартового скрипта и приложения в одном файле, описанная в одной из предыдущих статей.

И клиентская часть, которую мы называем «портал» и серверная — «релей» являются двумя режимами работы одного и того же приложения, поэтому как релей так и портал запускаются из любого места при необходимости.

В том числе на одной и той же машине.

При указании параметра «-relay» приложение запустится в режиме Релея — будет принимать и отдавать передаваемые файлы:

Технически это обычный HTTP-сервер на базе встроенного в любой JDK com.sun.net.httpserver, использование которого мы уже освещали в одной из предыдущих статей.

Обратите внимание на длинный URL, отображаемый Релеем при запуске:

http://majestic12:8989/2d52fb71ef728d8813a001a6592c8248801d844ce2c0d0a6976f10b73d3bdb463ea4cd09c1ad9a25d5b83a543238

Этот адрес является ключом для подключения к релею, из которого берется «seed» — часть ссылки, используемая для вычисления адресов конечных API, которые меняются при каждом запуске Релея.

Если только не был задан фиксированный seed специальным параметром (см. ниже).

Сей функционал необходим в 21м веке для того чтобы отгонять настырных роботов, протыкивающих ссылки на сервере различными методами — от простого перебора до сложных масок в поисках уязвимостей.

Для запуска портала (клиентской части) необходимо указать в качестве аргумента тот самый адрес, полученный от Релея:

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

Вот так это выглядит:

Как видите получается очень простое развертывание для конечных пользователей, которое тем не менее можно отключить специальным параметром (см. ниже)

Передача файлов

Теперь расскажу про саму передачу файлов, как это выглядит с точки зрения конечного пользователя.

Тут мы также достаточно долго экспериментировали а итоговый вариант был вдохновлен Dropbox.

При запуске в режиме клиента, Телепорта создает каталоги с названиями, совпадающими с названиями других порталов, зарегистрированных на текущем релее и затем мониторит эти каталоги на изменения.

Название портала является уникальным и берется по-умолчанию из hostname машины на которой запущен портал, но может быть переопределено специальным параметром (см. ниже)

Таким простым образом убирается вся сложность определения имени клиентской системы, соответствием имени и IP-адреса, использованием юникода и пробелов — все это становится неактуальным

Как только пользователь копирует или перемещает файл в каталог, на котором включен мониторинг Телепорты — начинается процесс «телепортации» файла, а точкой назначения выбирается тот портал, чье название совпадает с именем каталога.

Поскольку типичный сценарий работы с Телепортой это копирование файла в исходящий каталог — сразу после отправки на сервер файл удаляется.

Вот так это выглядит в действии:

Самым большим переданным файлом через Телепорту на сегодняшний день является режиссерская версия «Властелина Колец» в Blue-Ray качестве, размером в 75Гб.

Передача каталогов

Помимо файлов встала острая необходимость перекидывать еще и целые каталоги — та самая задача, на которой так сильно проседает Dropbox, поскольку делает рекурсивную синхронизацию каждого вложенного каталога и каждого файла.

Мы пошли другим путем:

Телепорта упаковывает весь каталог вместе с файлами в один архив и передает его одним куском.

На другой стороне происходит получение этого архива и автоматическая распаковка. Как-то так это выглядит в действии:

Каких-то лимитов на размер и вложенность замечено не было, поскольку мы постоянно работаем с проектами на Java — уровень вложенности может доходить до сотни каталогов.

И все совершенно это спокойно перебрасывается через Телепорту.

В качестве своеобразного теста производительности, мы делали например переброску исходников Intellij Idea Community Edition, это примерно 2.5 Гб файлов в сложной структуре каталогов — все успешно отработало.

Передача буфера обмена

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

На одной машине нажимается Ctrl-C и на всех остальных в буфере обмена появляются вставленные данные.

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

Вот так это выглядит:

По-умолчанию работа с буфером обмена отключена, для включения необходимо использовать параметр:

-Dclipboard=true

при запуске Телепорты, причем как на клиентской стороне (портале) так и на серверной (релее). Для Релея это необходимо, чтобы не передавать дальше обновления буфера обмена — если у кого‑то из порталов данная опция была включена.

Криптография

Для публичной версии Телепорты мы специально ослабили используемые алгоритмы, чтобы не превращать проект в инструмент для даркнета — реализовали самую простую криптографическую схему, работающую на банальных протоколах RSA и AES, доступных по-умолчанию в любом JDK/JRE и не требующих установки внешних криптопровайдеров.

2048-битный ключ RSA и 128-битный AES с одной стороны вполне достаточны для противодействия современным «кульхацкерам» и автоматическим сканерам, а с другой — легко вскрываемы любой спецслужбой, как приличной так и не очень.

Теперь перейдем к описанию того как все это работает.

И релей (сервер) и каждый портал (клиент) при запуске генерируют свою пару ключей: публичный и приватный. Ключи никогда не сохраняются на диск и живут только в памяти, что сильно сокращает риск утечек.

В процессе регистрации, портал отправляет релею свой публичный ключ, а релей в ответ — свой. Если был включен режим «приватного» релея (см. ниже) — порталу будет необходимо указать файл с публичным ключом релея, поскольку по сети он передаваться не будет.

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

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

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

Процесс шифрования файлов

Если чуть углубиться в детали процесса шифрования, то стоит рассказать об общеизвестном ограничении систем с публичным и приватным ключом — размер шифруемых такой системой данных сильно ограничен.

По этой причине нельзя зашифровать файл с помощью одного лишь RSA (если только очень маленький) и в обязательном порядке используется дополнительный алгоритм блочного шифрования, например AES.

Вот так выглядит в коде весь процесс, взятый из тестового класса:

TeleCrypt tc = new TeleCrypt();
// генерация пары публичный-приватный ключ
KeyPair pair = tc.generateKeys();
// сохранение публичного ключа в файл (в виде массива байт) 
File pk = new File("./public-key");
Files.write(pk.toPath(), pair.getPublic().getEncoded());

// восстановление публичного ключа из файла (из массива байт)
byte[] restoredPK = Files.readAllBytes(pk.toPath());
KeyFactory publicKeyFactory = KeyFactory.getInstance("RSA");
EncodedKeySpec publicKeySpec = new X509EncodedKeySpec(restoredPK);
PublicKey publicKey = publicKeyFactory.generatePublic(publicKeySpec);

// тестовый файл, который будем шифровать         
File src = new File("/home/alex/Downloads/weights.zip");
// генерация ключа AES, используемого для блочного шифрования
SecretKey fileKey = tc.generateFileKey();
byte[] key = fileKey.getEncoded();
// ключевой момент: шифрование ключа AES с помощью публичного ключа RSA
byte[] encKey = tc.encryptKey(key, publicKey);
// шифрование самого файла с помощью ключа AES (не зашифрованного!)        
try (FileInputStream in = new FileInputStream(src); 
     FileOutputStream out = new FileOutputStream(enc)) 
            tc.encryptData(fileKey, in, out);

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

Думаю вызовет определенный интерес еще и реализация всего процесса, поскольку Телепорта не использует каких-либо временных файлов (кроме истории с передачей каталогов):

как шифрование так и расшифровывание — потоковые и происходят в момент передачи или получения.

Еще мы не использовали ни JSON ни XML для формирования запросов и ответов а что именно использовалось и как это работает вам лучше увидеть своими глазами в исходном коде, не стоит портить этот момент прозрения вульгарными спойлерами.

Шифрование буфера обмена

С буфером обмена все несколько интересней — поскольку это общие данные и получить свою копию полученной строки должен каждый подключенный портал, релей делает «перешифрование» на ходу:

в потоке раскодирует полученное сообщение, зашифрованное публичным ключом Релея и тут же в потоке шифрует его публичным ключом портала назначения и отправляет данные.

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

Режим ручной отправки

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

Определить момент завершения копирования с учетом вложенности и без существенных потерь производительности — не представляется возможным, поскольку придется включать мониторинг на всех вложенных каталогах.

Хотя именно эту дичь делает например Dropbox. Тут мы опять пошли другим путем и реализовали механизм ручной отправки:

Как видите, все довольно просто и банально:

при получении события о появлении в каталоге отправки нового файла или каталога, будет автоматически создан файл «lock» и пока он не будет удален — Телепорта ничего отправлять не будет.

Другими словами это работает как выбиваемая подпорка — пока ее не выбить, гора не сдвинется с места.

Поскольку этот режим требуется далеко не всем — по‑умолчанию он отключен, для включения необходимо указать опцию при запуске в режиме портала:

-DuseLockFile=true

Отключение отправки

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

По-умолчанию отправка включена, отключить можно параметром:

-DallowOutgoing=false

Приватный релей

Чтобы исключить возможность подключения к Релею посторонних, каким‑то образом получивших ссылку для подключения с актуальной «seed»‑частью, был дополнительно реализован режим «приватного Релея».

Суть в том, что релей не обменивается своим публичным ключом при попытке регистрации, требуя вместо проверочное поле «hello», зашифрованное с помощью своего публичного ключа.

Чтобы это поле сформировать, клиент (портал) должен иметь файл с публичным ключом Релея к которому происходит подключение.

Ключ релей отображает в консоли при запуске, выглядит примерно так:

|TELEPORTA30820122300d06092a864886f70d01010105000382010f003082010a0282010100b04b
a71d7f0a7ce1dc9359a8e90c63971904105d443303a171e6622c8ba14121aba9e09a748293b31a65
076dda3d58237783978a8c490a714516607aca2f68577e59b707bd53b4dcfe26ed7221769081d76f
3af7b5554eb3a6f2e653a5092109a35f963d52fdf23b6978f3e273cbf95f716d12e13db380cd9688
340cc3cd00ca61a730b38e7ecbed0436bf7e86d6eee75c89515f730ad7001d41ebc42ba7b0d46a58
2d3215be71cbbd246b52f7f0c12c642c00d16b1e3617326c0c24b15057aa4c89fb345af4c54fe4a3
954750164291a2d2c8c0aa10f86db1935722d1ec80104dc139b4fe1810d678e5a2ca8af2368c4452
be458a6606eca8331386ef625e050203010001|

Пользователь копирует его и раскидывает по машинам, с которых необходимо подключаться к приватному Релею, указав при запуске:

-DrelayKey=/opt/work/tmp/tele.pub

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

Дополнительные параметры

Ниже приведен список дополнительных опций, влияющих на работу Телепорты, все они вводятся в любом порядке :

./teleporta.cmd -relay -DappDebug=true -DallowPortalNameUpdate=true -Dseed=testseed 

Или например:

./teleporta.cmd -DappDebug=true -Dclipboard=true http://majestic12:8989/testseed

Все параметры можно также вводить в конфигурационный файл teleporta.properties, без префикса -D:

appDebug=true
clipboard=true
relayUrl=http://majestic12:8989/testseed

Теперь сами опции, с пояснениями.

Включить отладочные сообщения:

-DappDebug=true

Использовать фиксированный «seed»:

-Dseed=testseed

При включении этой опции, URL подключения станет статичным, например: http://majestic12:8989/testseed и в таком виде станет доступным для использования с клиентов.

Разрешить обновлять портал с существующим названием:

-DallowPortalNameUpdate=true

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

Поскольку ключи не сохраняются на диск и генерируются при каждом запуске Телепорты — перезапуск клиента и попытка подключения к релею где есть активная (не устаревшая) сессия портала с таким именем будет порождать ошибку:

Duplicate portal name

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

Произвольное название портала:

-DportalName=samplePortal

По-умолчанию название берется из имени хоста (hostname).

Шаблон имени портала:

-DportalNameTemplate="USERNAME из HOSTNAME"

Позволяет задать шаблон имени портала, в который будет подставлено имя текущего пользователя и название хоста. USERNAME и HOSTNAME соответственно.

Не отображать логотип при запуске:

-DshowLogo=false

Не создавать ссылку на каталоги Телепорты на рабочем столе:

-DcreateDesktopLink=false

Указать путь до каталога с данными:

-DappHome=/полный/путь/до/каталога

Работает как на серверной стороне (релее) так и на клиентской (портале), по умолчанию используется домашний каталог пользователя, для портала:

/home/alex/.apps/teleporta

или для релея:

/home/alex/.apps/teleporta-relay

Указать порт, на котором будет отвечать релей:

-DappPort=9000

По умолчанию 8989, прослушиваются все интерфейсы.

Использовать «программный» мониторинг изменений в каталогах:

-DdumbWatcher=true

Актуально для сетевых или устаревших файловых систем, на которых не работает стандартный механизм File Watcher. Именно на нем работает мониторинг каталогов в Windows 98.

Свое приветствие при подключении:

-Dmotd="текст приветствия"

По-умолчанию при подключении будет отображаться сообщение:

Welcome to Teleporta Relay <версия>

Актуально для описания принадлежности релея и выдачи контактных данных.

Больше информации

Публичная разработка ведется на Github, новости и обновления по проекту выкладываются на специальной странице нашего блога.

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

Если проект ваш заинтересовал — с радостью ответим на ваши вопросы и поможем с вводом в работу, все контакты в профиле.