Евгений Хлебников

1. обратите внимание на ответ hint000, мне кажется, его мнение будет полезно.

Я бы предложил следующий подход:
1. Полная настройка почтового сервера на новом хостинге. (SPF, DKIM, проверка в спам базах и тд и тп) - полноценная. Завести все почтовые ящики, аналогично имеющимся. Добавить в MX с более низким приоритетом. Проверить отправку почты через новый почтовый сервер (получать , из-за приоритетов MX он ее все равно не будет)
2. Подготовка к миграции почтовых ящиков. Хорошо, если есть локальные клиенты (не вебмейл) - часто у них есть возможность архивации, благодаря чему после перенастройки на новый сервис можно все довольно быстро восстановить - подготовить бэкап почтовых ящиков, персонально для каждого пользователя
3. миграция.
Если пользователей немного:
Переключаем MX, почта начинает идти на новый хостинг, но не сразу - часть писем придется ловить в старом и переносить дополнительно. Перенастраиваем почтовые клиенты на новый хостинг. Загружаем подготовленные архивы писем в клиенты.

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

документацию читать пытались?
и вообще, первая ссылка в гугле https://github.com/dganic/Graylog-ContentPack-MinIO

с A-записями вы далеко не уедете, для вашей схемы нужен CNAME, как в комментариях уже написали
И, если будете избавляться от A записей, надо с каждым клиентом прорабатывать отдельно: возможно, им A запись нужна потому, что в их DNS 2-го уровня зоне больше ничего нет (и у них нет других сервисов), а запись необходима для работы txt и прочих записей (например для того чтобы почта ходила). Здесь, как варианты которые можете обсудить с ними:
1. если их DNS провайдер предоставляет услугу хостинга - можно предложить направить их A запись в зоне второго уровня туда, на статический сайт с редиректом на поддомен, который, в свою очередь CNAME-ом смотрит на ваш хостинг
2. предоставить им подобный статический сервис, который вы не будете менять
3. сделать точку входа для A записей, которая не будет меняться, но и не будет содержать приложения - только балансер, направляющий трафик на ваше приложение
Еще возможно, им принципиально важно чтобы ваш сервис был на домене второго уровня. Тогда может помочь перенос с их стороны DNS хостинга на провайдера, поддерживающего ALIAS записи (он же CNAME FLATTENING у CloudFlare) - они позволяют "прописывать" в зоне 2 уровня CNAME (который динамически обновляется и преобразуется по сути в A запись) без A записи
Для переключения
Самый, наверное, простой способ контролируемо переносить на другой хостинг это уникальные таргеты для CNAME
к примеру, клиент1 получает client1.service.name который и прописывает в CNAME у себя
В случае когда нет необходимости разделять клиентов по хостингам, у вас в DNS будет запись *.service.name -> IP хостинга 1
переезжает client13: добавляем client13.service.name -> IP хостинга 2
то есть client13 смотрит на новый хостинг а все остальные - на старый

Не претендую на полноту вариантов, но похожая задача решалась при переезде (и A запись тоже была, но там от нее не избавлялись, ибо чревато переосмыслением продукта и выпиливанием фич)
Постепенное переключение решалось перекидыванием трафика на стороне LB - с помощью настройки proxy protocol. В этом случае весь трафик все равно шел через одну точку входа, но старый хостинг разгружался - клиенты постепенно перекидывались на новый, для тестирования устойчивости и мониторинга нагрузки. А затем была долгая и муторная работа команды суппорта с ожиданием клиентов которые после 10 китайского предупреждения еще не сменили IP у себя в A записях.. та еще история

гитлаб указан в тегах верно?
поместите эти параметры в CICD переменные (поддерживаются в том числе файлы, а так же маскировка секретов), лимитировав их использование конкретным ENV-ом
https://docs.gitlab.com/ci/environments/
ну и укажите в деплой шагах ENV-ы (можно брать из имени бранча динамически)
хранить в репе все таки не стоит

по статье пробовали пройтись?

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

Альтернативные варианты:
- оплата CloudFlare для увеличения лимита (200 - лимит DNS записей для бесплатного тарифа, в платных квоты больше)
- перенос только одного сайта, оставив все остальные DNS записи на reg.ru (это возможно если сайт находится на субдомене типа www.site.ru и не получится простым способом если сайт на втором уровне - site.ru)
например ваша DNS зона где находится всё это, включая почту: site.ru а сайт, для которого требуется перенос - www.site.ru. Вы в CloudFlare добавляете только www.site.ru и создаете в DNS на reg.ru NS записи только для www.site.ru - в таком случае у вас за CloudFlare спрячется только один сайт, остальные будут работать по старой схеме. Впрочем вы можете точно так же перенести туда www2.site.ru, mysuperhomepage.site.ru и так далее - только те субдомены которые хотите спрятать за CloudFlare, учитывая общий лимит в 200 DNS записей. Почта и основная масса доменов, соответственно, останется на reg.ru

