Защита Mordhau-сервера от DDoS-атак

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

Все указания относятся к официальному выделенному серверу Mordhau (Steam-App-ID 629800, Unreal Engine 4) под Debian 12, Debian 13, Ubuntu 22.04 LTS или Ubuntu 24.04 LTS. Команды написаны для root, если вы работаете под обычным пользователем, добавляйте перед каждой командой sudo. Если атака идёт прямо сейчас, ничего не меняйте в конфигурации и не перезагружайте сервер, а сначала сохраните измерения (раздел 9), потому что после атаки их уже не будет. У Mordhau к этому добавляется вторая причина, которую многие владельцы узнают на горьком опыте: при завершении работы серверный процесс записывает своё состояние из оперативной памяти обратно в Game.ini. Кто правит файл при работающем сервере, теряет изменения при следующей остановке.

Почему Mordhau-серверам нужна защита от DDoS и кто их атакует

Mordhau-серверы атакуют потому, что их адрес публичен, весь игровой трафик идёт по UDP, а любой перебой сразу видят все. Запись в браузере серверов содержит IP-адрес и игровой порт в открытом виде, иначе игроки просто не нашли бы сервер. Публичные списки серверов и трекеры снимают те же данные через порт запросов Steam и публикуют их повторно. Ваш адрес — это не секрет, а характеристика продукта.

К этому добавляется техника самой игры. Unreal Engine 4 передаёт перемещения, удары и парирования по UDP. В UDP нет установления соединения, которого можно было бы потребовать, а адрес отправителя UDP-пакета легко подделать. Значит, атакующему не нужно ни заходить на ваш сервер, ни корректно с ним общаться, чтобы создать нагрузку. У Mordhau это весит больше, чем у многих других игр: исход размена решается в пределах нескольких десятых долей секунды, и уже 200 миллисекунд дополнительной задержки делают ближний бой неиграбельным задолго до того, как сервер действительно откажет. Именно поэтому небольшой атаки достаточно, чтобы испортить раунд. Что такое DDoS-атака с технической стороны, объясняет статья Что такое DDoS-атака.

Типичные поводы выглядят буднично: конкуренция между сообществами, забаненные игроки, проигранные дуэли, ссоры в Discord. Атака не требует от заказчика ни навыков, ни заметных денег, потому что всю работу делают арендованные booter-сервисы. Владельцы регулярно сообщают, что атаки начинаются ровно тогда, когда сервер полон, и прекращаются, как только он пустеет. Это не совпадение, а признак того, что кто-то следит за вашей записью в браузере серверов и использует число игроков как условие запуска.

Порты, о которых у Mordhau на самом деле идёт речь

Выделенному Mordhau-серверу нужны наружу ровно четыре UDP-порта: 7777, 7778, 15000 и 27015. Всё остальное либо опционально, либо в открытой сети ему не место. Порты передаются параметрами при запуске:

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

Две вещи здесь регулярно понимают неправильно. Во-первых, Beacon-порт 15000 — не мелочь. Beacon резервирует слот в тот момент, когда игрок подключается, чтобы после загрузки карты его не выбросило обратно. Если 15000 заблокирован или перегружен, игроки перестают заходить, хотя порт 7777 отвечает. Во-вторых, RCON у Mordhau заранее не настроен. Он включается только тогда, когда вы задаёте RconPassword и RconPort, и работает после этого по TCP, а не по UDP.

Ключевые показатели Mordhau-сервера одним списком:

Схемы атак, которые встречаются у Mordhau

Четыре схемы покрывают практически всё, что применяют против Mordhau-сервера, и каждая бьёт по своему порту.

• UDP-флуд по игровому порту 7777. Это стандартная атака booter-сервиса: как можно больше поддельных пакетов на порт, который стоит в браузере серверов. Она метит в полосу и в интенсивность пакетов, а не в уязвимость, и проявляется сначала как лаг-спайки, задолго до того, как кто-то потеряет соединение.
• Флуд запросами по порту 27015. Запрос A2S_INFO занимает 25 байт, а ответ с именем сервера, картой, режимом и числом игроков кратно больше. Значит, атакующий вкладывает мало, а у вас вызывает и вычислительную работу, и исходящий трафик.
• Reflection через ваш собственный порт запросов. Здесь ваш сервер — не цель, а инструмент: атакующий шлёт запросы с поддельным адресом отправителя, и ваш сервер отвечает жертве. Вы замечаете это как необъяснимо высокий исходящий трафик на 27015 и как жалобу на злоупотребление от вашего провайдера.
• Исчерпание подключений и слотов через Beacon-порт 15000. Вместо того чтобы жечь полосу, автоматические подключения занимают зарезервированные слоты. Сервер продолжает работать, но он полон, и настоящие игроки больше не заходят.

