RCON-клиенты: обзор инструментов для разных игр

MAATRIX GAMES

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

Зачем вообще выбирать между клиентами

Формально RCON — это один и тот же принцип: TCP-соединение, аутентификация паролем, отправка текстовой команды, получение ответа. Но на практике разница между клиентами ощущается уже на второй минуте использования:

• Консольные клиенты (mcrcon и подобные) — быстрые, скриптуемые, работают из cron и CI, но каждую команду печатаешь вручную или через параметры запуска.
• GUI-клиенты — удобны для живой модерации: список игроков на экране, кнопки кика/бана, история команд, но их нужно установить и настроить отдельно, и не для каждой игры такой найдётся.
• Веб-панели (встроенные в хостинг или отдельные) — ничего не ставите локально, заходите по ссылке из браузера с телефона, но зависите от того, что вам эту панель вообще предоставили.
• Библиотеки для своего кода — если вы пишете бота или дашборд, готовый клиент не нужен вообще, нужна библиотека, которая говорит на RCON-протоколе из вашего скрипта.

Дальше пройдёмся по каждой категории конкретно, с командами и именами инструментов, а не абстрактно.

Консольные клиенты: mcrcon и его альтернативы

mcrcon — самый universal вариант, если нужен один инструмент под несколько игр сразу. Это open-source консольный клиент под протокол Source RCON, который используют Rust, CS2, Garry's Mod, Minecraft (через встроенный RCON-сервер) и многие другие. Ставится через пакетный менеджер или собирается из исходников — под Windows, Linux, macOS.

Разовая команда:

mcrcon -H 203.0.113.10 -P 28016 -p "ваш_пароль" "say Рестарт через 5 минут"

Интерактивный режим (без последней команды в кавычках) открывает консоль, где можно печатать команды одну за другой, как в SSH-сессии. Для повседневной модерации живьём это удобнее, чем каждый раз вызывать бинарник заново.

Плюс mcrcon в том, что он один и тот же для всех Source-совместимых игр — не нужно учить новый инструмент под каждый сервер. Минус — никакого автодополнения команд и никакой памяти истории между запусками, если не обернуть в свой скрипт.

rcon-cli и похожие Node.js/Python-обёртки — по сути тонкая прослойка над теми же библиотеками (rcon-client для Node.js, mcrcon/rcon для Python), но с более дружелюбным CLI: подсказки, история команд через стрелки, конфиг-файлы с сохранёнными подключениями к нескольким серверам. Ставится через npm install -g rcon-cli или pip install rcon-cli в зависимости от реализации — под капотом всё тот же Source RCON протокол.

Для скриптов и автоматизации (крон-задача авто-рестарта, бот-триггер по расписанию) консольный клиент почти всегда выигрывает у GUI — его проще вызвать из другого скрипта и распарсить вывод.

GUI-клиенты: когда нужны глаза, а не только текст

Если вы модерируете сервер в реальном времени и вам важно видеть список игроков и историю событий на экране, а не в потоке текста, GUI-клиент экономит время.

RustAdmin — специализированный клиент под Rust с окном чата, списком игроков (ник, SteamID, пинг), горячими кнопками кика и бана, и логом команд. Плюс в том, что заточен именно под особенности Rust-консоли (например, парсит вывод players в таблицу автоматически). Минус — только Rust, для других игр придётся ставить что-то ещё.

Cod4x RCON GUI и подобные панели для Source-игр — похожий принцип для CS2 и других тайтлов на движке Source: окно с полем ввода команды, списком игроков и историей. Часть таких инструментов заброшена авторами (легаси со времён CS:GO), так что перед установкой стоит проверить дату последнего обновления и наличие поддержки текущей версии протокола.

Веб-RCON, встроенный в саму игру. У Rust есть параметр +rcon.web 1 — включает встроенную веб-консоль, доступную по адресу вида http://ваш.ip:28016/пароль-как-путь, прямо из браузера без установки чего-либо. Плюс — ничего ставить не надо, работает с телефона. Минус — URL с паролем в пути легко случайно засветить в истории браузера, скриншоте или логах прокси, если он стоит перед сервером.

Веб-панели хостинга: часто самый практичный вариант

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

Практический плюс такого подхода: пароль от RCON никогда не покидает панель хостинга — вы не копируете его в свой конфиг mcrcon, не храните в истории терминала. Хостинг сам держит соединение с сервером внутри своей сети.

Минус — зависимость от конкретной панели: если она подвисла или недоступна, а сервер уже упал, второго пути через RCON у вас не будет (разве что резервный консольный клиент с сохранённым паролем на такой случай). Держать хотя бы один запасной способ подключения — разумная страховка, даже если основной рабочий процесс идёт через веб-панель.

