Новый VPS привлекает ботов быстрее, чем кажется: безопасность сервера на старте низка. Провайдер берёт на себя изоляцию на уровне гипервизора и сетевую связность. Всё, что выше ОС, остаётся зоной ответственности клиента.

Что провайдер защищает, а что – нет

Хостинг-провайдер отвечает за физическую инфраструктуру, гипервизор и сетевую изоляцию между машинами. Операционная система, открытые порты, учётные записи и конфигурации сервисов остаются зоной ответственности администратора.

После выдачи машины проверьте стартовые настройки доступа: на части образов всё ещё может быть открыт root-доступ по паролю, SSH часто принимает соединения на стандартном порту 22, а пакеты могут требовать обновления. У многих современных провайдеров вход по паролю или под root уже отключён по умолчанию, но это нельзя считать универсальным правилом. Автоматические сканеры добираются до нового сервера в течение нескольких минут после получения публичного IP.

Baseline: минимум для нового VPS

Настройка VPS начинается не с деплоя приложения. Базовый харденинг нового сервера занимает 15–30 минут и снижает риск типовых атак: брутфорса SSH, сканирования открытых портов и эксплуатации устаревших пакетов.

Создайте непривилегированного пользователя с sudo и настройте аутентификацию по SSH-ключу. Root-логин по паролю отключите в /etc/ssh/sshd_config директивой PermitRootLogin no. Смена стандартного порта SSH снижает шум от автоматических сканеров.

Firewall и fail2ban

Настройте ufw или iptables: разрешите только нужные порты, остальное заблокируйте. Утилита fail2ban автоматически банит IP после серии неудачных попыток входа и хорошо дополняет правила firewall.

Автообновления и мониторинг логов

Включите unattended-upgrades для автоматической установки обновлений безопасности. Периодический просмотр /var/log/auth.log и вывода journalctl помогает заметить подозрительную активность до того, как она перерастёт в инцидент.

Чек-лист baseline-настроек

•  Создан непривилегированный пользователь с sudo

•  Root-логин по паролю отключён

•  SSH-аутентификация переведена на ключи

•  При необходимости изменён стандартный порт SSH

•  ufw или iptables настроен, лишние порты закрыты

•  fail2ban установлен и активен

•  unattended-upgrades включен

Baseline не заменяет полноценный аудит конфигурации, но снижает риск типовых атак. Примените чек-лист сразу после получения доступа к серверу. В блоге Aeza выходят материалы по серверной безопасности, следите за новыми разборами.

Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.

Что именно гарантирует VPS-провайдер

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

Где на самом деле ломается аптайм

На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.

Ошибки на стороне команды

Релиз без стейджинга и механизма отката, отсутствие проверок состояния, ручные правки конфигурации в продакшене: всё это классические источники простоев. Мониторинг, добавленный «потом», не предупреждает о проблеме до того, как её замечают пользователи.

Как повысить реальный аптайм сервиса

Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.

Чек-лист надёжности

•  Бэкапы и снапшоты настроены и проверены

•  Мониторинг и алерты подключены до деплоя

•  Есть процедура отката для каждого релиза

•  SSL-сертификаты обновляются автоматически

•  DNS TTL снижен перед плановыми миграциями

Аптайм сервиса на VPS-сервере зависит от инфраструктуры, архитектуры и операционных процессов одновременно. Пересмотрите собственные процессы: деплой, мониторинг, бэкапы и восстановление после сбоев. Если нужен взгляд со стороны, можно начать с аудита инфраструктуры и точек отказа.

Пометка NVMe в тарифе не гарантирует предсказуемых задержек для Cloud VPS. Реальные характеристики дисковой подсистемы зависят от архитектуры хранилища, QoS-политик и уровня виртуализации I/O. NVMe важен, но не решающий фактор.

Что на самом деле определяет скорость диска в VPS

Производительность VPS под дисковой нагрузкой ограничивается несколькими факторами одновременно. QoS-политика и burst-лимиты IOPS могут влиять на результат не меньше, чем тип накопителя. Виртуализация I/O через virtio добавляет небольшой накладной расход. Конкуренция соседей по хосту даёт непредсказуемость p99-задержек.

