Проект «Телепорта»

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

Релей с подключенным порталом в работе. Даже не спрашивайте почему руки три )

Релей с подключенным порталом в работе. Даже не спрашивайте почему руки три)

Задача

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

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

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

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

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

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

Передача буфера обмена из Linux в Windows 98 в 2024м году.

Передача буфера обмена из Linux в Windows 98 в 2024 м году.

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

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

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

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

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

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

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

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

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

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

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

Специфика

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

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

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

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

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

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

Несмотря на то, что большинство решений по виртуализации вроде 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-шифрование прямо в браузере.

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

Мессенджеры

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

b16cb22d2476ba63a9e67fceee442881.png

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

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

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

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

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

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

Схема работы

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

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

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

7e8058bf24722ec51bb4182c0f127048.png

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

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

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

Такая реализация работает медленней чем прямая передача данных между компьютерами, зато гарантирует стабильность передачи в любых условиях — в первую очередь при разрывах сети и изменении клиентской конфигурации, вроде выхода в интернет через другую 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» приложение запустится в режиме Релея — будет принимать и отдавать передаваемые файлы:

0d540a979ea37f1f7affab390e0c74a6.png

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

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

http://majestic12:8989/2d52fb71ef728d8813a001a6592c8248801d844ce2c0d0a6976f10b73d3bdb463ea4cd09c1ad9a25d5b83a543238

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

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

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

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

Логотип со знаменитой жабой

Логотип со знаменитой жабой «Pepe the Frog» успел надоесть, поэтому в новых версиях стал другим

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

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

c1ad5a52c45143ab7e92fd1fad155b4b.gif

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

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

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

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

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

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

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

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

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

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

Тут используется функционал

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

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

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

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

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

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

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

9deee2cb8fea09c97270de842aa32dc4.gif

Каких-то лимитов на размер и вложенность замечено не было, поскольку мы постоянно работаем с проектами на 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, новости и обновления по проекту выкладываются на специальной странице нашего блога.

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

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

© Habrahabr.ru