ky0

Похоже на какую-то блокировку. Через впн попробуйте.

В общем случае никак. Проще всего повторить самостоятельно, посмотреть кто отвечает, как отвечает - и исходя из этого начать диагностировать.

Почта - это сложно. Нет такой серебряной пули, которую "поймёт любой админ". А вот если это пожелание убрать - вариантов становится много.

location ~ ^/data/(.*)$ {
    rewrite ^/data/(.*) /site/$1 break;
    proxy_pass http://1.1.1.1;
}

"server1.docker.company.tld порт 25/tcp и server2.docker.company.tld порт 25/tcp" - при отсутствии возможности разделения запросов, аналогичного заголовку Host в HTTP, эти два сервиса должны резолвиться в разные IP-адреса, либо слушать на разных портах. Либо (но так делают относительно редко) нужна маршрутизация на основании источника. В любом случае - это требует сетевой инфраструктуры.

Что бы "не придумывать каждый раз новый порт", используют инстансы соответствующих сервисов, выставленные наружу и умеющие маршрутизировать запросы уже на уровне приложения. Для HTTP это ингресс, для SMTP - сервер входящей почты и т. д. От этого никуда не денешься.

По умолчанию nginx передаёт все заголовки. add_header, кстати, добавляет заголовок не в запрос (в сторону proxy_pass), а в ответ - клиенту.

Очень интересно будет посмотреть на ваше "переключение на резервный КД на незадействованной пока еще тачке".

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

Отправьте девопса к архитектору - пусть разберутся.

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

Опция Banner в /etc/ssh/sshd_config.

Конечно - приезжаете в ФСБ, просите проводить вас в лабораторию тестирования ТСПУ, садитесь за терминал, вводите в диалоговом окне IP вашего сервера, нажимаете "Проверить".

Сначала в цепочке перечисляете нужные порты с ACCEPT, после них делаете глобальное правило (без порта) с DROP.

И у вас какая-то чехарда с src и dst - вы точно понимаете, какой из вариантов для чего нужно юзать?

Выдавайте клиентам сессионную куку и используйте её (можно в сочетании с IP) для ключа limit_req_zone.

В любом нормальном клиенте есть аналогичная функциональность. В DBeaver, например.

Потому что у вас в локейшене указана конкретная директория, а должен быть какой-то динамический бэкенд.

Тем же, чем в любых других серверах - дёрганьем IPMI-метрик материнки. ОС, как бы, тут вообще ни при чём.

Можно, но тогда вам нужно не проксирование, а форвард трафика на уровне TCP. В противном случае любой имеющий доступ к промежуточным узлам в интернете мог бы прозрачно расшифровывать HTTPS.