Local NVMe vs сетевое хранилище

Local NVMe даёт наименьшую задержку: p99 в пределах 100–300 мкс. Сетевые решения (NVMe-oF, Ceph RBD, SDS) повышают p99 из-за сетевого round-trip, зато включают репликацию и снапшоты. Выбор NVMe VPS оправдан для stateful-нагрузок с жёсткими требованиями к fsync-задержкам.

IOPS, латентность и предсказуемость под нагрузкой БД

PostgreSQL и MySQL создают смешанную дисковую нагрузку: случайное чтение небольших блоков, fsync для WAL и последовательные сканирования. В продакшен-среде на Cloud VPS p99-задержка fsync напрямую влияет на задержку коммита. Burst-лимиты могут скрывать ограничение дисковой подсистемы до тех пор, пока нагрузка не превысит гарантированный уровень IOPS.

Как правильно бенчмаркать

Классическая ошибка: фиксировать средний throughput вместо p99-latency. Запускайте fio с параметрами --rw=randread --bs=4k --iodepth=32 и смотрите процентили задержки. Утилита ioping показывает задержку одиночного I/O. Для PostgreSQL используйте pgbench после нескольких прогонов на прогрев кэша.

Что узнать у провайдера до миграции

•  Гарантированные IOPS и burst-лимит вашего VPS

•  Архитектура хранилища: локальный NVMe или распределённое хранилище

•  Есть ли гарантии по p99-задержке

•  Схема репликации и RPO при сбое диска

•  Доступность снапшотов и периодичность их создания

•  Наличие оверкоммита и политика изоляции I/O

Тип диска в тарифе – это отправная точка. Перед миграцией проверьте дисковую подсистему по чек-листу и прогоните собственные тесты: реальные p99-задержки и стабильность IOPS могут отличаться от описания тарифа.

Fail2Ban запущен, jail sshd есть в списке, а попытки входа всё равно появляются в журнале. С разных адресов они могут приходить и при работающей защите, так как Fail2Ban считает ошибки для каждого адреса отдельно. Сам по себе статус службы не значит, что она блокирует подключения. Программа должна получить запись о неудачном входе, распознать её и передать адрес в сетевой экран. Проверять эту цепочку будем на VPS с Ubuntu 24.04. Установку и базовую настройку мы показывали в первой части, а здесь ищем звено, на котором защита перестала работать.

Перед проверкой оставьте открытым рабочий сеанс SSH. Если у провайдера есть консоль в панели, убедитесь, что вы можете через неё войти. Оба пути понадобятся, если правка настроек или тестовый бан закроют доступ.

Журнал SSH

Начните с самого сервера. На Ubuntu журнал службы SSH можно посмотреть так:

Ищите строки об отказах входа, например с Failed password или Invalid user, и адрес, с которого пришло подключение. Если таких строк за выбранное время нет, работу Fail2Ban по журналу пока не проверить: попыток просто не было. Можно повторить проверку после обычной неудачной попытки входа с другого устройства. Не включайте вход по паролю специально ради теста, если он уже отключён.

Запишите адрес клиента из журнала. Он понадобится позже: Fail2Ban считает ошибки и блокирует адрес, который видит SSH. Если вы подключаетесь через промежуточный сервер или общий офисный шлюз, в журнале может оказаться адрес этого узла.

Источник событий Fail2Ban

Теперь проверьте jail sshd и источник событий, который он читает:

В разделе Filter ищите список файлов или Journal matches. Первый вариант означает чтение файлов журнала, второй указывает на systemd journal. Статус без ошибок ещё не подтверждает, что выбранный источник содержит нужные SSH-события.

Что делать, если jail читает не тот журнал?

Если jail читает файлы, узнайте их имена. Для чтения journal посмотрите условие отбора записей:

Сравните результат с тем, где вы увидели отказ входа. Если SSH пишет в journal, а jail следит за отсутствующим или неиспользуемым файлом, в уже существующей секции [sshd] файла /etc/fail2ban/jail.local можно указать:

