Николай Медведков

Selenium или playwright
https://playwright.dev/java/

Любой запрос нужно будет посылать из контекста страницы при помощи js.
На стороне Java можно будет потом модифицировать запрос и прочитать ответ, сразу как он придёт

В комментариях уже написали простое решение, а я его чуток разовью.

import typing as tp

Func = tp.Callable[[], None]  # функция без апарметров, возвращает None

class FuncMap:
  def __init__(self):
    self.map: tp.Dict[str, Func] = dict()

  def register(self, key: str) -> tp.Callable[[Func], Func]:
    def decorate(f: Func) -> Func:
      self.map[key] = f
      return f
    return decorate
  
  def get(self, key: str) -> Func:
    return self.map[key]
  
  def run(self, key: str):
    return self.map[key]()

# а вот так этот класс используется
fmap = FuncMap()

@fmap.register('11')
def test():
  print('This is test()')

fmap.run('11')

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

Активация ключа по телефону/интернету исключает лишь самый тривиальный способ "взлома" - просто копирование одной и той же лицензии по куче компьютеров без модификации исполняемых файлов.

А так, берете какую-нибудь крипто библиотеку, выдаете сертификат, в котором подписываете своим приватным ключем "Лицензия выдана ООО рога и копыта". В программе зашит ваш публичный ключ. Программа проверяет файл лицензии, что он подписан вашим ключем. Но любой "хакер" умнее вас просто вырежет эту проверку из программы.

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

Прямой ответ на ваш вопрос: https://docs.strongswan.org/docs/5.9/howtos/forwar...

Однако это неправильный, сложный подход. Всё, что вам нужно — добавить маршрут к 192.168.97.100 у VPN-клиентов через VPN-туннель, а также убедиться, что маршрутизация этого адреса не заблокирована на Raspberry (VPN-сервере, как я полагаю).

Когда я пытался подобное реализовать, то докер постучал мне по лбу и сказал: ай-ай-ай, не надо так, я не умею такое. Времена может быть и изменились, но прошлые конфиги я пока что не менял. А то есть - хостмашина теперь без нгинкс, изначально веб порты ни кто не прослушивает, но потом в игру вступает докер с нгинкс, который слушает 2 порта (80,443), и при помощи объединения в одну сеть можно контейнеры связывать между собой. Единственное, у меня выходит 2 нгинкса - 1 общий и 1 в каждом проекте, не знаю, правильно ли это, но по другому не получалось нормально настроить.

По теме: https://hub.docker.com/r/nginxproxy/nginx-proxy

1. Никаких «вечных серверов». Даже как-то неловко разъяснять такое. «Вечный сервер» — маркетинговый ход, фактически мошенничество, который закончится, как только компания изменит условия/реорганизуется/закроется. Следует читать как «ну, проработает года три, а далее — неизвестно».

2. Непонятно, какого рода у вас информация, и что именно вы понимаете под словом «захостить», также непонятен критерий автономности. Разместить информацию в публичный доступ? Должна ли она индексироваться? Нужен ли для неё контроль доступа? По какому протоколу она должна быть доступна? Она будет нужна только вам через 10 лет, или кому-то еще? Это лицензированный контент, который могут удалить по DMCA (фильмы, сериалы, музыка)? Это персональные данные (сливы баз данных)? Информация популярна и/или востребована на данный момент? Есть вероятность, что она будет сравнительно востребована через 10 лет? Информация каталогизирована? Информация тематическая (например, архив, посвященный конкретной теме, области науки и т.п.)? Важно ли удобство и скорость доступа к информации?
Технологий много, но они все разные, с разными назначениями. Ответы на перечисленные вопросы необходимы, чтобы отбросить неподходящие и подробно рассмотреть подходящие.

3. Если информация публична и востребована, и будет востребована через 10 лет, то следует использовать DC++, BitTorrent + веб-хранилища с прямыми ссылками на файл, добавив ссылки в .torrent-файл, в виде webseed.
Bittorrent существует с 2006 года, популярен, клиенты есть под все ОС, совместимость и надёжность отличные.
DC++ всё еще имеет популярность. Основное преимущество перед Bittorrent: возможность поиска файла по его имени или названию директории, возможность лёгкого обновления и дополнения информации (нет привязки к «каталогу» в виде .torrent-файла)

Если информация конфиденциальна или требует контроля доступа, и у вас и кого-либо другого не будет возможности как-либо поддерживать её в течение 10 лет (я не знаю вашу ситуацию, поэтому предположим, что вам грозит 10-летний тюремный срок), то, возможно, есть смысл оплатить облачное хранилище от крупных компаний (Google, Yandex, Microsoft, Apple) на 10 лет вперед. Это не даёт никаких гарантий, но считаю такой вариант более надёжным, нежели хостинг общего плана (и особенно VPS).

Если информации немного, она не защищена авторскими правами, каталогизирована и полезна, можно банально разместить её на давно существующих бесплатных хостингах, вроде Ucoz, Google Sites, Neocities, загрузить на Bitbucket, Github, Sourceforge (последний поддерживает хранение больших файлов, которые можно скачать по прямой ссылке, вполне подойдёт в качестве webseed для торрента, к слову).

Если не боитесь попробовать развивающиеся, но еще не устоявшиеся технологии, присмотритесь к IPFS. Он работает по принципу Bittorrent, но позволяет получать доступ к информации через HTTP, а также поддерживается крупными игроками в лице Cloudflare, у которой есть шлюз из интернета в IPFS: https://cloudflare-ipfs.com/
Я держу несколько статичных сайтов с собственными доменами в IPFS, на домашнем компьютере, за шлюзом Cloudflare. Преимущества: все плюсы BitTorrent, возможность доступа как к сайту (в т.ч. на своём домене), индексация поисковиками, есть сервисы по долгосрочному платному хранению файлов (eternum.io, pinata.cloud), возможность лёгкого обновления информации. Недостатки: работает всё ещё достаточно медленно и нестабильно, только статичные сайты.

4. Судя по вашему комментарию выше, у вас всего 100 ГБ медиафайлов. Это вообще ерунда. Если они публичны и представляют ценность хотя бы для узкого круга людей, можете захостить их у меня, через проект Schare: https://valdikss.org.ru/schare/
Мой критерий автономности — максимальная независимость от сторонней инфраструктуры, поэтому файлы хостятся на домашнем сервере, а раздаются в сетях децентрализованного файлообмена.

Да - это реально, маршрутизация или маршрутизация + iptables NAT в руки и всё получится.