Настройка прав и групп в TeamSpeak

MAATRIX GAMES

Сервер TeamSpeak поднят, привилегированный ключ активирован — и тут встаёт следующий вопрос: как раздать права так, чтобы модераторы могли банить нарушителей, но не могли разжаловать друг друга, VIP получали закрытые каналы, а обычные гости видели ровно то, что нужно, и не лезли туда, куда не просят. Права в TeamSpeak устроены не так, как роли в Discord — тут два независимых слоя прав, система приоритетов на основе «силы» (power) и никакой привычной регистрации по логину-паролю. Разберём, как это всё работает и где обычно ломаются новички.

Два уровня прав: серверные и канальные

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

Серверные права (server permissions) действуют на весь виртуальный сервер целиком, независимо от того, в каком канале находится клиент: кто может кикнуть с сервера (b_client_kick_from_server), забанить (b_client_ban_client), создавать серверные группы (b_virtualserver_servergroup_create), видеть админ-панель, менять настройки виртуального сервера. Эти права назначаются через Server Groups — серверные группы, которые клиент носит с собой по всему серверу.

Канальные права (channel permissions) локальны для конкретного канала: кто может писать в текстовый чат канала, кто может говорить голосом без очереди, кто видит скрытые подканалы, кто может создавать дочерние каналы. Они назначаются через Channel Groups — но, в отличие от серверных групп, канальная группа привязана не к клиенту глобально, а к паре «клиент + конкретный канал». Один и тот же человек может быть Channel Admin в своём VIP-канале и рядовым Guest в общем лобби — и это нормальная, штатная схема.

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

Server Groups: из коробки и свои

На свежем сервере уже есть набор шаблонных серверных групп — обычно что-то вроде Guest (для незарегистрированных подключений), Normal, Voice, Channel Admin, Server Admin — точный набор и названия зависят от версии сервера и стоит свериться со своим списком через Permissions → Server Groups в клиенте. Их можно редактировать, но для рабочего сервера почти всегда удобнее не трогать стандартные группы, а завести свои — так проще не запутаться при обновлении сервера и откатить изменения при ошибке.

Типовой набор кастомных групп для игрового комьюнити:

• Модератор — кик/бан с сервера, перемещение клиентов между каналами, доступ к логам жалоб.
• VIP — приоритетный слот при заполненном сервере, доступ к закрытым каналам, возможность менять свой значок (talk power выше базового).
• Гость — минимальный набор: подключение, голос в открытых каналах, без прав на создание каналов и без доступа к приватным веткам.

Группа создаётся через клиент правым кликом по списку Server Groups → Add, либо через ServerQuery — об этом ниже. У новой группы сразу стоит тип Regular (обычная, назначаемая вручную) — есть ещё тип Template (шаблон для наследования при создании новых групп) и Query (для ServerQuery-аккаунтов), их трогать без явной необходимости не стоит.

Важный нюанс, который ловит почти всех новичков: в TeamSpeak нет традиционной регистрации по логину и паролю. Идентификация клиента строится на криптографическом идентификаторе (identity), который генерируется клиентом локально и хранится в его профиле. Если игрок переустановил TeamSpeak-клиент без экспорта своей identity (Tools → Identities → Export), сервер увидит его как нового, незнакомого клиента — и все ранее выданные группы и права слетят, потому что привязка идёт не к нику, а к этому идентификатору.

Как разруливаются права: система power и приоритетов

Самая частая причина «модератор не может забанить другого модератора» или «выдал права, а они не работают» — это система приоритетов TeamSpeak, построенная на числовых значениях «силы» (power), а не на простом порядке групп в списке.

У ряда управляющих прав есть парная логика: право действия и право, требуемое для того, чтобы это действие применить к конкретной цели. Например, у серверной группы в её настройках можно выставить значение вроде i_group_needed_modify_power — минимальную «силу», которая нужна администратору, чтобы редактировать состав именно этой группы. Если у вашего модератора значение силы ниже, чем это требование у группы «Server Admin», он физически не сможет добавить или убрать из неё участника, даже если формально у него есть право b_virtualserver_servergroup_client_add. Похожая логика действует для кика, бана и перемещения — держатель более высокой «силы» может воздействовать на держателя более низкой, но не наоборот.

Практический вывод: при создании иерархии групп задавайте значения силы сверху вниз с явным запасом — Server Admin выше Модератора, Модератор выше VIP и Гостя — и после создания новой группы сразу проверяйте её реальными действиями второй тестовой учёткой, а не полагайтесь на то, что «право стоит галочкой — значит работает». Отдельная грабля: если выдать модератору право менять права других групп без ограничения по силе, он технически сможет повысить самого себя — это стоит проверить отдельно, особенно если модераторов несколько и доверие между ними неполное.