Строку backend добавляют в существующую секцию, вторую секцию [sshd] создавать не нужно. После правки проверьте конфигурацию и перезапустите службу:

Если служба сообщает, что не может использовать backend systemd, проверьте наличие пакета python3-systemd. Для чтения journal Fail2Ban нужна библиотека Python для systemd, и без неё одной правки конфигурации недостаточно.

Проверка фильтра

Даже при правильном источнике событий jail может не засчитывать конкретные строки журнала. Для штатного фильтра SSH проверьте совпадения:

Команда читает записи journal и показывает, сколько строк подошло под фильтр sshd. Для сервера, где jail читает файл /var/log/auth.log, укажите вместо systemd-journal этот путь. Проверять нужно тот источник, которым пользуется работающий jail.

Почему фильтр не находит ошибки входа?

Если совпадений нет, сначала убедитесь, что в выбранном источнике есть свежие отказы SSH. Затем сравните сами строки отказов с тем, что ожидает фильтр: после обновления OpenSSH формат записей может измениться, и тогда понадобится более свежий фильтр. Повышать maxretry здесь бессмысленно. Положительное число совпадений тоже требует внимания: команда может найти старые записи. Оно подтверждает работу фильтра на прочитанном журнале, но само по себе ничего не говорит о новых попытках и блокировке подключений.

Пороги и исключения

Когда фильтр распознаёт ошибки, проверьте пороги и исключения, которые действуют сейчас

Fail2Ban блокирует адрес, если за интервал findtime накопилось maxretry подходящих событий. Пять ошибок от пяти разных адресов не складываются в один бан. Если нужный адрес указан в ignoreip, jail его пропустит. Сверяйте исключения с адресом в журнале SSH, особенно после смены сети или провайдера.

Адрес для ignoreip смотрите в журнале SSH либо узнавайте на устройстве, с которого вы входите. Если отправить запрос к сервису определения IP с самого VPS, он покажет внешний адрес сервера. При часто меняющемся адресе постоянное исключение для администратора может оказаться бесполезным. Тогда главным запасным путём остаётся консоль провайдера.

Текущие счётчики и заблокированные адреса снова видны в статусе jail:

Currently failed показывает, сколько адресов сейчас числится с неудачными попытками: они ещё не набрали порог для бана, а их ошибки не вышли за пределы findtime. Общее число учтённых ошибок видно в строке Total failed. После бана или окончания этого интервала значение может стать нулевым. Поэтому один ноль в статусе не значит, что журнал не читается. Сопоставляйте счётчик со временем ошибок и адресами в журнале

Проверка блокировки

Бан в статусе Fail2Ban показывает только решение программы заблокировать адрес. Применил ли его сетевой экран, видно по отказу нового SSH-подключения. Сначала узнайте, какое действие назначено jail:

Действие должно соответствовать сетевому экрану, который работает на VPS. По умолчанию, как правило, указано iptables-multiport. В этом случае Fail2Ban держит свои правила в отдельной цепочке f2b-sshd:

Если в списке стоит действие для nftables, его правила можно посмотреть так:

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

Как проверить бан с другого устройства?

Для контрольной проверки нужен клиент из другой сети, например с мобильным интернетом. Второй ноутбук в том же Wi-Fi обычно выходит в интернет с того же публичного адреса, что и основной. До бана убедитесь, что тестовый клиент входит по SSH, а его IP отсутствует в ignoreip.

Оставьте основной доступ к серверу и консоль провайдера. Узнайте внешний IP на тестовом устройстве, а затем на сервере временно заблокируйте именно его. Ниже указан адрес из диапазона для примеров. Перед выполнением замените его на адрес тестового клиента.

Проверьте, что адрес появился в статусе sshd, и попробуйте открыть с тестового устройства новое SSH-соединение. Уже открытый сеанс может сохраниться. Если вы заблокировали IPv4-адрес, убедитесь, что клиент не подключается к серверу по IPv6. Сразу после этого снимите бан:

