Проект «Телепорта»
Хочу поделиться с широкой общественностью одним нашим внутренним инструментом, совсем недавно выложенным в публичный доступ. Читатели заставшие ФИДО думаю обнаружат знакомые очертания ;)
Релей с подключенным порталом в работе. Даже не спрашивайте почему руки три)
Задача
Телепорта решает две простые, скучные и очень приземленные задачи:
Разумеется на свете уже существует 1000 и одно готовое решение для этого, поэтому ниже опишу зачем нужно еще одно, которое вы тоже возможно начнете использовать после прочтения этой статьи.
А пока посмотрим как это выглядит в работе:
Передача бинарного файла между двумя компьютерами, виртуальная машина тут только для демонстрации на одном экране
Для большего фана и в качестве демонстрации переносимости использовалась работающая Windows 98 в виртуальной машине с сетью.
Передача буфера обмена из Linux в Windows 98 в 2024 м году.
Почему и зачем
На дворе 2024й год, по улицам вовсю катаются роботы-курьеры, по дорогам — электромобили с платными обновлениями, а ваш смартфон давно стал считать себя умнее вас и вообще в шаге от осознания себя как личности.
Кругом искусственный интеллект, биткойны и боевые роботы,
но стоит попробовать перекинуть пару файлов между двумя рядом стоящими ноутбуками и сразу начинается каменный век.
Как так получилось и где именно прогресс пошел не туда сказать затрудняюсь, но для иллюстрации ниже описаны самые популярные решения данной задачи, вместе с сопутствующими проблемами и рисками.
Для большей конкретики стоит рассказать о типовых сценариях применения Телепорты в нашей компании:
Безопасное перекидывание файлов между машинами разработчиков в команде, в том числе удаленных, работающих из самых невероятных и богом забытых мест;
Выкладывание обновлений на тестовые сервера, в том числе чужие, защищенные и закрытые;
Проброс файлов и буфера обмена в виртуальные машины.
Хотелось бы добавить еще один сценарий — обмен файлами с заказчиками, но к сожалению не удалось переломить застарелую привычку отправлять файлы почтой и через мессенджеры.
Так что платежные поручения, счета фактуры и договора все также пересылаются обычной почтой.
Специфика
Поскольку занимаемся разработкой ПО, наши внутренние процессы сильно связаны именно с этим делом. Но с точки зрения применимости все тоже самое будет актуально и например для дизайн‑студии, типографии, бухгалтерии — в любом месте где есть «наколенный» документооборот, основанный на файлах и еще не доросший до масштабов применения ERP.
Файловый обмен между разработчиками
Разработчики чаще всего обмениваются тестовыми проектами, сборками и примерами кода, что обычно выглядит как каталог со сложной структурой и кучей непонятных (для обывателя) файлов. Поэтому надо уметь передавать не отдельные файлы, а целые каталоги, со сложной структурой.
Выкладка обновлений
Выкладывание обновлений на сервер требует определенной автоматики, где сама передача файлов — лишь часть процесса. Поэтому решение должно быть управляемым снаружи — через внешние скрипты. Еще важно чтобы решение не требовало открытия отдельных входящих портов для своей работы, поскольку это рано или поздно приведет к попытке взлома или вывода из строя (DDoS).
Проброс файлов в виртуальные машины
Несмотря на то, что большинство решений по виртуализации вроде 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 м веке для того чтобы отгонять настырных роботов, протыкивающих ссылки на сервере различными методами — от простого перебора до сложных масок в поисках уязвимостей.
Для запуска портала (клиентской части) необходимо указать в качестве аргумента тот самый адрес, полученный от Релея:
Логотип со знаменитой жабой «Pepe the Frog» успел надоесть, поэтому в новых версиях стал другим
Телепорта умеет отдавать готовый клиентский дистрибутив, сразу настроенный для подключения Релею, с которого дистрибутив был скачан.
Вот так это выглядит:
Как видите получается очень простое развертывание для конечных пользователей, которое тем не менее можно отключить специальным параметром (см. ниже)
Передача файлов
Теперь расскажу про саму передачу файлов, как это выглядит с точки зрения конечного пользователя.
Тут мы также достаточно долго экспериментировали, а итоговый вариант был вдохновлен 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, новости и обновления по проекту выкладываются на специальной странице нашего блога.
На данный момент Телепорта активно используется внутри нашей команды и еще несколькими в тестовом режиме, также есть отдельные установки среди наших клиентов и читателей блога.
Если проект ваш заинтересовал — с радостью ответим на ваши вопросы и поможем с вводом в работу, все контакты в профиле.