Проект "Телепорта"

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

Задача

Начну как обычно — с пафосного вброса описания решаемой проблемы:

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

Но копирование пары обычных файлов с одного рядом стоящего ноутбука на другой почему-то превратилось в неподъемную задачу:

прогресс свернул куда-то не туда и эта столь простая (казалось бы) вещь на практике превратилась в какой-то дикий треш и угар.

Вообще на подобный вброс таглайн есть две противоположные реакции:

• все за#бись и давно реализовано, просто автор — криворукий мудак;
• ля красава, поцоны ваще ребята — сделали по красоте!

Поскольку проект живет где-то с 2015го года и был неоднократно проверен в боевых условиях — могу сказать что правда где-то по середине:

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

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

FTP, SFTP и TFTP

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

Нет, конечно если вы — адов сисодмин и мамкин Unix-гуру (как автор), в этом случае у вас даже кирпич будет на пинги отвечать и никакой проблемы нет.

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

Тебя взломают и поимеют, не делай этого не выходи из дома.

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

Теперь немного про протокол FTP и его «безопасный» аналог — SFTP. Для начала как FTP так и SFTP это чистый клиент-сервер без посредников и сервер придется поднимать на каждой машине отдельно, ручками да.

Сервер надо отдельно поднимать и настраивать на уровне ОС — 21й порт это привилегированный порт (VIP в мире Unix) и в нормальных ОС он так просто не прослушивается.

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

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

• IP-адрес или доменное машины
• порт (опционально)
• логин и пароль для входа
• приватный ключ (для SFTP)

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

По этой причине вам например придется выгребать загруженные файлы из какой-нибудь жопы мира в /var или /tmp.

И затем ручками уже переносить куда вам надо.

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

С учетом масштаба и важности данного проекта — сие действие это такой неслабый намек на будущее данного протокола.

RSYNC и SCP

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

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

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

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

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

Правда весело?

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

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

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

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

И на то есть причины, примерно такие же, которые возникнут при попытке прокатиться на творении Лоренцо Феррари по родной деревне.

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

Файлопомойки

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

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

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

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

Мессенджеры

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

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

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

Отчет надо было срочно отправить, что поделать.

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

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

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

Схема работы

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

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

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

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

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

В начале файлы отправляются на этот самый релей, с указанием адресата — какому порталу файл предназначен.

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

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

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

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

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

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

Вот такой электронный концлагерь.

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

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

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

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

Технологии

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

Проект реализован на чистой Java, без каких-либо внешних зависимостей и библиотек и это одна из трех реализованных версий данной идеи.

У 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.

Потому что в старых ОС разумеется нет новых версий компилятора с поддержкой новых стандартов.

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

Телепорта это в первую очередь утилита и наш рабочий инструмент, для которого концепция «write once — run everywhere» является оптимальной.

Так что одна и та же собранная версия спокойно работает прямо сейчас на:

А вы говорите «зоопарк».

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

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

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

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

По умолчанию с версии 3.1.6 будет запущен релей с настройками "по-умолчанию":

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

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

http://majestic12:8989/2d52fb71ef728d8813a001a6592c8248801d844ce2c0d0a6976f10b73d3bdb463ea4cd09c1ad9a25d5b83a543238

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

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

Вот так это выглядело в работе в одной из первых версий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На другой стороне происходит получение этого архива и распаковка.

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

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

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

Для тестов мы делали переброску исходников Intellij Idea Community Edition и все отработало.

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

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

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

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

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

-Dclipboard=true

при запуске Телепорты в клиентском режиме.

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

Основное применение это переброска буфера обмена по сети — на соседний ноутбук.

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

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

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

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

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

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

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

Известные проблемы

Опишу заранее ряд известных проблем, собранных за время эксплуатации.

Создание ссылки

Уже не актуально, т.к. в версии 3.1.4 реализовали полностью программное создание ссылки.

В Windows не всегда отрабатывает создание ссылки на каталог Телепорты:

К сожалению исправить это из Java невозможно — надо настраивать политики безопасности в системе:

