Глобальные бан-листы для игровых серверов

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

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

Две разные задачи с одним названием#

«Глобальными банами» называют две довольно разные схемы, и их полезно различать.

Первое - операционное удобство почти без минусов. Второе - решение на уровне политики, и техническая часть в нём самая простая.

Есть и третий вид, который вы вообще не контролируете: глобальные баны поставщика античита и разработчика, действующие на всех серверах игры. О них - в статье BattlEye и Easy Anti-Cheat на серверах.

Как работает общая бан-система#

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

При выборе важны три свойства:

• Что происходит, когда база данных недоступна. Хороший плагин кеширует баны локально и продолжает их применять; слабый пускает всех, пока база не вернётся.
• Проверяются ли баны только при входе или передаются на серверы сразу. Мгновенная передача означает, что игрок, забаненный на одном сервере, сразу удаляется с другого, а не при следующем входе.
• Какие идентификаторы хранятся. Как минимум ID аккаунтов; IP-адреса - для выявления альтов; история - чтобы снятые баны оставались видны.

На всю сеть или на один сервер

Не каждый бан должен следовать за игроком везде. Игрок, который постоянно нарушает правила строительства на вашем креативном сервере, может быть вполне желанным гостем на PvP-сервере, а бан за кемперство на спавне на deathmatch-сервере ничего не говорит о том, как он ведёт себя в кооперативной кампании. Некоторые из инструментов ниже умеют ограничивать бан одним сервером или группой серверов, а не всей сетью; где это невозможно, ведите отдельный локальный бан-лист для правил, которые имеют смысл только на одном сервере.

Разумное разделение для большинства сетей:

• На всю сеть: читерство, обход бана, угрозы, доксинг, язык ненависти - всё, за что человека убрали бы и из Discord вашего сообщества.
• На один сервер: правила, привязанные к режиму игры, карте или культуре конкретного сервера.

Запишите это разделение для команды. Без него по умолчанию станет «банить везде», и мелкое нарушение на одном сервере закроет постоянному игроку доступ ко всему, что у вас есть.

Игры на Source: SourceBans++#

В играх на Source с SourceMod - Team Fortress 2, Garry's Mod, Left 4 Dead 2, Counter-Strike: Source и других - стандартом является SourceBans++. Это поддерживаемое продолжение оригинального SourceBans, состоящее из трёх частей: веб-панели на PHP, базы данных и набора плагинов SourceMod. Основной плагин отвечает за баны; сопутствующие плагины - за блокировку общения (гэги и муты) и синхронизацию администраторов, а ещё есть необязательный плагин, который помечает подключающихся игроков, чей IP совпадает с забаненным аккаунтом.

Каждый игровой сервер подключается к базе данных через databases.cfg в SourceMod:

"Databases"{	"driver_default"	"mysql"	"sourcebans"	{		"driver"	"default"		"host"		"db-host-from-your-panel"		"database"	"sourcebans"		"user"		"generated-user"		"pass"		"generated-password"		"port"		"3306"	}}

Каждому серверу также нужен собственный ID сервера, который задаётся в файле конфигурации плагина в configs/sourcebans/ и должен совпадать с сервером, добавленным в веб-панели. После этого sm_ban на любом сервере пишет в общую базу данных, и бан действует на всех серверах.

SourceBans++ рассчитан на MySQL-совместимую базу данных для веб-панели и плагинов, поэтому перед началом сверьте это требование с той базой, которая у вас есть.

У SourceMod есть и собственная система администраторов на базе данных - более простой вариант, если делиться нужно администраторами, а не банами: плагин admin-sql-threaded читает администраторов и группы из базы данных, описанной как "admins" в databases.cfg, так что повышение или удаление члена команды - одно изменение для всей сети. Модель прав, которой пользуются эти администраторы, описана в статье флаги администраторов и иммунитет в SourceMod.

Minecraft: один бан-плагин, одна база данных#

У сети Minecraft обычно есть прокси (Velocity или BungeeCord) перед несколькими бэкенд-серверами. Бан-плагины решают это одним из двух способов: установка на прокси, где бан останавливает игрока раньше, чем он доберётся до любого бэкенда, или установка на каждый бэкенд с общей базой данных. Установка на прокси проще и её труднее обойти - при условии, что до бэкендов нельзя достучаться напрямую.

У каждого в документации указано, какие движки баз данных он поддерживает; прочитайте это до создания базы, потому что не каждый плагин поддерживает каждый движок. Все три дают временные баны со сроками, муты, предупреждения, причины и историю - это главная причина уйти с ванильного banned-players.json даже на одном сервере. Большинство умеет импортировать из ванильных файлов и друг из друга, так что начните с ванильного списка и мигрируйте.

Запускайте бан-плагин там, где происходит вход. В сети это прокси плюс база данных, которую могут читать и бэкенды, если бэкенд-плагину нужна информация о банах. Схема сети описана в статье сеть Minecraft на прокси Velocity, а подключение плагинов к базе данных - в статье MySQL для плагинов Minecraft.

Rust, DayZ, Arma и другие игры, управляемые через RCON#