Ручной бан проверяет сетевой экран и путь к SSH, но обходит журнал, фильтр и порог. Если он сработал, а автоматических банов всё ещё нет, возвращайтесь к предыдущим шагам. Если статус показывает бан, но новое соединение с того же адреса проходит, проверьте выбранное действие, адрес клиента и порт SSH. При изменённом порте действие может блокировать только стандартный порт 22.

После проверки

Исправляйте первый сбой в цепочке: сначала запись в журнале SSH, затем источник событий и фильтр, после них пороги и действие блокировки. Так легче понять, почему защиты нет, и не менять сразу несколько параметров наугад. Вход по SSH-ключу оставьте в любом случае: Fail2Ban ограничивает повторяющиеся попытки с адреса, но не спасает от слабого пароля или украденного ключа.

Разберём, как подключиться к Windows VPS и подготовить его к работе. Порядок одинаковый, откуда бы вы ни подключались: из Windows, macOS или Linux. До установки приложений нужно проверить сертификат, заменить временный пароль и ограничить RDP. При ошибке в настройках потребуется другой способ входа: консоль в панели провайдера.

Инструкция рассчитана на Windows Server 2025 Desktop Experience вне домена и клиент Windows 11. Команды выполняются на сервере в Windows PowerShell 5.1 x64 от администратора. В домене часть настроек задаётся групповыми политиками.

Какие данные нужны для первого подключения по RDP?

Для первого подключения нужны IP-адрес или DNS-имя сервера, порт RDP, имя пользователя и пароль, а также доступ к консоли в панели провайдера. С ними можно открыть сеанс и восстановить доступ при ошибке настройки. Если подключение идёт через шлюз, потребуются и его параметры.

Что проверить в письме и панели

В панели провайдера сверьте выданный IP, регион, число vCPU, объём памяти и диска с заказом. Там же проверьте выбранный образ Windows: для этой инструкции нужна установка с графическим интерфейсом Desktop Experience. Если параметры расходятся, выясните причину до переноса данных.

В инструкции провайдера о том, как подключиться к VPS Windows, найдите имя пользователя и порт. Обычно RDP использует 3389, но образ или сетевые настройки могут предусматривать другой вариант. Временный пароль перенесите в менеджер паролей. В заметке о сервере достаточно ссылки на нужную запись.

Следующий шаг сделайте через аварийную консоль в панели: войдите в Windows и убедитесь, что можете открыть настройки системы. Если срок действия временного пароля истёк и RDP не пускает, смените пароль здесь. Консоль должна давать доступ к управлению Windows, иначе исправить ошибочное правило RDP через неё не получится.

Если в панели есть сетевой экран, ограничьте RDP своим внешним IP уже сейчас. Саму панель защитите многофакторной аутентификацией (MFA): через неё доступны консоль и управление VPS. На скриншотах скрывайте пароли, токены и личные данные. Пример IP ниже взят из диапазона для документации. При настройке правил указывайте свой адрес.

Первый сеанс и проверка сертификата

В Windows клиент RDP открывается командой mstsc через Win+R. В нём укажите адрес сервера. Для нестандартного порта используйте запись «адрес:порт». Если нужно разобраться, как подключиться к Windows VPS-серверу с macOS, подойдёт Windows App. В Linux можно использовать Remmina с поддержкой RDP.

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

Значение SSLCertificateSHA1Hash должно совпасть с полем «Отпечаток» в свойствах сертификата на клиенте, пробелы и регистр не важны. Также проверьте срок действия и имя. При необъяснимом расхождении остановитесь и выясните причину через поддержку. Для постоянного доступа по DNS-имени назначьте службе RDP сертификат, которому доверяет клиент и в котором указано это имя.

Если вход недоступен, через консоль проверьте, разрешён ли RDP в sysdm.cpl. После подключения сохраните версию ОС из winver и снимок окна сертификата без секретов, они пригодятся при проверке настроек.

Отдельные учётные записи вместо временного доступа