К этому добавляется пятая схема, как только RCON открыт в сеть: попытки входа с частотой раз в секунду по RCON-порту. Объёмной такая атака бывает редко, но она отнимает процессорное время, и это единственный из пяти случаев, в котором удачное попадание полностью отнимает у вас сервер.

Что вы можете сделать сами, прежде чем тратить деньги

Этот раздел самый длинный, и так задумано. Аккуратно настроенный Mordhau-сервер выдерживает небольшие и средние атаки собственными силами, независимо от того, у какого провайдера он стоит.

1. Инвентаризация: что вообще слушает на сервере?

Прежде чем написать хотя бы одно правило файрвола, посмотрите, что ваш сервер предлагает наружу. Не гадайте, а смотрите:

ss -lntup

Интерес представляет колонка с локальным адресом. 0.0.0.0:7777 и [::]:7777 означают «доступен из всего интернета», 127.0.0.1:27020 означает «только локально» и правила файрвола не требует. Рядом с игрой там часто обнаруживаются веб-панель, служба базы данных и давно забытая голосовая служба. Взгляд атакующего даёт скан снаружи, для UDP с коротким списком портов, потому что полный UDP-скан очень медленный:

nmap -Pn -sU -p 7777,7778,15000,27015 ВАШ.IP.АДРЕС.СЕРВЕРА
nmap -Pn -p- --min-rate 1000 ВАШ.IP.АДРЕС.СЕРВЕРА

2. Оставьте открытыми только те четыре порта, которые Mordhau действительно нужны

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

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau игра'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau Beacon'
ufw allow 27015/udp comment 'Mordhau Query'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Замените 203.0.113.10 на свой собственный адрес. Важно то, чего здесь нет: ни разрешения для веб-панели, ни для базы данных, ни для файлового сервера. Каждый дополнительно открытый порт — это дополнительная цель, которая к игре отношения не имеет. Полная инструкция вместе с запасным путём есть в статье Настройка файрвола UFW без потери доступа.

3. Ограничьте порт запросов 27015, не вылетая из списка серверов

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

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

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

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

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

4. Уберите RCON из открытой сети

