AlexVWill

с клиента Element X ошибка

Какого рода ошибка, что говорит клиент, какие данные в логе? Если вручную зарегистрировать нового клиента через сервер (через cli или webadmin), то он может работать через Element X?

Такое есть, или это бета?

да, такое есть, это уже не бета по моему, по крайней мере Element Call c недавнего обновления (по моему прошлое или позапрошлое) работает отлично, с автоматическим включением видео (чего не было на beta), но для этого надо новую версию сервера Synapse поднимать, 130 по моему, и LiveKit настроить

А зачем это нужно? USB предполагает использование на конкретном девайсе, а что мешает именно на этот девайс поставить клиента?

Если просто сообщение (без ответа) то https://man.archlinux.org/man/notify-send.1.en
Если с обработкой получения и ответа, то это надо какой то мессенджер. Смотри например RocketChat.
Или какой то Jabber клиент-сервер: https://xmpp.org/software/?platform=linux

по дефолту настроенный RDP (логин_пароль) не умеет защищаться от брутфорс, поэтому лучше его настроить или через AD или если нет такой возможности завернуть его в какой то туннель, хотябы в SSH (настройки Remmna позволяют подключаться к такому клиенту) но лучше делать по уму через VPN, тут все верно написали... там кстати, и не нужны будут ограничения по портам и IP...

Смотря что подразумевать под "первым" и "вторым". Я так понимаю, вопрос в том, в каком внешнем туннеле будет какой внутренний туннель, т.е. какой VPN будет "внешней" матрешкой, а какой внутренней.
Ну, судя по условиям - внешним туннелем будет тот, что на роутере, а внутреннем - тот, что на клиенте. Простая логика - весь трафик клиента идет через роутер (если он к нему подключен), поэтому если на роутере настроен какой то логический интерфейс подключенный к VPN1 и настроено правило Mangle к примеру, которое направляет весь трафик со всех внутренних интрефейсов или IP роутера (можно и так и эдак настроить) в этот интрефейс через настроенный маршрут, то клиент может и не знать, что он находится внутри туннеля VPN1, просто весь его трафик уйдет в VPN1. В том числе если клиент подключается к VPN2, всеравно весь трафик продолжает ходить через VPN1.
Если же вопрос в том, какой IP будет виден на удаленном сервере, то это зависит от того, на каких серверах сидят VPN1 и VPN2, конечно, если они на разных, то VPN2 выходя из сервера VPN1 пойдет на другой сервер, со своим IP, а оттуда до конечно хоста, поэтому в этом случае конечный хост увидит IP VPN2
Логика примерно такая, если я конечно верно понял вопрос.

api.myip.com

Есть такое понятие gateway. Условно говоря, это IP адрес, присвоенный сетевому интерфейсу, через который пойдет IP пакет, прежде чем его обработает внутренняя маршрутизация, и он уйдет на внешнюю маршрутизацию в роутер например. И default gateway - это gateway, который система и приложения его использует по умолчанию
В Linux его можно увидеть через команду ip r, в винде через ipconfig
Можно действовать 2мя путями либо устройство (либо виртуальное устройство tun для VPN) назначает свой собственный default gateway, либо после попадания в default getaway прописывается внутренний маршрут для передачи пакетов в VPN туннель, а дальше внутри него через роутер для сервера.

А сделать Wi-Fi роутер из ноута можно?

Да, можно, некоторые Linux это позволяют сделать просто нажатием кнопки.
На скриншоте Turn on WiFi Hotspot как раз оно, надо чтобы WIFi карта поддерживала этот режим.

Пишут ad guard home и pi-hole не помогут с этим.

Это DNS серверы, и работают они на уровне DNS запросов. Т.е. они блокируют только ту рекламу, которая приходит с отдельных рекламных серверов. Google AdWords к примеру. Ну и подобных. Вся реклама, что встроена в Youtube передается при просмотре с того же сервера, поэтому она не блокируется через DNS, для этого есть блокировщики рекламы, основанные на фильтрации JS, которые эту рекламу загружают, Adblock Plus, uBlock и подобные. Но они работают только в браузере, в стандартных родных клиента YT они не работают. Поэтому там рекламу нельза заблокировать (хотя российским IP её не показывают, но через VPN будет естественно европейский). В этом случае поможет нестрандартный клиенет YT. Там рекламу можно заблокировать, если она конечно не в сам ролик встроена )))

В NAT надо по другому правило указать:

add action=dst-nat chain=dstnat comment="WebServer" dst-port=443 protocol=tcp to-addresses=192.168.88.254 to-ports=443

для того, чтобы открыть порт 443 к какому то Web серверу внутри сети по адресу 192.168.88.254

RDP это протокол Windows, для того, чтобы он работал на Linux, на удаленной машине, к которой пытаются таким образом подключаться должен быть поднят и настроен соответствующий сервер. XRDP например. Ну и должны быть соответственно открыты порты до сервера.
По ссылке можно посмотреть подробности: https://www.digitalocean.com/community/tutorials/h...

Можно ли настроить маршрутизатор так

Нет. Маршрутизатор тут вообще ни при чем, это не его задача, он вообще не должен знать какие там Radmin или что-там-еще у вас работает. Задача маршрутизатора доставить TCP/IP пакеты данных от одного IP до другого, все более высокие уровни данных разруливаются соответствующими серверами в сети.

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

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

Гнать торрента через VPS, да ещё и в ЕС? Во первых проживет такой сервер пару дней, и сразу страйк получит, а во вторых скорость будет ниже, с учётом затрат на маршрутизацию, да и придется сервер искать с безлимитным трафиком.
Все это нахрена, а главное зачем? Если торренты все напрямую качаются с домашнего сервера туда и сюда?

Судя по всему, тебе надо либо STUN сервер, либо что-то подобное, потому что по сути ты пытаешься наладить p2p. Как то примерно так: https://voxlink.ru/kb/asterisk-configuration/obzor...
Эта щтука как раз просто говоря предназначена для того, чтобы все устройства за NAT'ом видели свои реальные IP и в зависимости от этого применяли те или иные правила маршрутизации или действия.

У тебя сертификат Let’s Encrypt R12 RSA 2048 - https://letsencrypt.org/certificates/
С ним у хрома похоже какие то траблы.
Попробуй сделать Let’s Encrypt E7 ECDSA P-384, с ним никогда никаких проблем не встречал. По моему за это ключ -csr отвечает, точно не помню.

Как в этой связке использовать VPN?

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

Tronscan имеет свой API и через него можно решить вопрос контроля транзакции на определенные кошельки.
Только непонятно

Основной вопрос: каким образом отслеживать факт его пополнения?

А вам это зачем? Т.е. зачем - понятно, зачем сам факт пополнения отслеживать по всем клиентам? Сама по себе трансакция это дело клиента, если за этим не должно последовать немедленно порождение какого либо события, ну т.е. клиент не открыл свою страницу в приложении с балансом, то и факт отслеживания трансакции можно поставить в какую то дальнюю очередь. Тут все очень конечно индивидуально, но не понимая всего проекта трудно что-то советовать умное на этот счёт.