Есть и другие варианты решения, но они требуют пересмотра подхода к работе с DNS записями, а учитывая что вы написали

Я совсем не разбираюсь в этом, поэтому прошу помощи.

то они вряд ли вам подойдут. Вышеописанные больше "административные" и не требуют глубоких знаний - только следование инструкциям

надо настроить для подсистемы enc уровень логирования
можно совсем заглушить ее поставив -1
https://docs.strongswan.org/docs/latest/config/log...

для начала попробуйте восстановить загрузчик на новом железе
грузитесь с ISO\флешки и проверяете, видите ли вы вообще данные на диске
затем восстановление (или создание нового) загрузчика
Возможно, системе еще не будет хватать драйверов того самого Avago MegaRaid

Дополнительно ко всему что уже написали: винда умеет балансировать интерфейсами

для нее нет признака что "этот gw сдох надо использовать другой" - вместо этого "на этом WAN нет интернета - пытаемся ходить через следующий по метрике WAN"

пытаясь заставить винду балансировать роутами вы на пользовательской машине хотите реализовать сценарий роутера (который, возможно, доступен в серверном функционале RRAS но я никогда из винды роутер не делал - не могу сказать с уверенностью )
Пользовательский сценарий: вот провод от провайдера, вот свисток LTE от другого. Два интерфейса. Не работает провайдер - идем через свисток (причем винда сама по своей логике ставит метрики - руководствуясь "платностью" соединения и скоростью сети, которые(метрики), впрочем, можно переназначить) . А играться роутами и настраивать тонкую логику - это пожалуйста самостоятельно, тем более что скрипты позволяют делать все что угодно

(их ведь тысячи!),

их миллионы, если не больше, и, кроме английского, надо еще учитывать специфику международную: в моем проекте к нам однажды повадились ходить боты из Таиланда, Камбоджи и Вьетнама. Ключевые слова там совершенно другие, и разные, даже несмотря на общую тематику казино
Чем бороться с фантазией глобального человечества проще работать вайтлистом - вы же точно знаете какие пути ваше приложение обрабатывает. Остальное - в топку, без всяких размышлений. С кверями правда посложнее.
Кроме того помогает знать своего пользователя и закрыться по геолокации (например через CloudFlare если модуля геолокации в вашем вебсервере\прокси нет) от всех стран которые вам не нужны
Ну и (я вот не спец в nginx но вижу что подобный функционал есть в nginx plus который вроде платный) в вебсерверах и прокси есть различные механизмы rate limiting и dynamic acl (на примере haproxy): например считать error rate для ip и блокировать его на определенное время автоматически (вплоть до неразрешения устанавливать TCP сессию) или устроить подобие ханипота: все кто является например на ../.git автоматом попадают в динамический ACL которому запрещен доступ к приложению в принципе

к серваку не будет доступа по ssh в рабочем режиме

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

Опять же вызывает вопросы "закрытость" контура: закрыт он от доступа извне или доступ наружу изнутри контура тоже отсутствует? Как тогда предполагается доставлять изменения?

Вы что-то переусложняете
В сети провайдера два устройства вряд ли будут сосуществовать, поэтому если первым вы поставите сервер - переносите весь роутинг на него, а роутер оставляйте как wifi свисток (насколько я понял он у вас в такой роли планируется)

Альтернативно - оставить все как есть, покопать возможности стоковой прошивки роутера на предмет маршрутизации и проброса портов (чтобы ваш сервис на сервере выставить в интернет)

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

Если добавлена роль File Server Resource Management то https://learn.microsoft.com/en-us/windows-server/s...
Если нет - запускайте в scheduler задачу со скриптом который берет lastwritedate у всех файлов в папке и удаляет то что дальше 3 дней от текущего

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

А вообще крайне не рекомендую находить на github пользователя bol-van и его zapret, устанавливать это на ваш локальный сервер\пк и делать локальный же прокси - часть сервисов все равно будет доступна только через VPN.

Потому что PublicKeyAuthentication так и работает - вы предлагаете серверу публичный ключ, он же, проверяя соответствующий приватный ключ, допускает вас или не допускает
Про форвардинг

When the user uses an SSH client on the server, the client will try to contact the agent implemented by the server and the server then forwards the request to the client that originally contacted the server, which further forwards it to the local agent

Вы инициируете вышеописанную цепочку когда с сервера(выделенного жирным) ssh клиентом пытаетесь подключиться к другому серверу

Если форвардинг не работает - проверяйте:
To use agent forwarding, the ForwardAgent option must be set to yes on the client (see ssh_config) and the AllowAgentForwarding option must be set to yes on the server (see sshd_config)
Ну и запущен ли SSH агент на первоначальном клиенте и на первом сервере

А вообще - документация https://www.ssh.com/academy/ssh/agent

Если программа консольная - засуньте ее в сервис, с настройкой авторестарта
с помощью sc.exe (специально пишу с расширением, поскольку в Posh - sc это алиас для коммандлета set-content)
или используйте nssm