Test stand: game server + sqproxy with proof of traffic path

[spumer]

Тестовый стенд sqproxy

Какую проблему решаем

sqproxy — это прокси, который стоит перед игровым сервером и должен защищать его от атак. Сейчас негде вживую проверить, что связка «игровой сервер + sqproxy» вообще работает — такого стенда просто не существует. Из-за этого ни одну будущую доработку sqproxy нельзя проверить живым запуском, только на словах. Эта задача создаёт постоянную проверочную площадку (стенд), на которой можно будет запускать и проверять sqproxy — и сейчас, и после любых будущих изменений.

Связь с другими задачами

Эта задача ни от чего не зависит — стенд поднимается локально на машине разработчика; общая виртуалка появится позже, когда будет нужна (создаём по запросу).

Эту задачу ждут две другие — им нужен уже работающий стенд:

• Стенд с ядром — добавляет к этому стенду защитный слой eBPF-фильтрации (sqredirect).
• Разбор и прогон движка — проверяется на этом же стенде.

Параллельно и без зависимости от стенда идут две задачи: хелсчек и метрики ошибок и видимость потока запросов.

Что уже есть

• Репозиторий sqproxy с кодом прокси доступен.
• Тестового стенда пока не существует — негде проверить связку «игровой сервер + sqproxy».
• Стенд делается локально у разработчика; когда понадобится общая площадка — создадим виртуалку.

Ветку для этой задачи в репозитории создаёт разработчик, который её берёт.

Основные понятия

• sqproxy — прокси в пользовательском слое, через который проходит трафик A2S (запрос-опрос игрового сервера: имя, карта, число игроков).
• Игровой сервер — отвечает на A2S-запросы (настоящий движок игры или собственный ответчик).
• Скрипт развёртывания — воспроизводимо поднимает стенд, без ручных шагов по памяти.
• Подтверждение прохода — лог или счётчик, который показывает, что запрос действительно прошёл через sqproxy, а не мимо него.
• eBPF — механизм ядра Linux, позволяющий выполнять в самом ядре небольшие проверенные программы: они видят пакеты раньше обычных приложений и могут пропустить, перенаправить или отбросить их.
• sqredirect — как раз такая программа для ядра, отдельная от sqproxy: заворачивает трафик в sqproxy и отсеивает лишнее ещё до того, как оно дойдёт до прокси. В этой задаче не участвует.

Сценарии проверки

1. Связка работает через sqproxy (обязательно)

Без этого сценария невозможна ни одна живая проверка ни для одной будущей задачи — это первый шаг, открывающий стенд.

Проверяет: другой человек (не автор) разворачивает стенд по инструкции с нуля.

• Если стенд развёрнут по скрипту локально, то связка «игровой сервер + sqproxy» поднята и работает.
• Если стенд поднят и на sqproxy отправлен A2S-запрос, то запрос доходит до игрового сервера и возвращается ответом клиенту.

2. Проход через sqproxy виден, не на слово (обязательно)

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

Проверяет: тот же человек видит подтверждение прохода через sqproxy, не проверяя на слово автора.

• Если стенд работает и отправлен A2S-запрос, то виден лог или счётчик, показывающий, что запрос прошёл через sqproxy.
• Если запрос отправлен напрямую к игровому серверу в обход sqproxy, то подтверждение не показывает проход через sqproxy.

3. Развёртывание воспроизводимо (желательно)

Стенд становится постоянной площадкой проверки; без воспроизводимости каждый подъём стенда будет держаться на памяти одного человека.

• Если стенд снят и другой человек запускает скрипт развёртывания, то стенд поднимается без действий, не описанных в инструкции.

Особые случаи

• Развёртывание или проверка не удались — скрипт падает с понятным сообщением, а не продолжает молча.
• Запрос проходит напрямую мимо sqproxy — это видно (подтверждение не показывает проход через прокси).
• Стенд по ошибке открыт наружу — конфигурация не публикует стенд в интернет ни на каком порту.

Требования

1. Локально у разработчика поднята связка: игровой сервер, отвечающий на A2S-запросы, и sqproxy перед ним. Скрипт развёртывания воспроизводим — тот же скрипт потом поднимет стенд и на виртуалке, когда она появится.
2. A2S-запрос, отправленный на sqproxy, доходит до игрового сервера и возвращается ответом клиенту.
3. Видно (лог или счётчик), что запрос прошёл именно через sqproxy, а не напрямую — иначе нельзя убедиться, что проверяется именно слой прокси.
4. Развёртывание воспроизводимо скриптом, а не «руками по памяти».
5. При сбое развёртывания или проверки скрипт падает с понятным сообщением. Если сбой замаскирован, сломанный стенд останется незамеченным.
6. Если для игрового сервера пишется свой A2S-ответчик, его формат сверяется с первоисточником (Valve Wiki, python-a2s, python-valve) — ИИ уверенно выдумывает детали бинарных протоколов, доверять ему на слово нельзя.
7. Стенд живёт в отдельном каталоге репозитория (например, deploy/test-stand/). Основной код sqproxy и всё, что связано с eBPF, в этой задаче не трогается. Исключение одно: в sqproxy можно добавить логирование, нужное для подтверждения прохода трафика. Сколько именно его добавить, решает разработчик — но эти правки выносятся в запросе на слияние отдельно от остальных, чтобы принимающий видел, что тронуто вне стенда.
8. Стенд не публикуется в интернет ни на каком порту — это только тестовое окружение, без реальных клиентов и трафика.
9. eBPF-редирект (sqredirect) в эту задачу не входит — стенд проверяет слой прокси, а не ядро.
10. Любые реквизиты доступа, если они появятся (например, к будущей виртуалке), не попадают в код, коммиты и запросы к ИИ.

Ограничения из конституции разработки

Полный список из 13 запретов — в CONSTITUTION.md. Здесь перечислены те, что прямо касаются этой задачи.

№	Запрет	Почему касается этой задачи
2	Никогда не проглатывай ошибку	Скрипт развёртывания и проверки обязан падать с понятным сообщением при сбое, а не «попробовали и тихо пошли дальше».
8	Никогда не выпускай код, написанный с ИИ, без проверки живым прогоном	Проверка здесь — сами сценарии выше плюс подтверждение человеком в запросе на слияние.
9	Никогда не принимай факт о протоколе от ИИ без сверки с первоисточником	Если для игрового сервера пишется свой A2S-ответчик, формат сверяется с Valve Wiki, python-a2s или python-valve, а не берётся из уверенного ответа ИИ.
10	Никогда не добавляй незаявленные зависимости и не переписывай код вне задачи	Задача не трогает код ядра sqproxy и eBPF за пределами границ, названных выше.
12	Никогда не помещай секреты в логи, переписку с ИИ, git и вывод программы	Любые реквизиты доступа, если они появятся (например, к будущей виртуалке), не попадают в файлы репозитория, коммиты и запросы к ИИ.

Критерии готовности

• Другой человек разворачивает стенд с нуля по инструкции, без помощи автора и без действий вне инструкции.
• Он же отправляет A2S-запрос через sqproxy и получает ответ.
• Он же видит независимое подтверждение, что запрос прошёл через sqproxy.
• Разработчик сам пишет проверку по этим пунктам — автоматическую или записанный ручной прогон.

Допущения

• Реализация игрового сервера в стенде (настоящий движок или свой A2S-ответчик) — решает разработчик.
• Порядок этой задачи относительно задачи про проверку работоспособности определяется при планировании работ.
• Объём работ — гипотеза при неизвестном текущем устройстве запуска sqproxy; подтверждается или пересматривается по факту первых часов работы.