Многие survival- и военные игры администрируются через RCON, а не через внутриигровой фреймворк плагинов, и здесь распространённый инструмент для общих банов - BattleMetrics. Его RCON-сервис подключается к вашим серверам, записывает игроков и их идентификаторы и хранит баны в бан-листах, которые вы применяете к одному или нескольким своим серверам. Организация может поделиться бан-листом с другой организацией или подписаться на чужой - именно так многие сообщества Rust и DayZ обмениваются банами. Баны из списка применяются сервисом через RCON, когда заходит подходящий игрок.

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

В Rust фреймворки плагинов также предлагают бан-плагины на базе данных, если вы предпочитаете хранить данные сами. В играх с BattlEye локальный bans.txt у каждого сервера свой, так что для обмена нужен инструмент, который пишет одни и те же баны в каждый.

В некоторых играх встроен список по URL. В настройках Palworld есть BanListURL - список, который сервер скачивает по HTTP; по умолчанию он указывает на список разработчика. Прежде чем менять его, проверьте, какое значение по умолчанию у вашей версии, и учтите, что, указав свой файл, вы заменяете всё, что давало значение по умолчанию.

Обмен банами с другими сообществами#

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

Как это ломается:

• Один плохой администратор отравляет все списки. Модератор другого сообщества банит бывшего друга за «читерство»; бан приходит на ваши серверы с тем же весом, что и настоящий.
• Разные стандарты доказательств. Ваше сообщество банит по записанным демкам, их - по жалобам в чате.
• Расползание охвата. Баны за токсичность, нарушения правил конкретного сервера или «драму» просачиваются в список, предназначенный для читеров.
• Нет пути для апелляции. Ошибочно забаненный игрок лишается доступа к десятку серверов, и ему не к кому обратиться.
• Месть. Спор между сообществами превращается в массовые баны игроков друг друга.

Правила, при которых это работает:

1. Делитесь только банами за читерство. Нарушения, зависящие от правил конкретного сервера, остаются локальными.
2. Требуйте доказательств к каждому общему бану, хранящихся там, где другие участники могут их посмотреть: демка, запись, выдержка из лога.
3. Согласуйте путь апелляции, обычно в сообщество, выдавшее бан, с обязательством снимать баны, которые нечем подтвердить.
4. Подписывайтесь в режиме только чтения, где это возможно, и проверяйте импортированные баны до их применения, если инструмент это позволяет.
5. Сохраняйте возможность переопределения. Вы должны иметь возможность разбанить игрока на своих серверах вне зависимости от общего списка.
6. Держите группу маленькой. Три сообщества, чьи владельцы знают друг друга, хорошо обмениваются банами. Тридцать незнакомцев - нет.

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

Приватность и юридическая сторона#

Бан-лист - это персональные данные: ID аккаунтов, часто IP-адреса, время и обвинение. Передача его другим людям - дополнительное использование этих данных. Для компании друзей это почти не важно; для сообщества любого размера, особенно находящегося в ЕС или обслуживающего его жителей, - важно.

Практический минимум:

• Передавайте минимум необходимого. Обычно достаточно ID аккаунта и категории («читерство, подтверждено демкой»). Логам чата, настоящим именам и IP-адресам редко нужно покидать ваши серверы.
• Укажите в правилах сервера или уведомлении о приватности, что баны за читерство могут передаваться партнёрским сообществам.
• Удаляйте то, что больше не важно. Старые временные баны и снятые баны не нужно передавать бесконечно.
• Будьте точны. Публично объявить человека читером, когда он им не был, - проблема совсем другого рода, чем ошибочный локальный бан.

Основы подробнее разобраны в статье приватность и данные игроков на игровом сервере.

Где разместить базу данных#

База данных банов должна быть доступна с каждого сервера, который её проверяет, надёжна и иметь backup. Несколько вариантов:

• Слот базы данных на игровом тарифе. Каждый игровой тариф RE:NODE включает один слот базы данных, который создаётся в панели со сгенерированными хостом, пользователем и паролем, и кнопку «Open in phpMyAdmin» для быстрого просмотра. Для маленькой сети этого часто достаточно - при условии, что плагин поддерживает этот движок.
• Выделенный сервер баз данных. Линейки баз данных RE:NODE - это PostgreSQL и MongoDB, что подходит бан-плагинам с поддержкой PostgreSQL. Подключение к такой базе с игрового сервера описано в статье удалённые подключения к PostgreSQL.
• Сторонний сервис, например BattleMetrics, который хранит данные за вас.

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

FAQ#

Нужна ли глобальная бан-система для двух серверов?

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

Можно ли подписаться на большой публичный список читеров?

На некоторых платформах - да, через сервисы вроде BattleMetrics. Сначала прочитайте правила списка: за что он банит, каких доказательств требует и как работают апелляции. За то, кого вы не пускаете на свои серверы, отвечаете вы, даже если решение принял кто-то другой.

Что будет, если база данных банов упадёт?

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

Включать ли IP-адреса в общие баны?

Обычно нет. IP-адреса меняются и бывают общими для семей и операторов, поэтому дают ложные совпадения на серверах других сообществ. Передавайте ID аккаунтов, а выявление альтов по IP держите локально.

Как быть с апелляцией на бан, выданный другим сообществом?

Направьте игрока в сообщество, которое выдало бан, и если оно не подтвердит бан доказательствами, снимите его на своих серверах. Ваше соглашение с партнёрами должно делать это нормой, а не поводом для спора.