Различия протокола между играми: не всё одинаково

Формулировка "RCON — это RCON везде одинаковый" верна лишь наполовину. Протокол Source RCON (бинарный, TCP, с заголовком пакета и ID запроса) действительно стал негласным стандартом — его используют Rust, все Source-игры Valve, ARK, Squad и десятки других. Но нюансы есть:

Практический вывод: клиент, написанный под протокол Source RCON (mcrcon и большинство библиотек), в теории подключится к любой игре из таблицы. Но набор доступных команд, формат ответа и даже кодировка текста (кириллица в чате Rust против латиницы команд ARK) отличаются — так что универсальный клиент решает только транспорт, а не то, что вы в итоге можете сделать через него. Если ваша основная задача — не подключение, а сами команды по конкретной игре, там уже нужна справка по RCON: подключение и основные команды с конкретикой для Rust, CS2, Minecraft и ARK.

Отдельно стоит Minecraft: там RCON — не родной для движка Java-протокол, а обёртка, которую Mojang добавила позже, и она немного капризнее. Например, многострочный вывод команд иногда обрезается клиентом, если тот не умеет собирать пакеты правильно — mcrcon это умеет, самописные скрипты на скорую руку иногда нет.

Библиотеки для своего кода: когда готовый клиент не нужен

Если вы пишете Discord-бота, дашборд мониторинга или скрипт автоматизации, вам не нужен ни консольный клиент, ни GUI — нужна библиотека, которая говорит по RCON-протоколу напрямую из вашего кода.

Node.js — пакет rcon-client (или его форки) даёт простой Promise-based интерфейс:

const { Rcon } = require('rcon-client');

const rcon = await Rcon.connect({
  host: '203.0.113.10',
  port: 28016,
  password: process.env.RCON_PASSWORD
});

const response = await rcon.send('players');
console.log(response);
await rcon.end();

Именно на этой библиотеке чаще всего собирают Discord-ботов для интеграции с RCON — слэш-команда в Discord дергает rcon.send() и возвращает ответ прямо в канал.

Python — пакет rcon (или mcrcon как библиотека, не только CLI) даёт похожий синхронный интерфейс:

from rcon.source import Client

with Client('203.0.113.10', 28016, passwd='ваш_пароль') as client:
    response = client.run('status')
    print(response)

Для одноразовых скриптов и cron-задач (например, автоматической волны банов по списку) Python-вариант часто пишется быстрее, чем разворачивать под это отдельный Node-проект — см. подход в статье про массовый бан игроков, где RCON-скрипт как раз дёргается программно, а не руками через клиент.

Go и Rust (язык программирования, не игра) — тоже есть готовые крейты/пакеты (gorcon, rust_rcon и подобные), если основной стек проекта уже на них — смысла тащить отдельный рантайм ради одного RCON-вызова обычно нет.

Безопасное хранение RCON-пароля при работе с любым клиентом

Какой бы клиент вы ни выбрали, пароль РCON так или иначе где-то оседает — в конфиге клиента, в переменной окружения, в коде бота. Несколько правил, которые стоит соблюдать независимо от инструмента:

• Никогда не хардкодьте пароль в скрипте, который пойдёт в git. Используйте переменные окружения (process.env.RCON_PASSWORD в примере выше) и файл .env, добавленный в .gitignore — банально, но именно так утекает большинство паролей.
• Для консольных клиентов не передавайте пароль в открытом виде в истории shell. Команда вида mcrcon -p mypassword осядет в ~/.bash_history — лучше передавать через переменную окружения, если клиент это поддерживает, или через файл конфигурации с ограниченными правами доступа (chmod 600).
• Отдельный пароль на автоматизацию, отдельный на ручной доступ, если игра/панель это позволяет — так утечка одного не роняет оба канала сразу.
• Секрет-менеджеры для продакшен-ботов. Если бот крутится на отдельном сервере и дёргает RCON регулярно, пароль стоит держать не в .env, а в секрет-хранилище (Docker secrets, HashiCorp Vault, встроенные секреты вашей CI/CD-платформы) — особенно если к серверу с ботом есть доступ у нескольких человек.
• Меняйте пароль при смене состава команды. RCON-пароль обычно один на весь сервер без персональных учёток — значит, любой, кто знал пароль, сохраняет доступ, пока вы его не смените вручную.

Если у вас уже настроена двухфакторная аутентификация для панели хостинга, RCON-пароль стоит считать отдельным, не менее чувствительным секретом — двухфакторка на панели не защищает от утечки RCON-пароля из конфига или чужого скрипта, это разные уровни защиты одного и того же сервера.

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