mikes

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

вангую что ломают вас не через субд как таковую (хотя держать ее с доступом извне странно) а через приложение. где то там есть возможность проводить инъекции и тд

первый вариант - разделите сеть на vlan согласно логической структуре. настройте соответственные области в dhcp

второй вариант (более сложный, но отвечающий вашим требованиям) настройте на коммутаторе 802.1x и выдавайте vlan и тд динамически на основе политик radius (ms ias) примененным к определенным группам в AD

передача инфы на сервер дело не хитрое
https://securitycamcenter.com/hikvision-upload-sna...
это штатный функционал многих камер и статический ip е требуется при этом

может таки начать с https://developers.trueconf.com/api/server/ и перестать дергать таблицы с бд?

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

устанавливая рокетчат устанавливается и caddy и висит на портах 80 и 443 которые пытается занять nginx
остановите caddy и nginx при установке отработает штатно

apache guacamole

Судя по логам все ок, "переходник" увиделся, дальше nut и ttyUSB0 в качестве порта.

Сам упс в таком варианте не появится как устройство, COM порт не plug and play же

Ответ на ваш вопрос - source routing
Сервер отвечает с того интерфейса на который пришел первый пакет.

а вот если вы будете кого нить пинговать к примеру, то все (окромя 10.10.118.0/24) будет уходить через 10.10.118.1 поскольку он является шлюзом по умолчанию.

Если РФ, то стоит изучить нормативку по части 152фз, как минимум это трансграничная передача данных и все вытекающее в пользовательском соглашении при этом.

Если уж хотите облачную СУБД смотрите в сторону решений из РФ

если коммутатор управляемый то можно посмотреть мак адрес устройства и на каком оно порту
если нужно смотреть со стороны клиента, на коммутаторе включите lldp (CDP для цисок) и софтом можно увидеть куда вы подключены.

Зачем выставлять rdp в интернет? Держите ресурсы за впн.

Решения к сожалению нет.
Все что есть - ужаленный фреймбуфер с разными алгоритмами сжатия.

Увы, но RDP по производительности делает всех.

Relay access denied

домен получателя точно обслуживается вашим postfix?

Нет тут противостояния.
В большинстве случаев 1 vlan - 1 subnet
Иначе вы запутаетесь в маршрутизации, к примеру как 1 /24 запихнуть в 2 vlan

Vlan делят сети на l2, а subnet на l3

Боюсь это будут уж сильно лютые костыли.
Скорее всего ваш путь должен лежать в сторону nextcloud и лучше всего на своём оборудовании, либо VDS из тех которые доступны по оплате.

Уходите от публичных облаков и живите спокойно

CG-NAT это не тип трансляции, это область применения. Грубо говоря - это nat применяемый провайдером.

Это называется keytab и целевое ПО должно поддерживать такой функционал.

Что касается прав, используйте facl и живите спокойно прописав пользователя в systemd