ky0

Почему написание скрипта на пару десятков строчек, делающего дифференциальные бэкапы файлов каким-нибудь rdiff-backup`ом и дамп баз данных родными утилитами вы называете мучением?

Более гибко и эффективно, чем так - никакая централизованная система вам не сделает. Централизация/унификация имеет смысл, когда сервисов много и они однотипные. Для ваших же объёмов, на мой взгляд, практичнее именно самописный скрипт.

"Более защищённей" та ОС, которая настроена более пряморуким админом. То же самое относится к остальной инфраструктуре. При прочих равных - разница в "более защищённости" у популярных дистрибутивов отличается гомеопатически.

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

Для проброса реального адреса клиента в нгинксе существует соответствующий модуль.

В такой формулировке - вам нормальная СУБД и не нужна, раз вы не умеете её готовить.

СУБД предназначены для другого. Считывайте данные из базы, делайте с ними что-то любым удобным для вас способом - и записывайте обратно получившееся.

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

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

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

Стандартным образом, добавив в нгинксе серверный блок с listen`ом нужного вам порта.

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

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

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

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

Если через сенсоры нельзя, ну, что вам ещё посоветовать? Припаяйте регулировочный резистор с колёсиком :)

Вентиляторы обычно не просто так шумят. Либо от перегрева, либо от механических неполадок.

Посмотреть в список процессов, например, с помощью select from pg_stat_activity.

Очень популярный на Тостере вопрос, проистекающий из изначально неверной архитектуры.

Вы говорите "один сервер ведущий, второй - ведомый", но правильно было бы сделать один (ну или несколько - для балансировки) сервер, проксирующий запросы и отвечающий за HTTPS-взаимодействие и выпуск сертификатов, и несколько - для отдельных доменов/сайтов. Такая схема (в особенности - в сочетании с виртуализацией) гранулирует сервисы и делает инфраструктуру более гибкой и проще администрируемой.

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

Это, в целом, задача не нгинкса, а бэкэнда - что-то менять в зависимости от пользователя. И, как верно заметили выше - куки для этого подходят куда больше.

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

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

Разумеется, нет - всё, что уезжает за пределы локальной подсети, отправляется через промежуточный узел, то есть мы попадаем на третий уровень.