With Windows (W7), you can add a user to the list of who may create symbolic links (without disabling UAC) using security policies. Run "secpol.msc" and change "Security Settings|Local Policies|User Rights Assignment|Create symbolic links

На работу Телепорты это никак не влияет, чтобы сообщение об ошибке не мозолило глаз — можно отключить попытку создания ссылки с помощью параметра -DcreateDesktopLink=false.

Копирование большой папки или файла

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

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

В версии 3.1.3 добавлен режим ручной блокировки (см. ниже) как раз для решения данной проблемы.

Использование старых или медленных файловых систем

Стандартный для Java WatcherService плохо работает с устаревшими FAT16/FAT32 или сетевыми файловыми системами.

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

Включается программный Watcher с помощью параметра:

-DdumbWatcher=true

На записи выше, где демонстрируется работа Windows 98 как раз используется эта реализация для работы с устаревшей файловой системой.

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

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

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

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

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

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

-DappDebug=true

Фиксированный seed:

-Dseed=testseed

При включении URL подключения станет статичным, например: http://majestic12:8989/testseed

и в таком виде станет доступным для использования с клиентов.

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

-DallowPortalNameUpdate=true

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

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

-DportalName=samplePortal

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

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

-DshowLogo=false

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

-DcreateDesktopLink=false

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

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

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

/home/alex/.apps/teleporta

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

/home/alex/.apps/teleporta-relay

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

-DappPort=9000

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

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

-DdumbWatcher=true

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

Обновление 3.1.1

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

Для включения укажите параметр:

-DprivateRelay=true

При запуске релея будет отображаться публичный ключ:

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

Его необходимо сохранить в файл, который затем указать при запуске в режиме портала:

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

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

Обновление 3.1.2

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

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

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

Достаточно кликнуть по ссылке, которую генерирует релей при запуске:

INFO: Public Teleporta Relay started: http://amarok:8989/4d9575d00ace270aa168c8d043a99984c0ba4807043719b4629461f31cf828d30645

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

Достаточно распаковать архив и запустить.

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

Для отключения этой замечательной фичи:

-DselfDownload=false

Обновление 3.1.3

Добавлен режим ручной блокировки, при копировании файла или каталога в «Исходящие» (to) теперь будет формироваться файл lock вместо немедленного запуска передачи файлов.

Логика такая:

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

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

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

-DuseLockFile=true

Обновление 3.1.4

Добавлено полностью программное создание .lnk файла на Windows, чтобы не бодаться с UAC.

Добавлено полное отключение отправки с портала (актуально для серверов):

-DallowOutgoing=false

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

Добавлено настраиваемое поведение для недоставленных файлов при запуске:

-DclearOutgoing=true

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

Добавлено настраиваемое приветствие:

-Dmotd="This is my awesome relay!"

которое будет отображаться на портале при подключении.

Добавлена возможность указать шаблон названия портала:

-DportalNameTemplate="USERNAME from HOSTNAME"

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

Обновление 3.1.6

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

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

-Dlang=ru 

Для русского или:

-Dlang=en 

для английского.

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

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

Функционал можно отключить параметром:

-DrelayHasPortal=false

Публичная версия

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

Проект собирается в один шаг с помощью обычного Apache Maven:

mvn clean package

В результате сборки в каталоге target появится запускаемый файл teleporta.cmd, запускаемый на любой ОС где есть любая версия JDK/JRE версии 1.8 или выше.

Для Linux/Unix окружений необходимо выставить бит запуска:

chmod +x ./teleporta.cmd

Для Windows скрипт попытается скачать JRE 1.8 если не найдет установленную версию.

С нетерпением ждем отзывов по использованию.

Коммерческая версия

Существует более продвинутая коммерческая версия Телепорты, с локализацией, в которой используется многоуровневая обфрускация протокола и данных, защита от кейлоггеров, защита от тайминг атак, MFA, постквантовая криптография: NTRU + XChaCha и много чего еще.

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

Подключение к релею:

В подключенном состоянии:

Ключи:

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

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

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