Теперь создайте свою запись с уникальным паролем. New-LocalUser добавит пользователя, а Add-LocalGroupMember включит его в группу администраторов. Обращение по SID находит группу при любом языке Windows:

Проверьте подключение к Windows VPS по RDP с именем ИМЯ_СЕРВЕРА\opsadmin и вход через консоль. После этого смените временный пароль. Исходную запись отключайте, если она не нужна для восстановления. Для задач без повышенных прав создайте обычного пользователя в lusrmgr.msc. Если ему нужен RDP, добавьте его в группу «Пользователи удалённого рабочего стола».

В secpol.msc откройте политику блокировки. Пример: 10 ошибок, блокировка на 15 минут, сброс счётчика через 15 минут. При низком пороге посторонний сможет постоянно блокировать ваш вход.

Как защитить RDP и не потерять удалённый доступ?

Создайте отдельного администратора, включите NLA и разрешите RDP только с доверенных адресов, сохранив открытой аварийную консоль. Затем проверьте новый сеанс: действующее подключение может продолжать работать после изменения правил и само по себе не подтверждает доступность входа. Если внешний IP меняется, правило придётся обновлять, поэтому держите под рукой доступ к панели.

NLA и правила доступа к RDP

Первичная настройка Windows VPS продолжается в sysdm.cpl: на вкладке удалённого доступа включите требование NLA. Этот механизм проверяет учётные данные до создания полного сеанса. Повторите команду проверки сертификата: у свойства UserAuthenticationRequired должно быть значение 1.

Сетевой доступ настраивается в wf.msc. Для активного профиля брандмауэр должен быть включён, а входящие подключения по умолчанию заблокированы. Создайте входящее разрешение для TCP на порт RDP, обычно 3389. В области действия укажите свой внешний IP, например 203.0.113.25. Для UDP задайте такое же ограничение либо отключите его разрешающее правило, если этот транспорт не нужен. Правила должны действовать в активном профиле сети.

Остальные правила тоже нужно просмотреть: старое разрешение «с любых адресов» оставит RDP открытым. Учитывайте IPv6 и правила с диапазоном портов. Общий запрет на порт RDP заблокирует и нужный вход, поскольку явный запрет имеет приоритет. Список действующих правил доступен в разделе «Наблюдение».

Оставив консоль открытой, проверьте новый вход с разрешённого адреса и отказ с другого. Если порт открыт всему интернету, любой может пробовать войти. Смена его номера этого риска не устраняет.

Обновления, время и региональные настройки

Когда доступ настроен, установите обновления через Windows Update. Перезагрузку удобнее выполнить сейчас, так как после установки приложений она уже может прервать рабочие задания. Перед ней сохраните файлы и убедитесь, что сможете войти через консоль, если RDP не заработает.

После перезапуска откройте новый RDP-сеанс и проверьте, сохранились ли NLA, профиль сети и ограничения доступа. Полный номер сборки из winver и номера установленных обновлений (KB) из журнала Windows Update запишите в заметку о сервере. По ним позже можно будет установить, какие исправления уже были применены и после какого обновления появилась проблема.

Безопасность RDP на VPS зависит и от обновлений самой Windows, поскольку ограничения по IP не исправляют уязвимости службы. При ошибке установки сохраните её код и выясните причину. Затем снова запустите проверку обновлений, чтобы убедиться, что система не ждёт ещё одной установки или перезагрузки.

Для проверки времени используйте w32tm /query /status и Get-TimeZone. Первая команда показывает состояние синхронизации, вторая выводит часовой пояс. Неверное системное время мешает проверке сертификатов и сопоставлению событий. Для журналов разных машин удобно выбрать UTC. Региональный формат дат и чисел настройте с учётом приложений, он может влиять на чтение дат и чисел из CSV.

Что видно в журнале входов

Первый вход в Windows Server удобен для настройки аудита. В secpol.msc откройте расширенную политику аудита: включите аудит входа в систему и управления учётными записями пользователей, выбрав «Успех» и «Отказ». Затем войдите повторно и найдите событие в журнале Security через eventvwr.msc.

