Ограничение доступа по IP для игрового сервера

MAATRIX GAMES

Игровой порт открыт всему миру — это нормально, иначе никто не зайдёт поиграть. А вот SSH, RCON и веб-панель управления — это уже не про игроков, это ключи от всего сервера, и они не должны быть доступны кому угодно из интернета. Если хоть раз видели в логах бесконечный перебор паролей на 22 порту или странные подключения к RCON среди ночи — это не про то, что вас взломали, это боты сканируют весь диапазон адресов и стучатся во всё подряд. Разберём, как ограничить именно административные каналы конкретными IP, оставив игровой порт открытым для всех, кому он и нужен.

Почему это не то же самое, что whitelist игроков

Важно сразу развести две разные задачи, которые по названию похожи, а по смыслу нет. Whitelist игроков — это про то, кто может зайти в игру: список никнеймов или Steam ID, которым разрешён вход на игровой сервер (подробнее в статье про настройку whitelist). Это работает на уровне игрового протокола, и игровой порт при этом всё равно открыт всем — просто сервер сверяет, кто стучится, с списком разрешённых имён.

Ограничение по IP, о котором эта статья, — это другой уровень, сетевой. Речь не о том, кто может играть, а о том, кто может достучаться до административных интерфейсов сервера: SSH-консоли операционной системы, RCON-протокола управления игровым процессом и веб-панели (если она есть). Тут неважно, какой у человека ник в игре — важно, с какого IP-адреса идёт подключение. Игровой порт как был открыт всем, так и остаётся: ограничивать его по IP означает разрешить заходить только избранным игрокам, а это уже совсем другая задача, не связанная с безопасностью хоста.

Три точки входа, которые стоит защитить

На игровом сервере обычно три административных канала, каждый со своим уровнем риска:

• SSH (обычно порт 22 или перенесённый на нестандартный) — полный доступ к операционной системе. Скомпрометированный SSH — это не потеря игрового мира, это потеря всего сервера целиком, включая бэкапы, если они лежат там же.
• RCON — удалённое управление игровым процессом: кик, бан, смена карты, рассылка команд (см. статью про подключение по RCON). Скомпрометированный RCON — это захват контроля над игрой: массовый бан всех игроков, гриферские команды, иногда возможность выполнить произвольный код через уязвимости плагинов.
• Веб-панель управления — если используете панель вроде Pterodactyl, AMP или собственную панель хостера — это ещё одна точка, через которую можно перезапустить сервер, поменять конфиг или скачать бэкап с чувствительными данными.

Общий принцип для всех трёх один: разрешено только то, что явно нужно. По умолчанию — закрыто для всех, вручную открывается доступ конкретным адресам. Это логика "deny by default", которая радикально снижает шум от автоматических сканеров и целенаправленных попыток подбора паролей — подробнее про саму логику построения правил файрвола в статье про настройку портов и файрвола.

Ограничение SSH по IP через файрвол

Если у вас статический IP (домашний провайдер с фиксированным адресом, офисный канал, VPS, с которого вы всегда подключаетесь) — можно ограничить SSH конкретным адресом или небольшим списком напрямую в файрволе.

Через ufw (Ubuntu/Debian):

# сначала сбросить общее правило на SSH, если оно уже разрешено всем
sudo ufw delete allow 22/tcp

# разрешить только с конкретного IP
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

# если админов несколько — отдельное правило на каждый IP
sudo ufw allow from 198.51.100.25 to any port 22 proto tcp

Через iptables:

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Порядок правил в iptables критичен: сначала разрешающее правило для нужного IP, потом запрещающее для всех остальных — иначе DROP отработает раньше, чем дойдёт очередь до ACCEPT, и вы отрежете сами себя.

Главная граблина этого подхода — динамический IP. Если провайдер меняет вам адрес раз в несколько дней (а домашние тарифы почти всегда такие), правило файрвола устаревает без предупреждения, и в какой-то момент вы просто не сможете зайти на свой же сервер. Проверить текущий публичный IP перед подключением можно командой curl ifconfig.me с вашей машины — но если приходится делать это регулярно, это сигнал, что нужен более надёжный способ, а не список IP руками.

Когда статики нет: VPN вместо списка адресов

