res2001

В корневые нужно пихать только сертификат ЦА. Это контейнер для них.

Самоподписанный сертификат - это другое. Это когда у вас нет ЦА и вы просто выпускаете сертификат сервера и он сам себя подписывает. Такой простейший вариант сертификата.

Сертификат ЦА - самоподписанный, т.к. его никто не подписывавет, но используете вы сертификат сервера и возможно клиента, а эти оба сертификата подписываются ЦА и они не самоподписанные. В работе используется сертификат ЦА только для проверки подписи предоставленного сертификата сервера и/или клиента, дальше для всего используются серверный и клиентский сертификаты.
Не знаю особенностей Jitsi Meet, но по ссылке нет самоподписанных сертификатов. Там упор делается на использование LetsEncrypt, но по большому счету разницы нет - используете ли вы ЦА от LetsEncrypt или свой собственный. В случае своего ЦА , вы должны обеспечить возможность проверки сертификатов, правильно установив сертификат ЦА, тогда как сертификат LetsEncrypt (и других известных публичных ЦА) обычно уже установлен в системе. Процесс контроля за сроком сертификатов, их перевыпуском, ведением списка отозванных сертификатов и его доступностью то же ложится на вас.

Любой сертификат содержит в себе публичный ключ владельца сертификата. Вторая часть ключа - секретный ключ - идет в отдельном файле. Серктеный ключ ЦА должен находится только на самом ЦА, он требуется только для выпуска новых клиентских сертификатов. В остальных случаях используется только сертификат ЦА, который можно свободно распространять. Аналогично и секретные ключи сервера/клиента - они должны находиться только у владельца ключа.

Вам нужно на роутере добавить маршрут до сети 192.168.5.0/24 через IP eth0.
На самом компе добавлять маршрут не нужно, т.к. он имеет IP адреса во всех задействованных сетях, то маршруты уже есть.
Пингами с роутера проверяете доступность IP eth1.
Т.к. eth2 работает мимо ОС, то схема должна работать.
Естественно на компе надо включить маршрутизацию пакетов и настроить/выключить фаервол.
Сниффером слушаете eth1.

Более "чистая" и точно рабочая схема была бы, если использовать второй ПК: eth2<=>второй ПК<=>router
На втором ПК можно настраивать сниффер и видеть весь трафик.

В скрипте после создания ссылки измените ее владельца с помощью chown.

На роутере пробрасываете порты на локальный адрес и порт веб сервера. При этом внешний порт может отличаться от внутреннего, используемого веб сервером.
После этого веб сервер должен быть доступен из вне по внешнему адресу роутера.
Если по какой-то причине сайт не работает - включаете логи на веб сервере и смотрите какие запросы приходят и ответы сервера. Устраняете ошибки в конфигурации веб сервера.
Прохождению трафика может препятсятвовать фаервол. Фаервол может быть и на веб сервере и на роутере и оба могут блокировать трафик.
Тестируйте для начала по внешнему IP роутера. Только после того как этот вариант заработает, настраиваете DNS и продолжаете тестирование по доменному имени. Не стоит сразу все мешать в кучу, так будет труднее разбираться.

Можно сделать несколько конфигурационных файлов службы для systemd и в каждом передавать в параметрах свой конфиг.
Многие службы уже содержат подобный "универсальный" конфигруационный файл, который позволяет из "коробки" запускать несколько экземпляров службы. Например, такой у openvpn, на сколько я помню.
В общем, разбирайтесь с настройкой служб в systemd. Там не то что бы сильно сложно.

Заберите у юзеров админские права на рабочих станциях и активируйте везде Windows Defender, с вирусами станет легче.
Какой выбрать линукс - пофиг, тот, что лучше знаете, но берите стабильную ветку дистра. Можно без GUI.

Используйте в конфиге сервера опцию keepalive. Это заставит OpenVPN отправлять тестовые пинги для проверки соединения.
https://openvpn.net/community-resources/reference-...

Можно. Ничего не надо настраивать.

Если пользователи сидят в одной локальной сети то ssh избыточна, используйте стандартные средства: виндовые шары/samba.
Если нужен доступ из инета, то можно использовать sshfs. Или WebDAV какой-нибудь.

Напишите конфиг службы для systemd и запускайте ваш чат как службу через стандартные механизмы ОС. Логи будут писаться в файл в /var/log, Логирование можно настроить так что бы для вашего приложения был отдельный файл.
Конфиги служб systemd в Ubuntu лежат в /lib/systemd/system файлы с расширением .service. Можете взять какой-нибудь для примера.

Порт на хосте открыт, но трафик может блокироваться локальным фаерволом или не локальным.
"Connection refused" обычно говорит о том, что нет связи с сервером. Связи может не быть по разным причинам. Порты - только одна из них.

Нельзя указывать адрес хоста 127.0.0.1 - на этом адресе вы сможете получать и передавать пакеты только на него же (даже на виртуалку не сможете, потому что на виртуалке свой собственный адрес 127.0.0.1 ).
Как правило нет нужды в пробросе портов, достаточно просто правильно выставить тип подключения в настройках сетевого адаптера и сможете обращаться к ВМ по ее IP адресу.
Я обычно ставлю тип подключения "Виртуальный адаптер хоста", если к виртуалке нужен доступ только с хоста. В этом случае по умолчанию виртуалке присваивается адрес из сети 192.168.56.0/24, на хосте при этом 192.168.56.1.
Вот тут популярно в картинках расписаны все типа подключения, выбирайте, какой вам нужен: https://www.nakivo.com/blog/virtualbox-network-set...

Стандартное разрешение никсов на выполнение: sudo chmod +x <имя файла скрипта>
При этом в скрипте первая строка должна быть чем-то вроде: #!/bin/bash
Варианты могут быть разные, в зависимости от ЯП на котором написан скрипт, первые 2 символа обязательные.

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

linux-notes.org/otpravit-soobshhenie-drugomu-pol-z...