Что сделано

Провёл аудит Ubuntu, портов, firewall, SSH forwarding и сервисов. Настроил SSH SOCKS5: туннель инициируется из Латвии, выход к Google идёт через США. Создал отдельные учётные записи и SSH-ключ; ограничил доступ IP латвийского VPS и адресом generativelanguage.googleapis.com:443.

Запретил интерактивный вход, команды и обратный forwarding. Настроил systemd-сервис с автозапуском и восстановлением туннеля. Прокси слушает только 127.0.0.1:1080. В FreeLLMAPI направил через него только Google, остальные API оставил напрямую. Сохранил бэкапы и инструкцию отката. Маршруты проверил по логам: интерфейс показывал пример URL как заполненное поле, а исключения требовали проверки.

Результат

Подтверждены IP США, проверка ключа Google и запрос к Gemini 3.1 Flash-lite. При отключении туннеля Google выдавал ошибку SOCKS5, другой провайдер работал напрямую.

SSH, xRDP, nginx, Docker и Python REST API (HTTP 200) в США продолжили работать. Новые публичные порты не открывал, маршруты, DNS, firewall и исходники не менял. Сеанс XFCE отдельно не проверял.

Выявлен риск прямого fallback при ошибке прокси-агента FreeLLMAPI: нужна отдельная доработка, полного запрета обхода пока нет.

Стек: Ubuntu, OpenSSH, SOCKS5, systemd, FreeLLMAPI, Gemini API.

Настроены 5 отдельных пользователей с независимыми графическими сессиями, Chrome и Firefox, русским интерфейсом, раскладками RU/EN и переключением Alt+Shift. Выполнена оптимизация xRDP: динамическое разрешение, clipboard, компрессия, FastPath, TLS, Xorg-сессии и защита авторизации через Fail2Ban.

Для сотрудников подготовлено подключение через FreeRDP вместо стандартного mstsc. Написаны PowerShell/CMD-скрипты для быстрого запуска: пароль не хранится в открытом виде, а сохраняется через Windows DPAPI. Окно RDP автоматически разворачивается под рабочую область монитора, при этом панель задач Windows остаётся доступной.

Дополнительно устранён запрос GNOME Keyring в Chrome и подготовлена HTML-инструкция в формате лендинга с пошаговой установкой и решением типовых проблем.

Результат: готовое многопользовательское RDP-окружение для 3–4 одновременных сотрудников с подключением в несколько кликов.

Стек: Ubuntu 24.04, XFCE, xRDP, Xorg, FreeRDP, PowerShell, Bash, Windows DPAPI, Fail2Ban.

Сначала провел диагностику сервера и проверил состояние системы, веб-сервисов и пакетов панели. Выяснилось, что проблема была связана не только со слетевшим основным пакетом FastPanel, но и с поврежденными путями логов и ошибками в web-обвязке панели. Из-за этого сервис FastPanel не мог корректно завершить запуск.

Выполнил восстановление основного пакета FastPanel, устранил ошибки post-installation, создал недостающие системные каталоги и log-файлы, после чего поэтапно восстановил запуск web-сервиса панели. Все работы провел аккуратно, без полной миграции сервера и без разрушения существующего окружения.

Результат: FastPanel была полностью восстановлена, панель снова стала доступна в браузере, ключевые сервисы успешно запустились, а клиент получил обратно рабочий доступ к управлению сервером.

В ходе диагностики были проверены Apache, nginx, MySQL, swap, access/error-логи и пики нагрузки. Выявлено, что после перезагрузки BitrixVM откатывала настройки Apache prefork к тяжёлым стандартным значениям, из-за чего сервер снова начинал расходовать больше памяти и уходить в нагрузку. Также были обнаружены внешние сканеры и тяжёлые динамические ajax-запросы сайта.

Что было сделано

оптимизирован Apache prefork под текущий объём RAM;
исправлен шаблон BitrixVM, из-за которого настройки откатывались после перезагрузки;
добавлен guard-скрипт для автоматического контроля настроек Apache;
настроена nginx-защита от типовых сканерских запросов;
добавлен мониторинг пиков нагрузки;
проверены и проанализированы тяжёлые ajax-запросы корзины/каталога;
выполнено обновление и проверка основных сервисов сервера.

Результат: сервер стабилизировался, скачков CPU до 100% больше не наблюдается уже больше недели. Максимальный всплеск после оптимизации составил около 55%, средняя рабочая нагрузка держится в диапазоне 15-25%. Сайт работает стабильно, без регулярных зависаний и ручных перезагрузок.

В ходе работ был найден и удалён вредоносный код, восстановлен public / index.php, исправлена конфигурация Nginx, восстановлена работа сайта и внутренних Laravel-маршрутов.

Дополнительно проведён аудит доступов: заблокированы лишние пользователи, удалён root-клон, очищены SSH-ключи, ограничены SSH-входы, проверены cron/systemd, FTP и fail2ban.

Была выполнена ротация MySQL-доступов: создан новый пользователь БД для Laravel, старый засвеченный пользователь удалён, Docker-сервисы переведены на новые доступы, отключён внешний MySQL X Plugin.

Также были удалены служебные Composer-файлы из public-директории, проверена недоступность .env, .git и других чувствительных файлов извне.

На втором этапе восстановлены связанные WordPress-сайты, которые использовали старые DB-доступы, и исправлена работа раздела расписания.

Результат: сайт восстановлен, редирект устранён, Docker-сервисы работают, БД переведена на новые доступы, публичные утечки закрыты, сервер дополнительно укреплён.

Начали с полной диагностики. Проверили Docker, Remnawave Node, Xray, UFW, порты, маршрутизацию и сетевой трафик через tcpdump. В результате выяснили, что проблема находится не в настройках сервера: TCP-пакеты терялись на стороне сетевой инфраструктуры VPS-провайдера.

Чтобы не ждать решения хостинга, развернули новую ноду у другого провайдера. Установили и подключили Remnawave Node, перенесли TLS-сертификаты, восстановили конфигурацию Xray и проверили все используемые порты и протоколы.

При подключении новой ноды обнаружилась несовместимость со старой панелью Remnawave 2.7.4. Выполнили резервное копирование базы и конфигурации, после чего обновили Remnawave до ветки 3.x и устранили возникший после обновления 502 Bad Gateway.

Результат: новая нода успешно подключена, домен переведен на новый сервер, VPN-профили снова работают, база пользователей и существующая конфигурация сохранены. Инфраструктура восстановлена без необходимости создавать всё заново.