ky0

Виртуалки должны быть не за NAT, ип адреса должны быть белыми и полностью доступны с виртуалок.

Это требование исходит из чего? НАТ 1 в 1 делает то, что вам нужно совершенно прозрачно.

Этот процесс называется "транспонирование". Посмотрите в сторону функции crosstab, как рекомендуют, например, вот тут.

Разберитесь сначала, что такое 0.0.0.0 и как /etc/hosts работает, прежде чем глупости туда добавлять.

Можно. Так и называется - SSH-туннель.

Зависит от того, что умеет роутер - первое, что приходит в голову, это Netflow какой-нибудь или аналоги.

Expect отлично умеет трогать подобные глупые железки, про которые написано у вас в пп. 1-3. Вполне можно всё это засковородить в рамках какого-нибудь Ансибла и т. п.

Копать в мануалы нгинкса, проксирование удалённого ресурса ничем особенно не отличается от локального.

https://nginx.org/en/docs/http/ngx_http_proxy_modu...

Разделить на два VLANа, настроить фаерволл, чтобы они друг к другу не могли ходить.

1. Гуглите, как установить поведение по умолчанию в цепочке INPUT.
   
2. Гуглите, как разрешить соединения с определённого адреса.
   

Учитывая наличие слова "модем", первый подозреваемый - интернет-канал. Для начала - всё замониторить, чтобы подтвердить подозрения.

Я бы не назвал условия "равнозначными".

Просто установить вместо апача нгинкс и php-fpm недостаточно, чтобы гарантированно получить прирост производительности. Нужно смотреть, как было настроено, как настроено сейчас, крутить крыжики, профилировать...

А в чём заключается прикладной результат описанной вами атаки? Нгинкс даже на минимальном железе может отдавать 404 ошибки гораздо с большей скоростью, чем 50 rps. Отключите логирование 404 ответов и, как советовали выше, включите fail2ban.

Имхо, это и атакой-то назвать нельзя - так, баловство...

Рекурсивные функции и SQL плохо совместимы - подобная логика обычно выносится вне СУБД, чего и вам советую.

Где-то что-то не натится или не маршрутизируется. Нгинкс ничего про ваши туннели и айписеки знать не знает.

Нужна последовательная диагностика с дампом трафика и курением сетевых настроек.

domain.ru:любой порт - это не к нгинксу. Вы можете, конечно, завернуть на фаерволле диапазон портов, например, на какой-нибудь 81-ый, для которого в нгинксе создать отдельный серверный блок с 403 отлупом - но это какая-то крайне странная идея, в целом. Обычно неиспользуемые или нуждающиеся в ограничении доступа порты просто закрывают на фаерволле.

Безусловный редирект на HTTPS в виде if`а - это костыль, юзайте стандартный return 301.

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

Не побоюсь показаться банальным: https://www.postgresql.org/docs/current/index.html

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