RCON у Mordhau ни при каких условиях не должен без ограничений висеть в интернете. Доступ включается в Game.ini, в разделе [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Мой Mordhau-сервер
MaxSlots=64
ServerPassword=
AdminPassword=ДлинныйСлучайныйПароль
RconPassword=ДругойДлинныйСлучайныйПароль
RconPort=27020

Mordhau говорит по протоколу Source RCON, то есть по TCP, и поэтому работает с любым распространённым RCON-инструментом. Именно этим пользуются и скрипты, перебирающие учётные данные. Три правила закрывают этот случай. Первое: RconPassword и AdminPassword — это два разных длинных случайных пароля, а не вариации имени сервера. Второе: разрешение для RCON-порта вы ограничиваете своим собственным адресом, как в блоке UFW выше. Третье, если постоянного адреса у вас нет: оставьте порт снаружи закрытым и ходите на него через проброс порта по SSH, после чего подключайтесь локально на 127.0.0.1:27020:

ssh -N -L 27020:127.0.0.1:27020 root@ВАШ.IP.АДРЕС.СЕРВЕРА

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

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. Защитите Beacon-порт 15000 от флуда подключениями

Beacon-порт — недооценённая точка атаки Mordhau-сервера. Через него игра резервирует слот подключающегося игрока, пока тот ещё загружается. Бот, который в быстром темпе инициирует подключения, занимает таким образом слоты, ни разу не добравшись до игры. Сервер остаётся онлайн и всё равно выглядит полным. Верхний предел на каждый адрес источника это перехватывает, потому что настоящий игрок обращается к beacon ровно один раз за подключение, а не двадцать раз в секунду:

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

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

Просто добавленные правила iptables после перезагрузки исчезают. В Debian и Ubuntu их сохраняют так:

apt-get install -y iptables-persistent
netfilter-persistent save

При работе с UFW такие правила помещают в /etc/ufw/before.rules, иначе они пропадут при следующем ufw reload.

6. Game.ini и Engine.ini: что действительно даёт эффект

У Mordhau два файла конфигурации, и под Linux оба лежат в Mordhau/Saved/Config/LinuxServer/, под Windows в Mordhau\Saved\Config\WindowsServer\. Game.ini отвечает за имя сервера, слоты, пароли, список администраторов, ротацию карт и идентификаторы модов из mod.io, Engine.ini — за поведение сети. Правьте оба исключительно при остановленном сервере, иначе серверный процесс при завершении перезапишет ваши изменения состоянием из оперативной памяти.

Для поверхности атаки действительно важны три настройки. Первая — ServerPassword: он держит в стороне всех, кого не приглашали, но стоит публичной находимости и против флуда по порту 7777 не помогает вообще, потому что атакующий и не собирается подключаться. Вторая — реалистичное значение MaxSlots: Mordhau рассчитан максимум на 64 игроков, и каждый дополнительный слот — это дополнительный источник пакетов, который должен обслуживать ваш процессор. Третья — тикрейт в Engine.ini:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Тикрейт Mordhau-сервера по умолчанию равен 60. Повышение до 120 удваивает и интенсивность пакетов на игрока, и нагрузку на процессор, а это ровно то, что под атакой вам не нужно. Сервер на 64 слота с тикрейтом 120 уже в обычном режиме создаёт порядка 8 000 пакетов в секунду в каждую сторону. Тот, кого обстреливают постоянно, на 60 едет заметно стабильнее, чем на 120.

7. Разгрузите отслеживание соединений и приёмные буферы

Часто упускаемое узкое место — отслеживание соединений в ядре. Оно ведёт отдельную запись для каждого UDP-потока, и флуд из десятков тысяч поддельных адресов отправителя заполняет таблицу за секунды. Когда она заполняется, сервер отбрасывает и легитимные пакеты, а в логе появляется «nf_conntrack: table full». Текущее значение и верхний предел показывает:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack | tail -20

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

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

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

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

На постоянной основе эти значения помещают в файл в каталоге /etc/sysctl.d/, например 99-gameserver.conf. Важно понимать: увеличенные буферы не повышают вашу устойчивость к крупной атаке, они лишь не дают короткому всплеску сразу стоить вам пакетов.

8. Ваш адрес стоит в списке серверов, и изменить это нельзя

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

Действенны здесь три привычки. Нигде не публикуйте сырой IP-адрес сами: ни в Discord-канале, ни на странице проекта. Подключайте игроков через имя хоста, чтобы в критической ситуации смена адреса не ломала все ссылки. И убирайте старые DNS-записи, ведь забытая A-запись на прежний адрес обесценивает любую смену. То же касается тестовых серверов: любой публично доступный второй сервер на той же машине выдаёт адрес основного.

9. Измеряйте, пока всё работает нормально

Самый важный шаг — тот, который почти никто не делает заранее: собрать базу для сравнения, пока сервер работает спокойно. Без нормального значения вы после инцидента не скажете, много ли это, 40 000 пакетов в секунду, или это просто субботний вечер. С apt-get install -y vnstat sysstat измерение идёт постоянно в фоне. Во время инцидента хватает четырёх команд:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 'udp port 7777 or udp port 15000 or udp port 27015' -c 200 -q

Для tcpdump правило одно: всегда ограничивайте объём через -c, ведь захват трафика под полной нагрузкой дополнительно нагружает и без того перегруженный сервер. Обратите особое внимание на счётчики отброшенных пакетов из ip -s link. Растущие значения dropped при спокойном процессоре — самый явный признак того, что проблема в интенсивности пакетов, а не в вычислительной мощности. Как разобрать полученные значения, описано в статье Как определить DDoS-атаку на сервере. Как аккуратно поставить сервер через SteamCMD и поддерживать его в актуальном состоянии, описывает статья Установка игрового сервера через SteamCMD.

Где эти меры заканчиваются: полоса и интенсивность пакетов

Теперь та часть, которую не решит ни один конфигурационный файл. Все описанные выше меры работают на вашем сервере, то есть в конце канала. Правило файрвола принимает решение о пакете, который уже прошёл по кабелю. Вы можете его отбросить, но не можете сделать неотправленным.

Давайте посчитаем. Типовой игровой сервер подключён на 1 Гбит/с, это 125 мегабайт в секунду, и канал заполнен, как только кто-то отправит больше. Полному Mordhau-серверу на 64 слота нужна от этого лишь малая доля: при тикрейте 60 игровой трафик лежит в районе 4 000 пакетов в секунду в каждую сторону. Арендованный booter выдаёт при этом без труда от 5 до 50 Гбит/с, то есть от пятикратного до пятидесятикратного объёма вашего канала. Насколько хорошо написано ваше правило iptables за этим каналом, роли уже не играет: пакеты ваших игроков не доходят ещё раньше.

Вторая величина — интенсивность пакетов, и упирается в неё обычно раньше, чем в полосу. При маленьких пакетах по 64 байта в канал на 1 Гбит/с помещается около 1,49 миллиона пакетов в секунду. Обычное серверное ядро в зависимости от процессора и сетевой карты обрабатывает несколько сотен тысяч из них, а дальше начинает отбрасывать. Значит, атака, которая не заполняет ваш канал даже на треть, всё равно способна положить ваш Mordhau-сервер, потому что процессорное время уходит на само отбрасывание. Владельцы серверов описывают это словами «загрузка ведь была совсем не высокой, а всё равно всё легло».

Чтобы понимать, какие порядки величин встречаются на практике: на серверах KernelHost были отфильтрованы, среди прочего, атака мощностью более 473,4 Гбит/с при более чем 41,5 миллиона пакетов в секунду на голосовой сервер и UDP-flood мощностью более 112,2 Гбит/с на игровой сервер. Локальной настройки против такого не существует. Объёмные атаки должны заканчиваться в сети перед сервером.

Что KernelHost этому противопоставляет

Постоянная защита, которая включена в каждый сервер

Защита от DDoS в KernelHost построена в два уровня и активна постоянно, вам не нужно ничего включать, заказывать или настраивать:

• Уровень 1: 17 Тбит/с ёмкости mitigation в глобальной scrubbing-сети. Объёмные атаки вычищаются близко к источнику, ещё до того как они дойдут до дата-центра.
• Уровень 2: фильтрация Arbor в реальном времени на 3,2 Тбит/с во Франкфурте-на-Майне. Непосредственно перед сервером распознаются и отбрасываются схемы, характерные для конкретных протоколов, пакет за пакетом.

Решают два свойства. Защита работает постоянно и не должна сначала отреагировать на атаку, поэтому нет тех первых минут, когда сервер недоступен. И null-routing не применяется: ваш IP-адрес остаётся в сети, отбрасываются только вредоносные пакеты. Тот, кто убирает IP-адрес из сети, добивается для вас того же результата, что и атакующий. Площадка — Франкфурт-на-Майне. Какие игры и протоколы покрыты, перечисляет статья Защита игровых серверов от DDoS в реальном времени.

Advanced DDoS Protection для Mordhau-серверов под постоянным обстрелом

Некоторые серверы атакуют не время от времени, а прицельно и неделями. Для них есть Advanced DDoS Protection от 50,00 € в месяц, по модели PrePaid, без минимального срока и без платы за подключение. Разница не в большей ёмкости, а в контроле:

• Выделенный защищённый IP-адрес из франкфуртского ядра сети, на который ваш сервер переводится внутри нашей сети. С вашей стороны ничего перестраивать не нужно.
• Самостоятельно управляемые правила защиты по портам и протоколам в личном кабинете: вы отдельно задаёте, что разрешено на 7777 UDP, что на 15000 UDP и что на 27015 UDP, и тикет для этого писать не нужно.
• Изменения вступают в силу в реальном времени, поэтому подстраивать их можно прямо во время идущей атаки, а не ждать технологического окна.
• Профиль защиты под конкретную игру. Для игровых серверов на Unreal Engine поверх UDP и для портов запросов Steam есть готовые профили, как и для модифицированных и собственных приложений на любых портах TCP или UDP.

Advanced DDoS Protection рассчитана на серверы, которые работают в KernelHost. Если ваш Mordhau-сервер сейчас стоит в другом месте и его регулярно выбивают из сети, путь к этой фильтрации — переезд.

Сравнение двух уровней

Большинству Mordhau-серверов хватает включённой постоянной защиты вместе с аккуратной настройкой. Advanced DDoS Protection — это ответ на ситуацию, когда кто-то воспринимает происходящее лично.

Частые ошибки и что с ними делать

«Я закрыл порт 27015, и теперь моего сервера нет в списке»: это ожидаемое следствие. Порт запросов Steam отдаёт браузеру серверов имя, карту и число игроков. Без него ваш сервер больше не появляется или числится недоступным. Правильный путь — ограничение интенсивности на каждый адрес источника, а не блокировка.

«Игроки не заходят, хотя сервер работает»: проверьте сначала порт 15000 UDP. Beacon резервирует слот во время загрузки. Если он заблокирован, отфильтрован слишком жёстко или перегружен, подключение зависает, хотя порт 7777 отвечает и сервер стоит в браузере.

«Мои изменения в Game.ini после перезапуска снова пропали»: вы правили файл при работающем сервере. Серверный процесс Mordhau при завершении записывает своё состояние из оперативной памяти обратно и перезаписывает при этом вашу версию. Остановить сервер, отредактировать, запустить, именно в таком порядке.

«Мои правила iptables не срабатывают»: частых причин три. Правила стоят позади цепочек UFW, и дело до них не доходит. Либо они пропали после последней перезагрузки (тогда помогут netfilter-persistent save или запись в /etc/ufw/before.rules). Либо атака объёмная, и правило работает корректно, только канал уже давно забит. Проверьте командой iptables -L INPUT -n -v, растут ли счётчики совпадений. Если они остаются на нуле, до правила дело не доходит.

«Сервер работает, но у всех лаг-спайки и удары доходят с опозданием»: посмотрите сначала, растёт ли интенсивность входящих пакетов при спокойном процессоре. Это и есть картина атаки. Если интенсивность пакетов остаётся обычной, а процессор загружен на 100 процентов, то это не DDoS-атака, а чаще всего слишком высокий тикрейт, слишком много слотов или мод.

«Мой провайдер сообщает об исходящем злоупотреблении с порта 27015»: ваш сервер использовали как усилитель для reflection. Запросы приходили с поддельным адресом отправителя, а отвечал ваш сервер чужой жертве. Ограничение интенсивности на 27015 UDP по каждому адресу источника это прекращает.

«Мой прежний провайдер заблокировал мой IP-адрес»: это и есть null-routing. Так провайдер защищает собственную сеть, а для вас результат ничем не отличается от успешной атаки, обычно ещё на несколько часов после неё. Если сомневаетесь, спросите напрямую: трафик фильтруют или адрес уводят в null-routing. Ответ определяет вашу доступность сильнее, чем любые характеристики железа.

«В tcpdump я не вижу ничего подозрительного»: если трафик отфильтрован ещё в сети перед сервером, то до самого сервера, как и ожидается, ничего не доходит. При работающей фильтрации это нормальная картина. Верно и обратное: при насыщенном канале до вас может не дойти даже та SSH-сессия, из которой вы собирались снимать измерения. Тогда используйте VNC-консоль в личном кабинете, она работает независимо от сети гостевой системы.

Коротко о главном

• Выделенному Mordhau-серверу нужны наружу ровно четыре UDP-порта: 7777 (игра), 7778 (Steam), 15000 (beacon) и 27015 (запросы Steam). Всё остальное закрывается.
• RCON у Mordhau работает по TCP по протоколу Source RCON и включается только через RconPassword и RconPort в Game.ini. Ограничьте этот порт своим собственным адресом.
• Порт 27015 UDP вам можно ограничить, но не закрыть: без него ваш сервер пропадает из браузера серверов, потому что число игроков, карта и имя запрашиваются через этот порт.
• Порт 15000 UDP — это beacon-порт, он резервирует слот на время загрузки. Если он заблокирован или перегружен, игроки не заходят, хотя сервер работает.
• Правьте Game.ini и Engine.ini только при остановленном сервере, потому что при завершении серверный процесс записывает обратно состояние из оперативной памяти.
• Местные правила файрвола заканчиваются на полосе: 1 Гбит/с — это 125 мегабайт в секунду и при пакетах по 64 байта около 1,49 миллиона пакетов в секунду. Всё, что больше, решает исключительно сеть перед сервером.
• В KernelHost двухуровневая постоянная защита входит в каждый серверный тариф без доплаты и активна с момента развёртывания, без null-routing. Кто хочет управлять фильтрацией сам, получает её с Advanced DDoS Protection от 50,00 € в месяц.

Если ваш Mordhau-сервер уже работает в KernelHost, фильтрация активна, и делать для этого ничего не нужно. Если вы всё же замечаете странности, откройте тикет в поддержку, чтобы правила фильтрации подстроили под ваш IP-адрес. Во время идущей атаки с нами дополнительно можно связаться через экстренный чат WhatsApp по номеру +43 650 8209883.