Событие 4624 с типом 10 означает успешный удалённый интерактивный вход. 4625 фиксирует отказ: при NLA встречается тип 3. Он бывает и у других сетевых входов, поэтому нужны также имя пользователя, время, источник и код ошибки. 4740 сообщает о блокировке учётной записи.

Для уведомления в системе мониторинга можно взять начальный порог: 10 отказов за 5 минут для одной пары «IP и пользователь». Успешный вход после такой серии стоит проверить отдельно. Затем порог уточняют по обычной активности сервера, чтобы не получать лишние уведомления.

Брандмауэр и NLA не добавляют второй фактор. MFA можно подключить через RD Gateway, но для этого потребуется отдельно настроить шлюз и службу аутентификации. Клиенты должны входить только через шлюз. Прямое подключение к RDP обходит такую проверку.

Какие настройки Windows изменить сразу после входа?

1.  Заменить временный пароль и разделить рабочую и административную учётные записи.

2.  Включить NLA и ограничить доступ к RDP доверенными адресами.

3.  Установить обновления, проверить время и включить аудит входов.

Производительность сервера и качество сеанса

Если удалённый рабочий стол VPS реагирует с задержкой, причина может быть как в нагрузке на Windows, так и в соединении. На перерисовку окон влияют задержка сети, потери пакетов и обработка изображения на клиенте. Чтобы оценить сам сервер, нужно посмотреть, что происходит внутри системы.

В resmon видны загрузка CPU, доступная память и процессы с дисковой активностью. Для сравнения запусков в perfmon запишите показатели с шагом в секунду за 2–5 минут одной и той же нагрузки. Подойдут % Processor Time, Available MBytes и Avg. Disk sec/Read либо Avg. Disk sec/Write. Названия счётчиков зависят от языка ОС. Дисковые задержки указаны в секундах, для миллисекунд умножьте их на 1000.

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

Сеть проверяйте передачей известного объёма данных до выбранного узла, отдельно фиксируя время и ошибки. Результат зависит от всего маршрута. Если приложение работает быстро, а сеанс тормозит, уменьшите разрешение и визуальные эффекты RDP. Отключите ненужное перенаправление дисков и принтеров, а буфер обмена оставьте только там, где он нужен для работы.

Снимок, резервная копия и проверка консоли

Перед установкой приложений снова проверьте Windows Update. В английском интерфейсе нужная кнопка называется Check for updates. Когда обновления завершены, можно сохранить исходное состояние. Снапшот (снимок) VPS удобен для отката неудачной установки, но его состав и согласованность данных зависят от платформы провайдера. Не считайте любой снимок работающей машины корректной копией базы данных.

Резервная копия должна пережить потерю самого VPS и иметь историю версий. Храните её отдельно от сервера и проверьте восстановление нужных файлов. Снимок на том же хранилище не покрывает его отказ. Убедитесь, что восстановленные файлы открываются и содержат нужные данные.

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

На случай потери пароля нужен отдельный порядок действий. Запишите, где хранятся данные резервного администратора, а при его отсутствии уточните процедуру сброса у провайдера. Консоль обходит сетевые ограничения RDP, но для входа в Windows по-прежнему нужен пароль. Ответственный за сервер должен иметь доступ и к панели, и к резервным учётным данным.

Когда понятно, как подключиться к Windows VPS, остаётся проверить вход после перезагрузки и восстановление через консоль. Вы должны входить под своей учётной записью, а с постороннего адреса подключение должно отклоняться. Через консоль вы сможете исправить правило RDP, даже если оно закрыло вход по сети. Если одна из проверок не пройдена, сначала устраните причину, а затем переносите данные.

Результат подготовки сохраните вместе с датой, именем администратора, параметрами VPS и версией образа. Добавьте снимки сертификата и NLA, правила с адресами и профилями, номера обновлений, события проверочного входа и результат восстановления доступа. Если проблема появится после следующего изменения, по этим записям будет проще найти отличия и понять, какую настройку нужно вернуть.