HTTPS и SSL для веб-панели управления игровым сервером

MAATRIX GAMES

Открыл панель управления сервером по обычному http:// — браузер молчит, всё работает, логин и пароль от Pterodactyl или AMP улетают в чистом виде через wifi в кафе. Ловится это не хакерским скиллом, а обычным Wireshark на том же сегменте сети. Разберём, как за 15 минут закрыть панель нормальным сертификатом Let's Encrypt и забыть об этом на годы вперёд — с автопродлением, которое не нужно помнить руками.

Зачем HTTPS нужен даже "внутренней" панели

Аргумент "у меня панель только для своих админов, зачем ей сертификат" не выдерживает проверки практикой по трём причинам.

Первая — куки сессии. Панели вроде Pterodactyl, Pelican, AMP или самописных решений для Rust/ARK-серверов хранят сессионный токен в куке. По http:// эта кука летит открытым текстом, и любой узел на пути (публичный wifi, скомпрометированный роутер, прокси провайдера) может её перехватить и зайти в панель под вашим аккаунтом — без пароля, просто скопировав куку.

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

Третья — техническая. Веб-консоль игрового сервера (тот самый "живой" вывод логов и ввод команд в браузере) почти всегда работает через WebSocket. Современные браузеры разрешают защищённый wss:// только со страницы, загруженной по https. На обычном http часть функциональности консоли просто не заработает или браузер покажет предупреждение "небезопасное соединение" при каждом входе — это раздражает, но также приучает админов кликать "всё равно продолжить", что рано или поздно выстрелит на действительно опасной странице.

Если панель торчит только во внутреннюю сеть VPN — риски ниже, но описанные ниже шаги всё равно бесплатны и занимают минуты, так что смысла экономить на них нет.

Что нужно подготовить перед стартом

Let's Encrypt выдаёт сертификаты бесплатно, но для этого нужно подтвердить владение доменом. Стандартный вариант — HTTP-01 challenge, для него нужны:

• Домен или поддомен, A-запись которого указывает на IP хоста с панелью (например panel.mojdomen.ru). Про настройку своего домена под игровой сервер есть отдельный разбор — кастомный домен и SRV-запись для игрового сервера, там же логика применима и к панели.
• Открытые порты 80 и 443 на файрволе хоста — без 80-го HTTP-01 challenge не пройдёт, даже если панель работает только на 443. Если не уверены, что порты открыты, сверьтесь с материалом про настройку портов и файрвола для игрового сервера.
• SSH-доступ к хосту с правами sudo/root.
• nginx (или Apache) как reverse-proxy перед панелью. Большинство панелей (Pterodactyl, Pelican, Wisp, AMP на Linux) по умолчанию слушают на localhost или на нестандартном порту (8080, 25565+n, 8443) и рассчитаны на то, что перед ними стоит прокси-сервер, а не на прямую отдачу HTTPS самой панелью.

Если у вас Cloudflare как DNS и проксирование (оранжевое облако) — на время получения сертификата временно переключите запись в режим "только DNS" (серое облако), иначе Let's Encrypt увидит IP Cloudflare, а не ваш сервер, и challenge не пройдёт. После выпуска сертификата облако можно включить обратно.

Установка certbot и получение сертификата

На Ubuntu/Debian certbot ставится из репозитория (snap-версия сейчас предпочтительнее apt-версии — она обновляется чаще):

sudo apt update
sudo apt install snapd
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Если перед панелью уже стоит nginx, самый простой путь — плагин certbot для nginx, который сам пропишет сертификат в конфиг:

sudo apt install python3-certbot-nginx
sudo certbot --nginx -d panel.mojdomen.ru

Certbot задаст пару вопросов (email для уведомлений об истечении, согласие с условиями) и сам добавит блок listen 443 ssl в конфиг сайта, а заодно предложит настроить редирект с http на https — соглашайтесь, это стандартная практика.

Если nginx ещё не настроен как reverse-proxy для панели, ставьте сертификат в standalone-режиме (certbot временно поднимет свой веб-сервер на 80 порту, поэтому nginx на это время нужно остановить):

sudo systemctl stop nginx
sudo certbot certonly --standalone -d panel.mojdomen.ru
sudo systemctl start nginx

Сертификат и ключ окажутся в /etc/letsencrypt/live/panel.mojdomen.ru/fullchain.pem и privkey.pem — эти пути дальше пойдут в конфиг nginx.

Настройка nginx как reverse-proxy для панели