Если IP не статический, правильное решение — не гнаться за адресом каждый раз, а поднять VPN (WireGuard или OpenVPN) между админской машиной и сервером, и открывать SSH/RCON/панель только для IP-адреса внутри VPN-туннеля. Тогда физический адрес интернет-провайдера вообще не имеет значения — файрвол видит только внутренний адрес VPN-подсети, который у вас всегда один и тот же, независимо от того, из дома вы подключаетесь, из кафе или с телефона в роуминге.

Кратко идея на WireGuard: на сервере поднимается интерфейс wg0 с адресом вроде 10.8.0.1, у каждого админа — свой клиентский конфиг с адресом 10.8.0.2, 10.8.0.3 и так далее. Правило файрвола после этого простое:

sudo ufw allow in on wg0 to any port 22 proto tcp
sudo ufw deny 22/tcp

То есть SSH разрешён только с интерфейса VPN, а обычное внешнее правило на 22 порт — запрещающее. Тот же принцип применяется к RCON и веб-панели: они слушают либо только на внутреннем VPN-адресе, либо файрвол пропускает к их портам трафик только с адресов подсети 10.8.0.0/24.

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

Ограничение RCON по IP

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

Пример для RCON Rust (порт 28016, TCP):

sudo ufw allow from 203.0.113.10 to any port 28016 proto tcp
sudo ufw deny 28016/tcp

Для RCON на Source-играх (CS2 и другие, где RCON обычно ходит через тот же порт, что и игра, но по TCP) картина сложнее: нельзя просто закрыть порт для всех кроме своего IP, потому что тот же порт нужен для обычных игровых подключений по UDP. В этом случае единственный надёжный способ — сложный пароль RCON плюс, если сборка это поддерживает, ограничение через sv_rcon_whitelist_address (доступно начиная с определённых версий движка Source — проверьте актуальность параметра в документации вашей конкретной сборки перед тем как полагаться на него).

Если RCON нужен только вам одному и не используется ботами/дашбордами с других серверов — самый простой и надёжный вариант: вообще не открывать RCON-порт снаружи в файрволе, а подключаться только через SSH-туннель на сервер и дальше к RCON локально (127.0.0.1):

ssh -L 28016:127.0.0.1:28016 user@your.server.ip

После этого RCON-клиент на вашей машине подключается к 127.0.0.1:28016, а трафик реально идёт через зашифрованный SSH-туннель. Порт RCON при этом вообще не виден снаружи — в файрволе для него не нужно открывающих правил вовсе, кроме локального 127.0.0.1.

Ограничение доступа к веб-панели управления

Если сервер администрируется через веб-панель (Pterodactyl, AMP, панель хостера) — она обычно висит на HTTP/HTTPS порту (80/443 или нестандартный вроде 8080), и по умолчанию доступна всему интернету, если её явно не закрыть.

Тот же принцип на уровне файрвола:

sudo ufw allow from 203.0.113.10 to any port 8080 proto tcp
sudo ufw deny 8080/tcp

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

location / {
    allow 203.0.113.10;
    allow 198.51.100.25;
    deny all;
    proxy_pass http://127.0.0.1:8080;
}

Такой блок в конфиге nginx работает поверх приложения — даже если в самой панели найдётся уязвимость аутентификации, до неё просто не достучаться с постороннего адреса. Это не отменяет обычные меры вроде сложного пароля и, если панель поддерживает, двухфакторной аутентификации — IP-фильтр это дополнительный слой, а не замена базовой защиты входа.

Не забудьте про файрвол хостера (Security Groups)

Отдельная грабля, в которую регулярно упираются: правила файрвола внутри операционной системы (ufw, iptables) — это только один уровень. У многих хостеров и облачных провайдеров есть ещё сетевой файрвол на уровне инфраструктуры, часто называемый Security Groups или Cloud Firewall, который работает до того, как трафик вообще дойдёт до вашей ОС.

Если такой файрвол настроен на "разрешить всё" (частая настройка по умолчанию, чтобы не мешать первому запуску сервера), то ограничения внутри ОС всё равно работают и защищают — но если он, наоборот, ограничивает что-то на своём уровне отдельно от ваших правил в ufw, легко потратить время на отладку "почему не пускает", хотя внутри ОС всё настроено правильно. Проверьте панель управления хостингом отдельно и убедитесь, что там либо разрешено всё нужное (а работу делает файрвол ОС), либо синхронизируйте оба уровня, чтобы список разрешённых IP совпадал.

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