Настройка через клиент: ServerAdmin

Самый наглядный способ — через сам TeamSpeak-клиент, подключённый с правами ServerAdmin (полученными по privilege key при первом запуске сервера, см. инструкцию по установке TeamSpeak).

1. Permissions → Server Groups — список всех серверных групп. Правый клик → Add создаёт новую, двойной клик открывает редактор прав конкретной группы.
2. В редакторе группы — длинный список прав с чекбоксами и числовыми значениями (для прав с параметром, вроде максимального времени бана). Включённое право без выставленной силы обычно наследует значение по умолчанию — для управляющих прав его стоит проверить явно.
3. Чтобы добавить клиента в группу — правый клик по клиенту в дереве сервера (или в списке Client Database, если человек офлайн) → Set Server Group → отмечаете нужные группы галочками. Клиент может состоять сразу в нескольких серверных группах одновременно — итоговые права складываются.
4. Права конкретного человека, минуя группы, можно выставить отдельно через Client Info → Permissions — полезно для разовых исключений, но для постоянной структуры лучше работать через группы, иначе через месяц никто не вспомнит, кому что назначено вручную.

Через ServerQuery и WebQuery: автоматизация без клиента

Если нужно управлять правами скриптом (например, автоматически выдавать группу «Донатер» после оплаты) или настраивать сервер массово, используется ServerQuery — административный протокол на порту 10011 (raw, текстовый, telnet-подобный) или 10022 (тот же протокол поверх SSH, безопаснее для интернета).

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

servergrouplist
servergroupadd name=Moderator type=1
servergroupaddperm sgid=12 permsid=b_client_kick_from_server permvalue=1 permnegated=0 permskip=0
servergroupaddclient sgid=12 cldbid=34
servergroupclientlist sgid=12

Здесь sgid — ID серверной группы (смотрится через servergrouplist), cldbid — ID клиента в базе сервера (через clientdblist или clientdbfind pattern=Nick), permsid — текстовый идентификатор права (числовой permid тоже поддерживается, но текстовый читаемее и переживает обновления сервера).

С относительно недавних версий сервера есть более удобная альтернатива raw-протоколу — WebQuery, HTTP-интерфейс с JSON-ответами вместо телнет-подобного текста. Включается через query_protocols=raw,http в ts3server.ini, слушает по умолчанию порт 10080 (HTTP) или 10443 (HTTPS). Доступ идёт по API-ключу, который создаётся из обычного ServerQuery-сеанса:

apikeyadd scope=write lifetime=90

Дальше запросы отправляются как обычные HTTP-вызовы с ключом в заголовке x-api-key — это удобнее встраивать в веб-панель или Discord-бота, чем разбирать текстовый протокол построчно. Если управляете сервером не напрямую, а через панель хостинга (в том числе через личный кабинет MAATRIX GAMES) — панель, как правило, сама дёргает ServerQuery или WebQuery под капотом, и вам достаточно формы с чекбоксами прав, без ручного набора команд.

Channel Groups и точечные права на канал

Канальные права работают отдельным механизмом поверх серверных групп. У сервера тоже есть свой набор шаблонных Channel Groups — как правило, что-то вроде Guest, Talker, Channel Admin — и логика та же: можно оставить дефолтные или создать свои под структуру каналов.

Назначение канальной группы клиенту — всегда привязка к конкретному каналу:

channelgrouplist
channelgroupadd name="VIP Channel Admin" type=1
channelgroupaddperm cgid=8 permsid=i_channel_needed_modify_power permvalue=40
setclientchannelgroup cgid=8 cid=15 cldbid=34

Это даёт клиенту cldbid=34 группу cgid=8 именно в канале cid=15 — в остальных каналах сервера у него останутся права по умолчанию (обычно Guest или Talker).

Кроме групп есть ещё channel-specific permissions — точечные права конкретного клиента в конкретном канале, минуя группу вообще. Настраиваются через правый клик по клиенту внутри канала → Permissions, полезны для разовых исключений («этому одному человеку разрешить говорить в read-only канале объявлений»), но, как и с серверными правами, злоупотреблять точечными исключениями не стоит — растащенные по десяткам каналов ручные правки почти невозможно потом аудитить. Если структура каналов заведена под конкретный игровой проект — например, отдельная ветка под ваш Minecraft-сервер — обычно достаточно одной канальной группы «Донатер» с расширенным доступом, без плетения ручных исключений на каждого игрока.

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