Типовой конфиг для Pterodactyl (панель слушает на 127.0.0.1:80 или 8080 в зависимости от установки) выглядит так — сохраните как /etc/nginx/sites-available/panel.conf:

server {
    listen 80;
    server_name panel.mojdomen.ru;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name panel.mojdomen.ru;

    ssl_certificate /etc/letsencrypt/live/panel.mojdomen.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/panel.mojdomen.ru/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # обязательно для WebSocket-консоли (live-логи, RCON-консоль в браузере)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Активируйте и проверьте синтаксис:

sudo ln -s /etc/nginx/sites-available/panel.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Строки proxy_set_header Upgrade и Connection "upgrade" — не опциональная деталь. Без них веб-консоль панели (та, где видны логи сервера в реальном времени и можно вводить команды) просто не подключится, хотя сама панель откроется и будет выглядеть рабочей. Это одна из самых частых причин жалоб "поставил SSL, а консоль сервера перестала обновляться".

Для панелей вроде AMP, где встроенный веб-сервер сам умеет слушать HTTPS, вариант проще — указать пути к сертификату прямо в настройках панели вместо связки nginx+прокси. Но даже тогда автопродление certbot остаётся нужным — просто deploy-hook должен не перезагружать nginx, а перезапускать сервис самой панели (см. следующий раздел).

Автопродление сертификата

Сертификаты Let's Encrypt живут 90 дней — это осознанное ограничение проекта, оно вынуждает автоматизировать продление, а не полагаться на память админа. Snap-версия certbot ставит systemd-таймер автоматически, проверить его можно так:

sudo systemctl list-timers | grep certbot

Если таймера нет (например, при установке через apt на старых системах), добавьте его вручную через cron — продление дважды в сутки с рандомной задержкой, как рекомендует сама Let's Encrypt:

sudo crontab -e

0 */12 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Флаг --deploy-hook выполнится только если сертификат реально был продлён (обычно это происходит за 30 дней до истечения), и как раз он перечитает конфиг nginx с новым сертификатом. Для панели типа AMP, где сертификат подключается не через nginx, а напрямую в настройках приложения, deploy-hook нужно заменить на перезапуск соответствующего сервиса:

--deploy-hook "systemctl restart ampinstmgr"

Проверить, что продление в принципе сработает, можно без ожидания 90 дней — сухим прогоном:

sudo certbot renew --dry-run

Если команда отработала без ошибок — автопродление настроено правильно и можно забыть про эту тему до следующей смены сервера.

Частые проблемы и грабли

Несколько ситуаций, которые встречаются чаще всего при первой настройке:

• "Timeout during connect" при certbot certonly. Порт 80 закрыт файрволом или занят другим процессом. Проверьте sudo ss -tlnp | grep :80 и правила firewall (ufw/iptables/security group у хостера).
• DNS не успел распространиться. После создания A-записи подождите 5-30 минут и проверьте dig +short panel.mojdomen.ru — если возвращается не ваш IP, рано выпускать сертификат.
• Cloudflare с включённым проксированием ломает challenge. См. раздел про подготовку — временно отключайте оранжевое облако для HTTP-01.
• Несколько поддоменов (панель + отдельный домен нод/wings). Для этого удобнее DNS-01 challenge через certbot-плагин вашего DNS-провайдера — он выпускает wildcard-сертификат *.mojdomen.ru без необходимости открывать 80 порт вообще:

  sudo certbot certonly --manual --preferred-challenges dns -d "*.mojdomen.ru"

(для автоматизации есть плагины под конкретных провайдеров DNS — cloudflare, route53 и т.д., ручной режим годится для разового выпуска).

• Сертификат для демона нод (Pterodactyl Wings, аналоги). Помимо самой панели, отдельного сертификата иногда требует и daemon на нодах — если ноды физически на разных серверах, каждой нужен свой сертификат (или используйте wildcard).
• Панель после установки сертификата открывается, но выдаёт mixed content warning. Обычно значит, что панель в своих настройках (APP_URL, base_url и т.п.) прописана с http:// — нужно поменять на https:// в конфиге самой панели, не только в nginx.

Если через reverse-proxy при этом закрываете панель по IP-whitelist или через VPN — это дополняющая, а не альтернативная мера: подробнее в материале про VPN для администраторов игрового сервера. А если ещё не настроена двухфакторная аутентификация в самой панели — это второй базовый слой защиты, который стоит включить сразу после SSL, разобрано в двухфакторной аутентификации для панели управления сервером.

Частые вопросы