حماية خادم Hytale من هجمات DDoS

خادم Hytale الذي يفقد مساءً في وسط اللعب جميع اتصالاته في وقت واحد، ويبقى غير قابل للوصول لبضع دقائق، ثم يعمل من جديد من تلقاء نفسه، نادراً ما تكون مشكلته في العتاد. ففي الغالب يجري هجوم. ويعرض هذا المقال كيف تحمون خادم Hytale من هجمات DDoS: أولاً ما تستطيعون إعداده بأنفسكم دون تكاليف إضافية، ثم الموضع الذي تنتهي فيه هذه الإجراءات تقنياً، وفي الختام ما يجب أن يحدث في الشبكة الواقعة قبل الخادم لكي يبقى الخادم قابلاً للوصول.

جميع المعطيات تتعلق بالخادم المخصص الرسمي من Hypixel Studios، أي بـ HytaleServer.jar مع Assets.zip تحت ⁦Java 25⁩، مُشغَّلاً على ⁦Debian 12⁩ أو ⁦Debian 13⁩ أو ⁦Ubuntu 22.04 LTS⁩ أو ⁦Ubuntu 24.04 LTS⁩. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها. وHytale في Early Access ويتحرك بسرعة: ولهذا يحمل كل قول عن اللعبة في هذا المقال تاريخاً، وكل ما ليس موثّقاً رسمياً مُعلَّم صراحةً على أنه توقّع أو على أنه مصدر من المجتمع. وإذا كان الهجوم جارياً الآن، فهناك ترتيب إضافي: القياس أولاً، ثم التغيير. فإعادة تشغيل قاسية تحت الحِمل تُهدر كل ما حدث في العالم منذ نقطة الحفظ الأخيرة، وقياسات الحادثة تختفي بعدها كذلك.

لماذا تُعطَّل خوادم Hytale بشكل مقصود بهجمات DDoS

خادم Hytale هو جمهور على عنوان ثابت، وهذا الجمهور قابل للاستبدال. فمن لا يستطيع الدخول ثلاث مرات متتالية مساءً إلى خادمه المعتاد، يبحث عن خادم آخر. وهذا بالضبط هو نموذج العمل خلف الهجمات على خوادم المجتمعات: فالأمر لا يتعلق بالبيانات ولا بالتهديد بالفدية، بل بلاعبين يرحلون. وخدمة booter تقصف عنواناً ببضعة يوروات في الشهر لا تطلب من طالب الهجوم مهارةً ولا جهداً، والضرر ينشأ من جديد مع كل انقطاع.

ويُضاف في Hytale أمر خاص: كود الخادم علني. فقد أعلنت Hypixel Studios في يونيو 2026 برنامج Hytale Shared Source وتوفّر عبره كود الخادم الكامل وبروتوكول الشبكة والأصول عبر GitHub، ومتاحة لكل من يملك ترخيص لعبة صالحاً. ولمشغّلي الخوادم هذا مكسب، لأن الإضافات تُبنى في مقابل واجهات حقيقية. أما لجهة الهجوم فهو يعني أن أحداً لم يعد مضطراً إلى تخمين البروتوكول. فمن يريد معرفة الموضع الذي يستهلك فيه إنشاء الاتصال وقت معالجة، يستطيع قراءته. وما يحدث تقنياً في هجوم كهذا يشرحه المقال ما هو هجوم DDoS؟.

حال Hytale في 27 سبتمبر 2026

Hytale في Early Access منذ 13 يناير 2026، ومتاح لأنظمة Windows وmacOS وLinux، وبلغ في الأيام التي تلت الانطلاق أكثر من مليون لاعب. والطريق إلى ذلك كان غير معتاد، وهو يشرح لماذا لم تبق المقالات الأقدم عن Hytale صحيحة في الغالب.

والنتيجة العملية لهذا التسلسل: خادم Hytale اليوم ليس خادم يناير. فمع ⁦Update 6⁩ تغيّر بروتوكول الشبكة من hytale/2 إلى hytale/3، ووفق ملاحظات التحديث الرسمية بتاريخ 27 أغسطس 2026 يجب إعادة بناء الخوادم والإضافات قبل أن تتصل. فمن يخطط لتوافره، لا يخطط ضد الهجمات وحدها، بل ضد تغييرات البروتوكول أيضاً.

لماذا يكون 12 أكتوبر 2026 الموعد الحرج

تحديثات المحتوى الكبيرة تعمل كانطلاق بيع ثانٍ. فهي تُعيد اللاعبين القدامى، وتجذب لاعبين جدداً، ولبضعة أيام تحدد القابلية للوصول أي خادم مجتمع ينمو من هذه الموجة وأيها يفوّتها. وهذا النمط موثّق في ألعاب أخرى: فقد بلغ Palworld في يناير 2024 ملايين اللاعبين في أيام قليلة، وكانت خوادم المجتمعات في مرحلة الانطلاق تلك أكثر ما تعرضت للهجوم في اللحظة التي كان لديها فيها أكثر ما تخسره. والميكانيكا خلف ذلك موصوفة بالتفصيل في حماية خوادم Palworld من هجمات DDoS وتنتقل إلى Hytale واحداً بواحد.

وتنتج عن ذلك حقيقة غير مريحة عن الجدول الزمني: الحماية التي تُطلَب في 12 أكتوبر متأخرة. فالوصلة وعنوان الحماية ومجموعة القواعد لكل منفذ وقيمة قياس للتشغيل الطبيعي تحتاج إلى وقت سابق، لأنها لا تُضبَط بشكل معقول دون بيانات مقارنة. ومن يبدأ أسبوعين قبل تحديث كبير يملك وقتاً كافياً. ومن يبدأ في يوم التحديث يضبط في طيران أعمى.

المنافذ التي يتعلق بها الأمر فعلاً في خادم Hytale

يحتاج خادم Hytale إلى منفذ مفتوح واحد بالضبط: ⁦5520 UDP⁩. فحركة اللعب تسير عبر QUIC، أي عبر UDP، ولا يُحتاج إلى TCP لحركة اللعب. ومن يصرّح لـ TCP وحده يرى الصورة ذاتها التي يراها عند جدار حماية مغلق: اللاعبون يسقطون في مهلة انتهاء. والربط الافتراضي هو 0.0.0.0:5520، ويُضبَط منفذ مختلف عند الإقلاع بالمعامل --bind.

هذا الجدول أقصر منه في معظم الألعاب الأخرى، وهذا هو أهم فرق. فخادم Counter-Strike يجيب عن استعلامات الحالة بصيغة Steam المسماة A2S، وخادم Minecraft Bedrock يجيب عن Unconnected Ping، وخادم Palworld يُبقي منفذ استعلام خاصاً به مفتوحاً. أما في Hytale فلا يوجد في الوثائق العلنية أي منفذ آخر إلى جانب ⁦5520 UDP⁩: لا منفذ استعلام، ولا منفذ RCON، ولا واجهة REST في حالة التسليم. وكل ما يعرضه خادم Hytale إلى الخارج يقع على منفذ UDP واحد.

خادم Hytale في أرقام

القيم التالية هي الأساس لكل قرار عن قواعد التصفية والقيم الحدية. والمصدر مذكور مع كل منها، لأنه يحدد مدى قابليتها للتحميل.

ما يغيّره QUIC في سطح الهجوم

QUIC بروتوكول نقل يُنشئ اتصالات مؤمَّنة فوق UDP ويحمل بناء التشفير وفق ⁦TLS 1.3⁩ مدمجاً فيه بشكل ثابت. ولا يوجد QUIC غير مشفَّر. ولمشغّل الخادم يعني ذلك أمرين يتناقضان، وكلاهما مهم.

الأول تحسين حقيقي. فلأن UDP لا يُرغم على إنشاء اتصال ولأن عناوين المرسل قابلة للتزييف، تكون خدمات UDP بلا اتصال هي المُضخِّمات الكلاسيكية للهجمات على أطراف ثالثة. وQUIC يحدّ من ذلك في المعيار نفسه. فيفرض ⁦RFC 9000⁩ في القسم 8.1 أن الخادم لا يجوز له قبل فحص عنوان المرسل أن يرسل أكثر من ثلاثة أضعاف كمية البايتات المستلمة، ويطلب القسم 14.1 أن يحشو العميل مخطط بياناته الأول إلى 1200 بايت على الأقل. وهاتان القاعدتان معاً ترفعان معامل تضخيم خدمة QUIC إلى ثلاثة كحد أقصى، بينما يبلغ منفذ استعلام Steam أو Unconnected Ping في Bedrock أضعاف ذلك. ولهذا فخادم Hytale الذي يعمل بشكل صحيح غير مثير للاهتمام عملياً كمُضخِّم انعكاس. وهذه ميزة بنيوية في مقابل جميع الألعاب ذات حركة UDP تقريباً، وتظهر بوضوح عند المقارنة بـ خوادم Minecraft Bedrock.

والثاني هو الثمن. فإنشاء اتصال QUIC يكلّف الخادم وقت معالجة، لأنه يشمل مصافحة ⁦TLS 1.3⁩ بتشفير غير متناظر. وحزمة مزيفة واحدة لا تستطيع إرغام الخادم على إنشاء اتصال، أما طوفان محاولات اتصال حقيقية من شبكة بوتات فيستطيع. والمهاجم يدفع كذلك وقت معالجة، وهذه النسبة بالضبط هي الحاسمة: فما دام الخادم يؤدي عن كل محاولة اتصال عملاً أكثر من المهاجم، فالهجوم مُجدٍ اقتصادياً. ولهذا لا يُحمّل طوفان محاولات الاتصال الوصلة، بل المعالج، وهو لا يبدو شيئاً في إحصاءات النطاق الترددي. وهذه هي الميكانيكا ذاتها المعروفة في Minecraft باسم Nullping وطوفان المصافحة، والموصوفة بالتفصيل في المقال الحماية من DDoS في Minecraft والحماية من Nullping.

والقابل للاستخدام عملياً في ذلك هو قاعدة 1200 بايت بالأساس. فمحاولة الاتصال الجديدة يجب أن تصل كمخطط بيانات لا يقل عن 1200 بايت، وإلا فهي وفق المعيار ليست إنشاء اتصال صالحاً. أما حركة اللعب الجارية فتتكون في معظمها من حزم صغيرة. وهذا التمييز يمكن صبّه في قاعدة تصفية، وسنأتي إلى ذلك مباشرةً.

ما ليس موثّقاً علناً عن Hytale

هذه القائمة تنتمي إلى مقال صادق، لأنها تحدد الموضع الذي لا يجوز لكم فيه الاعتماد على أرقام. وكل ما يلي ليس موثّقاً رسمياً بحال 27 سبتمبر 2026:

• ما إذا كان الخادم يستخدم QUIC-Retry لفحص العنوان. يسمح ⁦RFC 9000⁩ في القسم 8.1.2 بحزمة Retry برمز، يفحص بها الخادم عنوان المرسل قبل أن يربط موارد. أما ما إذا كان Hytale يفعل ذلك ومن أي حِمل، فغير موثّق. افترضوا أنكم لا تستطيعون الاعتماد على ذلك.
• القيم المسبقة للكتلتين RateLimit وConnectionTimeouts في config.json. أن الكتلتين موجودتان أمر متسق عبر عدة مصادر. لكن الأرقام المذكورة تتناقض: فمصدر يذكر قيماً حدية محددة، وآخر يصف الكتلتين على أنهما موجودتان لكن بلا أثر. ولهذا لا يرد أي من هذه الأرقام في هذا المقال، ولهذا لا ينبغي لكم إدراج هاتين الكتلتين في حساب دفاعكم.
• أسماء أنماط الاستيثاق وقيمها المسبقة. تصف وثائق المجتمع الخاصة بكود الخادم المنشور ثلاثة أنماط، تُضبَط عبر --auth-mode، مع authenticated كقيمة مسبقة وكذلك offline وinsecure للبيئات الخاصة وللتطوير. وهذا غير مؤكَّد رسمياً. والقاعدة المستخلصة من ذلك واضحة مع هذا: لا تغيّروا النمط لخادم عام.
• تفاصيل بناء TLS. تصف وثائق البروتوكول من المجتمع، المبنية على كود الخادم المنشور، شهادةً من الطرفين، وشهادة خادم ذاتية الإصدار تُولَّد عند الإقلاع ويصل بصمتها من نوع ⁦SHA-256⁩ إلى العملاء عبر خدمة الجلسات، وكذلك تعطيل ⁦0-RTT⁩. وهذا معقول ويلائم ⁦TLS 1.3⁩، لكنه غير مؤكَّد رسمياً، ولا يغيّر شيئاً في الإجراءات الواردة أدناه.
• أحجام الهجمات على خوادم Hytale تحديداً. لا توجد عنها أرقام علنية. والقيم المذكورة في الجدول بين ⁦5 Gbit/s⁩ و⁦50 Gbit/s⁩ هي قيمة خبرة عبر مشاريع خوادم اللعب وليست إحصاءً عن Hytale صراحةً.
• معدلات الحزم في التشغيل الطبيعي لكل لاعب. لا يوجد لذلك أيضاً أي منشور قابل للتحميل. ولهذا لا ترد في هذا المقال أي قيمة حدية تستطيعون أخذها دون فحص، بل يرد دليل على كيفية قياسها بأنفسكم.

ما تستطيعون فعله بأنفسكم قبل أن تدفعوا مالاً

الخطوات التالية لا توقف أي هجوم حجمي، فهذا ما لا تستطيع أي برمجية على الخادم تحقيقه. لكنها تُنظّف كل ما يقع تحته: فحص المنافذ، وطوفانات محاولات الاتصال من مصادر قليلة، ومحاولات الاستيلاء عبر واجهات إدارة مثبّتة إضافةً إلى ذلك، واحتلال الغرباء لكل الخانات. وهذا هو الجزء الأكبر من كل ما يُزعج خادم Hytale في الحياة اليومية، وهو يكلّف ساعة واحدة جيدة.

1. الجرد: ما الذي يستمع على الخادم؟

قبل أن تكتبوا قاعدة واحدة، انظروا ما الذي يعرضه خادمكم إلى الخارج. لا تخمّنوا، بل انظروا:

ss -lntup

المهم هو العمود الذي يحمل العنوان المحلي. فـ 0.0.0.0:5520 يعني «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:8080 يعني «محلياً فقط» ولا يحتاج إلى أي تصريح. وإلى جانب عملية Java الخاصة بالخادم تظهر على جهاز نما مع الوقت في الغالب لوحة إدارة، وخادم ويب لعرض الخريطة، وقاعدة بيانات. أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج:

nmap -Pn -sU -p 5520 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

والنداء الثاني هو الأهم. فهو يُظهر ما هو مفتوح إضافةً إلى ذلك، وهو في الممارسة أكثر من المتوقع دائماً تقريباً.

2. إبقاء ⁦5520 UDP⁩ وحده مفتوحاً وإغلاق كل ما عداه

تصريحان يكفيان. ومع UFW يبدو ذلك على النحو التالي، وبهذا الترتيب بالضبط حتى لا تحجبوا أنفسكم:

ufw allow 22/tcp comment 'SSH'
ufw allow 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

ولا تحتاجون إلى تصريح TCP على 5520. وإذا كنتم تشغّلون الخادم على منفذ مختلف، فيجب أن يطابق التصريح القيمة الواردة في --bind، وإلا اكتمل الإقلاع ولم يصل اللاعبون مع ذلك. والدليل الكامل مع طريق النجاة موجود في إعداد جدار حماية UFW دون حجب نفسكم.

ولكل ما ثبّتموه إضافةً إلى ذلك للإدارة تسري القاعدة ذاتها السارية في كل لعبة أخرى: لا في الشبكة المفتوحة، بل قابلاً للوصول عبر تمرير منافذ SSH، ثم العمل محلياً في مقابل 127.0.0.1:

ssh -N -L 8080:127.0.0.1:8080 root@YOUR.SERVER.IP.ADDRESS

3. تشغيل الخادم كما هو مقصود

الإقلاع يتكون من أمر واحد. وملفات الخادم تحصلون عليها عبر أداة تنزيل Hytale الرسمية أو من تثبيت اللعبة الخاص بكم:

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

وعند الإقلاع الأول يُنشئ الخادم ملف config.json والمجلد logs/ ومجلد العالم universe/. وبعد ذلك تُسجّلونه مرة واحدة في حسابه، لكي يعمل استيثاق اللاعبين. ويجري ذلك عبر رمز جهاز في وحدة تحكم الخادم:

/auth login device
/auth status

ولا تضبطوا -Xmx على كامل الذاكرة العاملة للجهاز. فنظام التشغيل، وذاكرة تخزين نظام الملفات المؤقت، وعبء تشغيل Java خارج الكومة يحتاجون إلى مكان كذلك، والخادم الذي ينزلق تحت الحِمل إلى ذاكرة التبديل يبدو للاعبيكم كهجوم بالضبط.

4. القائمة البيضاء وكلمة مرور الخادم والحد الأعلى للاعبين ضد استنفاد الخانات

استنفاد الخانات هو أرخص هجوم على خادم مجتمع ولا يحتاج إلى نطاق ترددي. فمن يبني ما يكفي من الاتصالات المتزامنة يحتل كل الخانات ويحجب بذلك المجتمع الحقيقي، دون أن يشتري غيغابت واحداً. وHytale يملك لذلك، بخلاف بعض الألعاب الأخرى، الأدوات المناسبة في حالة التسليم: قائمة بيضاء في whitelist.json، وقائمة حجب في bans.json، وصلاحيات في permissions.json، وفي config.json المفتاحان Password وMaxPlayers.

{
  "ServerName": "خادم Hytale الخاص بي",
  "MOTD": "",
  "Password": "قيمة لا تعرفها إلا مجموعتكم",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

والمفتاح Password فارغ من المصنع، أي أن كل من يملك العنوان والمنفذ يدخل. وللخادم المغلق تكون كلمة المرور المضبوطة أكثر إجراء مفرد فعالية ضد استنفاد الخانات، وللخادم العام تكون القائمة البيضاء هي ذلك أثناء موجة هجوم. وأمر واحد يجب أن يكون واضحاً: كلمة مرور الخادم تحمي خاناتكم، لا وصلتكم. فالمهاجم الذي يُغرق خادمكم لا يريد الانضمام أصلاً.

وحرّروا هذه الملفات عند خادم متوقف فقط. فعملية الخادم الجارية تحفظ حالتها الخاصة في الذاكرة وقد تكتب فوق التغييرات التي تكتبونها في الملف أثناء ذلك، دون تعليق، عند الإغلاق. وللتغييرات في التشغيل الجاري استخدموا أوامر وحدة التحكم بدلاً من المحرّر.

5. إبقاء الاستيثاق على القيمة القياسية

النمط القياسي يطلب من كل لاعب حساب Hytale صالحاً. وهذا أكثر من فحص ترخيص: إنه مُرشِّح وصول يجعل الحسابات بالجملة مكلفة. فالمهاجم الذي يريد احتلال الخانات يحتاج لذلك إلى حسابات صالحة، وهي تكلّف مالاً. لا تُخرجوا هذا المُرشِّح.

وتصف وثائق المجتمع إلى جانب القياسي نمطين آخرين للبيئات الخاصة وللتطوير، يمكن بهما الانضمام دون فحص الحساب. وهما لخادم عام أسوأ إعداد يمكن الوصول إليه، لأنهما يحوّلان استنفاد الخانات من مسألة مال إلى مسألة سكربت. وإذا حوّلتم للاختبار، فليكن ذلك على جهاز غير موجود في الإنترنت، وتعيدون التحويل بعد ذلك.

6. تحديد محاولات الاتصال الجديدة، وذلك بقاعدة 1200 بايت

الآن تصبح الميزة البنيوية لـ QUIC عملية. فإنشاء الاتصال الصالح يصل وفق ⁦RFC 9000⁩ كمخطط بيانات لا يقل عن 1200 بايت. وحركة اللعب الجارية أصغر بوضوح. ولهذا تستطيعون بتتبّع الاتصالات تمييز المجاري الجديدة من القائمة وإسقاط كل ما هو جديد وصغير جداً. ومع nftables، مُحمّلاً عبر nft -f:

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

والقاعدة الأولى تعمل على طول UDP، أي 8 بايت للرأس زائد 1200 بايت من الحمولة، أي 1208 معاً. وهي تصيب حصراً الحزم التي تريد فتح مجرى بيانات جديد وهي صغيرة جداً لذلك، ولا تستطيع إصابة اللاعبين المتصلين. والقاعدة الثانية تحدّ من عدد الاتصالات الجديدة التي يحق لعنوان مصدر واحد فتحها في الثانية. وخمسة في الثانية كرم: فاللاعب الحقيقي يبني اتصالاً ويحتفظ به. والأولوية -10 تضمن أن تعمل القاعدتان قبل سلسلة تصفية UFW.

والحد الأعلى لمعدل الحزم لكل عنوان مصدر على منفذ اللعبة نفسه هو القاعدة الثالثة المعقولة، وهنا يسري صراحةً: القيمة الرقمية قيمة بداية، لا حقيقة.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

قيسوا أولاً أسبوعاً في التشغيل الطبيعي، ثم اضبطوا الحد على ضعف قيمة الذروة المقيسة. ولا يوجد لـ Hytale رقم مرجعي منشور لذلك، والقيم تتعلق بقوة بعدد اللاعبين وبمدى الرؤية. ومن يضبط بضيق شديد يُخرج لاعبيه، وأولهم أصحاب أسوأ وصلة.

وقواعد iptables الصريحة تختفي بعد إعادة التشغيل. وعلى Debian وUbuntu تحفظونها كالتالي:

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

وتحت UFW تنتمي قواعد كهذه إضافةً إلى ذلك إلى /etc/ufw/before.rules، لأنها تختفي خلاف ذلك عند ufw reload التالي. وما إذا كانت القاعدة تُبلَغ أصلاً يُظهره iptables -L INPUT -n -v: فإذا بقيت عدّادات المطابقات عند صفر، فهي لا تعمل.

7. ضبط تتبّع الاتصالات في نواة النظام بشكل صحيح

هذه النقطة تشرح انقطاعات تبدو كهجوم حجمي وهي ليست كذلك. فنواة النظام تُنشئ لحركة UDP مُدخَلات في تتبّع الاتصالات، وعند عناوين مرسل مزيفة يعني كل عنوان مُدخَلاً جديداً. وإذا امتلأ الجدول، أسقطت نواة النظام الحزم دون تمييز، وطار الهجوم مع لاعبيكم معاً، ووقف في السجل «nf_conntrack: table full». والحال والحد الأعلى يُظهرهما:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

وفي معظم الألعاب يكون أفضل جواب على ذلك هو عدم تتبّع حركة اللعب على الإطلاق. أما في Hytale فهذه موازنة حقيقية، لأن قاعدة 1200 بايت من الخطوة 6 تحتاج إلى تتبّع الاتصالات. فبدونه لا يعرف المُرشِّح أي حزمة تفتح مجرى بيانات جديداً. ولهذا تكون التوصية: الإبقاء على التتبّع، وتكبير الجدول، وإبقاء مهلة انتهاء UDP قصيرة. وإضافة تحت /etc/sysctl.d/، تُنشَّط بالأمر sysctl --system:

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

ومن يريد إيقاف التتبّع مع ذلك، مثلاً على جهاز بعدد لاعبين متزامنين كبير جداً، يضع udp dport 5520 notrack في جدول raw ويتنازل بذلك عن قاعدة 1200 بايت. والاثنان معاً غير ممكنين. ولخادم Hytale مفرد تكون القاعدة أثمن من مُدخَلات الجدول الموفَّرة.

وإذا وصلت الحزم أسرع مما تسحبها عملية Java، طفح إضافةً إلى ذلك مخزن الاستقبال المؤقت. وهذا يبدو للاعبين كفقد حزم، وإن كانت الوصلة حرة. وما إذا كانت إعدادات المخزن المؤقت أعلاه ضرورية تكشفه نواة النظام بنفسها: فإذا ارتفع UdpRcvbufErrors في nstat -az، فهي تعمل. وإذا بقي العدّاد عند صفر، لم يغيّر التعديل شيئاً.

8. اختيار مدى الرؤية وعدد اللاعبين بما يلائم الوصلة

هذه الخطوة ليست إجراءً أمنياً، لكنها تحدد مقدار الهجوم الذي تتحملونه أصلاً. وقد صاغت Hypixel Studios ذلك بوضوح في متطلبات العتاد الرسمية بتاريخ 1 ديسمبر 2025: إذا ضاعفتم مدى الرؤية، ضاعفتم كمية العالم حول اللاعب أربع مرات. والتوصية الرسمية 12 قطعة على الأكثر، أي 384 كتلة، وتُضبَط عبر MaxViewRadius. وفي جهة العميل تذكر المتطلبات ذاتها ⁦2 Mbit/s⁩ كحد أدنى و⁦8 Mbit/s⁩ كتوصية لكل لاعب في اللعب الجماعي.

احسبوا ذلك لخادمكم مرة واحدة. فخادم بأربعين لاعباً ومدى رؤية كريم يحرّك في التشغيل الطبيعي نطاقاً من الميغابت بثلاثة أرقام منخفضة. وهذه هي القيمة التي يجب أن تُقاس وصلتكم بها، وهي في الوقت نفسه القيمة التي يجب على الهجوم تجاوزها لكي يلفت النظر. ومن يملأ وصلة بسرعة ⁦1 Gbit/s⁩ إلى الثلث في التشغيل الطبيعي يملك احتياطاً أقل من صاحب خمسة بالمئة. ولهذا فمدى الرؤية الأصغر ليس مسألة أداء وحدها، بل مسألة صلابة أيضاً.

9. متابعة الإضافات والملحقات وتغييرات البروتوكول

Hytale قابل للتعديل في جهة الخادم: فالإضافات توضع بصيغة .zip أو .jar في المجلد mods/، والملحقات تخاطب واجهة الخادم مباشرةً. وهذا مريح، لأن اللاعبين لا يحتاجون إلى تثبيت شيء، وهو في الوقت نفسه خطر على التوافر لا علاقة له بالهجمات. فالملحق الذي يعمل عملاً مكلفاً عند كل حدث شبكي هو مُضخِّم في بيتكم أنتم.

ويُضاف إلى ذلك تغيير البروتوكول. فمع ⁦Update 6⁩ تغيّر بروتوكول الشبكة وفق ملاحظات التحديث الرسمية بتاريخ 27 أغسطس 2026 من hytale/2 إلى hytale/3، ويجب إعادة بناء الخوادم والملحقات قبل أن تتصل. وللتوافر يعني ذلك: احفظوا قائمة بإضافاتكم مع إصدار كل منها، وافحصوها قبل كل تحديث على نسخة ثانية، واحسبوا نافذة صيانة قبل 12 أكتوبر 2026. فالخادم الذي لا يُقلع بعد تحديث لا يمكن للاعبيكم تمييزه من هجوم.

10. جمع القياسات قبل أن تصبح الأمور جدية

أهم خطوة هي تلك التي لا يفعلها أحد تقريباً مسبقاً: بناء أساس مقارنة ما دام كل شيء يعمل بشكل عادي. فبدون قيمة عادية لا تستطيعون القول بعد حادثة إن 40,000 حزمة في الثانية كانت كثيرة أم أنها كانت ليلة سبت عادية. وبالأمر apt-get install -y vnstat sysstat conntrack يعمل القياس بشكل دائم. وأثناء الحادثة تكفي خمسة أوامر:

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

ومع tcpdump يسري: التحديد بـ -c دائماً، فالتسجيل تحت حِمل كامل يُحمّل خادماً محمَّلاً فوق طاقته أصلاً حِملاً إضافياً. ولأن خادم Hytale يعمل على Java، تحتاجون إلى عيّنة ثانية تستبعد أكثر إنذار خاطئ شيوعاً. فتوقف جمع الذاكرة المهملة يبدو للاعبين كالهجوم بالضبط: يقف الجميع في وقت واحد، ثم يستمر الأمر. والفرق موجود في الأرقام.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

والتحليل بسيط. فإذا ارتفعت الحزم الواردة بعيداً فوق القيمة العادية، بينما تعمل عملية Java بالكاد، فهو هجوم. وإذا بقي معدل الحزم غير ملحوظ، بينما تمتلئ الكومة أو يُظهر السجل توقفات طويلة، فهو حِمل. وكيف تحلّلون قيم الشبكة بالتفصيل مذكور في التعرف على هجوم DDoS على الخادم.

11. النسخ الاحتياطي وخطة التراجع وتشغيل تجريبي قبل الموعد الكبير

مفهوم حماية لم يُختبر قط هو تخمين. وقبل موعد مثل 12 أكتوبر 2026 يجب أن تكون أربعة أمور منجَزة: نسخة احتياطية من المجلد universe/ مع config.json تقع خارج الجهاز، وعودة مفحوصة إلى إصدار الخادم السابق، ونسخة ثانية تُدخلون التحديث عليها أولاً، واختبار حِمل واحد يُطلِق قواعد التصفية الخاصة بكم.

واختبار الحِمل هو الموضع الذي يتوقف عنده معظم المشغّلين، وهو الأهم. لا تفحصوا ما إذا كانت قواعدكم تصدّ الهجمات، بل ما إذا كانت تُمرّر لاعبيكم أنفسهم. ويكفي لذلك مراقبة عدّادات المطابقات بينما ينضم عشرون لاعباً حقيقياً في وقت واحد. فإذا ارتفعت عدّادات قواعد الإسقاط في ذلك، فحدّكم مضبوط بضيق شديد، وكنتم ستعرفون ذلك في يوم التحديث وتحت أسوأ الظروف.

أين تنتهي هذه الإجراءات: النطاق الترددي ومعدل الحزم

والآن الجزء الذي لا يستطيع أي ملف إعداد حلّه. فكل الإجراءات السابقة تعمل على خادمكم، أي في نهاية الوصلة. وقاعدة جدار الحماية تبتّ في حزمة سارت فعلاً عبر الكابل. وتستطيعون إسقاطها، لكن لا تستطيعون جعلها غير مُرسَلة.

احسبوا معنا مرة واحدة. فخادم اللعب النموذجي معلّق على ⁦1 Gbit/s⁩، أي 125 ميغابايت في الثانية، والوصلة تمتلئ بمجرد أن يرسل أحد أكثر من ذلك. والهجمات على مشاريع خوادم اللعب تقع في العادة بين ⁦5 Gbit/s⁩ و⁦50 Gbit/s⁩، أي بين خمسة أضعاف وخمسين ضعف وصلتكم. وما إذا كانت قاعدة nftables خلف ذلك جيدة لم يعد يلعب أي دور، لأن حزم لاعبيكم لم تعد تمر من قبل ذلك.

والمقدار الثاني هو معدل الحزم، وهو يضرب في الغالب أبكر من النطاق الترددي. فعند حزم صغيرة بحجم 64 بايت يتسع في وصلة بسرعة ⁦1 Gbit/s⁩ نحو 1.49 مليون حزمة في الثانية. أما نواة نظام الخادم العادية فتعالج بعض مئات الآلاف منها بحسب المعالج وبطاقة الشبكة، قبل أن تبدأ بالإسقاط. أي أن هجوماً لا يملأ وصلتكم حتى إلى الثلث يستطيع مع ذلك تعطيل خادمكم، لأن وقت المعالجة يذهب في الإسقاط. ويعيش المشغّلون ذلك على شكل «الاستخدام لم يكن مرتفعاً أصلاً، ومع ذلك ضاع كل شيء».

ويُضاف في Hytale مقدار ثالث غير موجود في معظم الألعاب: وقت المعالجة الخاص بإنشاء الاتصال. فطوفان محاولات اتصال صالحة من شبكة بوتات لا يملأ وصلة ولا يولّد معدل حزم ملحوظاً، بل يُشغل المعالج بالتشفير. وهجمات كهذه غير مرئية في إحصاءات النطاق الترددي وواضحة في حِمل معالج عملية Java، ولا يفيد ضدها تحديد المعدل لكل عنوان مصدر ولا مخزن استقبال مؤقت أكبر، إذا كانت المصادر عديدة بما يكفي.

وللتصنيف، أي الأحجام التي تحدث فعلاً: على خوادم KernelHost صُفّي فيما صُفّي هجوم بأكثر من ⁦473.4 Gbit/s⁩ عند أكثر من 41.5 مليون حزمة في الثانية على خادم صوت، وإغراق UDP بأكثر من ⁦112.2 Gbit/s⁩ على خادم لعب. ولا يوجد لذلك أي إعداد محلي. فالهجمات الحجمية يجب أن تنتهي في الشبكة الواقعة قبل الخادم.

ما تضعه KernelHost في مقابل هجمات DDoS على خوادم Hytale

الحماية الدائمة المشمولة في كل حزمة خادم

الحماية من DDoS لدى KernelHost مبنية على مستويين وفعّالة بشكل دائم، دون أن تحتاجوا إلى تشغيل شيء أو طلبه أو إعداده:

• المستوى 1: سعة تخفيف تبلغ ⁦17 Tbps⁩ في شبكة التنقية العالمية. تُنقّى الهجمات الحجمية قريباً من مصدرها، قبل أن تصل إلى مركز البيانات.
• المستوى 2: تصفية Arbor في الوقت الفعلي بسعة ⁦3.2 Tbps⁩ في فرانكفورت أم ماين. وقبل الخادم مباشرةً تُكشَف الأنماط الخاصة بكل بروتوكول وتُسقَط، حزمةً حزمة.

وخاصّتان هنا حاسمتان. الحماية تعمل بشكل دائم ولا تحتاج إلى الاستجابة لهجوم أولاً، فلا توجد دقائق في البداية يكون الخادم فيها غائباً. ولا يُستخدم التوجيه إلى العدم: فعنوان IP الخاص بكم يبقى في الشبكة، وتُسقَط الحزم الضارة وحدها. ومن يسحب عنوان IP من الشبكة يصل بكم إلى النتيجة نفسها التي يريدها المهاجم. أما العناوين والبروتوكولات المشمولة بملفات حماية خاصة فيسردها المقال حماية خوادم اللعب من DDoS في الوقت الفعلي.

Advanced DDoS Protection لمشاريع Hytale التي تتعرض للقصف باستمرار

بعض المشاريع لا تُهاجَم من حين إلى آخر، بل تُهاجَم بشكل مقصود وعلى مدى أسابيع، وفي لعبة في Early Access يصيب ذلك الخوادم التي تنمو حالياً بشكل خاص. ولهذا توجد Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر، بنظام PrePaid، دون حد أدنى لمدة الالتزام ودون رسوم إعداد. والفرق ليس في سعة أكبر، بل في التحكم:

• عنوان IP مخصص للحماية من النواة الفرانكفورتية، يُحوَّل خادمكم إليه داخل شبكتنا. ولا يلزم أي تغيير في جهتكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء: تحدّدون ما المسموح على ⁦5520 UDP⁩، بمعزل عن كل ما عداه، ولا تحتاجون لذلك إلى أي تذكرة.
• التغييرات تسري في الوقت الفعلي، أي تستطيعون التعديل أثناء هجوم جارٍ، مثلاً تحديد الاتصالات الجديدة بقسوة أكبر لفترة قصيرة وترك حركة اللعب الجارية دون مساس.
• مجموعة قواعد مناسبة للبروتوكول، لـ QUIC فوق UDP كما للتطبيقات الخاصة على أي منفذ TCP أو UDP.

وتتوجه Advanced DDoS Protection إلى الخوادم القائمة لدى KernelHost. ومن يشغّل مشروع Hytale الخاص به حالياً في مكان آخر ويتعرض للهجوم بشكل دائم، ينقله لذلك إلى KernelHost، وحينها يعمل المستويان من لحظة التسليم.

مقارنة بين المستويين

ولمعظم خوادم Hytale تكفي الحماية الدائمة المشمولة مع إعداد نظيف للخادم. أما Advanced DDoS Protection فهي الجواب على أن يأخذ أحدهم الأمر على المستوى الشخصي.

ما يمكن نقله من ألعاب أخرى إلى Hytale

لأن Hytale ما زال حديثاً ولأنه لا توجد أرقام علنية عن الهجمات على خوادم Hytale، فأسرع طريق إلى معرفة قابلة للتحميل هو النظر في ألعاب مماثلة. والقابل للنقل في ذلك ليس رقم المنفذ، بل النمط.

• الانطلاق المتفجر وما يُطلقه: يُظهر Palworld كيف تتداخل زمنياً موجة لاعبين جدد وموجة هجمات ولماذا تصبح الخوادم النامية بالتحديد هدفاً.
• الفرق بين الاستعلام وحركة اللعب: يشرح Minecraft Bedrock عبر Unconnected Ping كيف يعمل التضخيم فوق UDP. وهذا الطريق بالضبط لا يملكه Hytale بفضل QUIC، وعنده يُفهَم الفرق على أفضل وجه.
• إنشاء الاتصال كهدف للهجوم: يصف الحماية من DDoS في Minecraft والحماية من Nullping طوفانات المصافحة التي تكتفي بنطاق ترددي لا يُذكر. وهذا أقرب قريب لطوفان اتصالات QUIC.
• أعداد اللاعبين الصغيرة واستنفاد الخانات: يُظهر Project Zomboid وConan Exiles كم يكفي من الجهد القليل لحجب مجموعة ثابتة، وأي دور تلعبه القائمة البيضاء وكلمة المرور في ذلك.
• التشغيل تحت حِمل دائم: يُظهر Terraria كيف تتفاعل عملية خادم مفردة ذات حِمل على نواة واحدة مع الهجمات. وخادم Hytale عملية Java، والمشكلة الأساسية قابلة للمقارنة.

أخطاء شائعة في خوادم Hytale وحلولها

«صرّحت للمنفذ 5520 على TCP واللاعبون لا يدخلون مع ذلك»: حركة اللعب تسير عبر QUIC، أي عبر UDP. والتصريح لـ TCP لا يفيد حركة اللعب بشيء. صرّحوا لـ ⁦5520 UDP⁩ وافحصوه من الخارج بالأمر nmap -Pn -sU -p 5520. وإذا وضعتم الخادم بـ --bind على منفذ آخر، فيجب أن يذكر التصريح هذا المنفذ.

«الخادم يعمل، لكن لا أحد يستطيع الانضمام، ولا يوجد في السجل شيء عن هجمات»: افحصوا تسجيل الخادم في حسابه بالأمر /auth status. فالخادم الذي انقضى تسجيله يستمر في العمل ويرفض اللاعبين مع ذلك. وهذه ليست مشكلة شبكة ولا قاعدة تصفية.

«بعد التحديث لم يعد شيء يُقلع»: هذا ليس هجوماً، بل تغيير البروتوكول. فمع ⁦Update 6⁩ تغيّر بروتوكول الشبكة من hytale/2 إلى hytale/3، والخوادم والملحقات تحتاج إلى بناء جديد. أدخِلوا التحديثات أولاً على نسخة ثانية، قبل أن تسمحوا بها على الخادم الإنتاجي.

«كل اللاعبين يقفون في وقت واحد لثانيتين، ثم يستمر الأمر»: هذا باحتمال عالٍ جمع الذاكرة المهملة في بيئة تشغيل Java وليس هجوماً. افحصوا jcmd ... GC.heap_info وسجل الخادم. فإذا بقي sar -n DEV 1 10 غير ملحوظ في ذلك، لم يكن هناك هجوم، بل كومة مضبوطة بضيق شديد أو مدى رؤية كبير جداً.

«قاعدتي ضد الحزم الصغيرة حجبت اللاعبين»: إذاً فشرط 1200 بايت موجود في السلسلة دون ct state new. فحركة اللعب الجارية تتكون في معظمها من حزم صغيرة، وشرط الطول دون فحص الحالة يصيبها بالضبط. والشرط يسري حصراً على المجاري المفتوحة حديثاً.

«بدّلت عنوان IP وكنت بعد ساعتين غير متصل من جديد»: المهاجم حصل على العنوان الجديد من المصدر ذاته الذي حصل منه على القديم. وفي Hytale يكون ذلك في الغالب مُدخَل A قديماً في DNS، أو بوت Discord بعرض للحالة، أو مُدخَلاً في إحدى قوائم الخوادم الكثيرة من أطراف ثالثة. ومنذ ⁦Update 6⁩ صارت عناوين الخوادم في قائمة الخوادم الرسمية مخفية من المصنع، وهذا يُغلق أسهل طريق، لا كل الطرق. فتبديل العنوان كسب وقت، لا حل.

«قواعد التصفية لدي لا تعمل»: ثلاثة أسباب شائعة. القواعد موجودة خلف سلاسل UFW ولا تُبلَغ قط، أو كانت قد اختفت بعد إعادة التشغيل الأخيرة (وحينها يفيد netfilter-persistent save أو مُدخَل في /etc/ufw/before.rules)، أو الهجوم حجمي والقاعدة تعمل بشكل صحيح على وصلة مليئة أصلاً. افحصوا بالأمر iptables -L INPUT -n -v ما إذا كانت عدّادات المطابقات ترتفع.

«مزوّدي السابق حجب عنوان IP الخاص بي»: هذا هو التوجيه إلى العدم. فالمزوّد يحمي بذلك شبكته الخاصة، أما لكم فالنتيجة مماثلة لهجوم ناجح، وفي الغالب لساعات بعده أيضاً. اسألوا عند الشك ما إذا كانت التصفية هي المستخدمة أم التوجيه إلى العدم. فالجواب يحدد في توافركم أكثر من أي معطى عن العتاد.

«في tcpdump لا أرى شيئاً غير معتاد»: إذا كانت الحركة تُصفّى في الشبكة الواقعة قبل الخادم أصلاً، فلا يصل إلى الخادم شيء كما هو متوقع. وهذه هي الحالة العادية عند تصفية تعمل. وفي المقابل يسري: إذا كانت الوصلة مُشبَعة، قد لا تصل إليكم حتى جلسة SSH التي أردتم القياس بها. استخدموا حينها وحدة VNC في منطقة العملاء، وهي تعمل بشكل مستقل عن شبكة النظام الضيف.

باختصار

• يحتاج خادم Hytale إلى منفذ مفتوح واحد بالضبط: ⁦5520 UDP⁩ لأجل QUIC. ولا يُحتاج إلى TCP لحركة اللعب، ولا يوجد في الوثائق العلنية أي منفذ آخر للاستعلامات أو لـ RCON أو للتحكم عن بعد.
• لأن QUIC لا يجوز له وفق ⁦RFC 9000⁩ أن يرسل قبل فحص العنوان أكثر من ثلاثة أضعاف كمية البايتات المستلمة، ولأن محاولة الاتصال الأولى يجب أن تكون بحجم 1200 بايت على الأقل، فخادم Hytale غير مثير للاهتمام عملياً كمُضخِّم انعكاس. وهذا يميّزه من الخوادم ذات استعلام Steam أو Unconnected Ping في Bedrock.
• وقاعدة 1200 بايت ذاتها هي أفضل قاعدة تصفية محلية: فما يريد فتح مجرى بيانات جديد على ⁦5520 UDP⁩ وهو أصغر من ذلك، لا يمكن أن يكون إنشاء اتصال صالحاً ويمكن إسقاطه دون إصابة اللاعبين المتصلين.
• والجزء المكلف في إنشاء اتصال QUIC هو التشفير، لا النطاق الترددي. فطوفان محاولات اتصال صالحة غير مرئي في إحصاءات النطاق الترددي ولا يُرى إلا في حِمل المعالج وفي عدّادات الاتصالات الجديدة.
• والنمط القياسي بوجوب الحساب هو مُرشِّح وصول يجعل الحسابات بالجملة مكلفة. ولخادم عام يبقى دون مساس، ويُضاف إليه whitelist.json وbans.json وقيمة مضبوطة في Password ضد استنفاد الخانات.
• والإجراءات المحلية تنتهي عند الوصلة: فـ ⁦1 Gbit/s⁩ هي 125 ميغابايت في الثانية، وعند حزم بحجم 64 بايت يتسع هناك نحو 1.49 مليون حزمة في الثانية. وكل ما فوق ذلك يجب أن ينتهي في الشبكة الواقعة قبل الخادم.
• وHytale في Early Access منذ 13 يناير 2026، و⁦Chapter 1⁩ معلَن للثاني عشر من أكتوبر 2026. والمواعيد الكبيرة مواعيد هجوم، والحماية التي تُطلَب في الموعد تأتي متأخرة.
• ولدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر وفعّالة من لحظة التسليم، دون توجيه إلى العدم. وتبدأ Advanced DDoS Protection بعنوان IP مخصص للحماية وقواعد لكل منفذ تديرونها بأنفسكم من ⁦50.00 EUR⁩ في الشهر.

إذا كان خادم Hytale الخاص بكم يعمل لدى KernelHost أصلاً، فالتصفية فعّالة دون أن تفعلوا شيئاً. وإذا لاحظتم مع ذلك أموراً غير معتادة، افتحوا تذكرة دعم ليُعاد ضبط قواعد التصفية لعنوان IP الخاص بكم. وأثناء هجوم جارٍ تستطيعون الوصول إلينا إضافةً إلى ذلك عبر محادثة الطوارئ على WhatsApp على الرقم +43 650 8209883.

هذا المقال بحال 27 سبتمبر 2026. وHytale في Early Access، وبروتوكول الشبكة تغيّر في هذه السنة مرة واحدة أصلاً. وسيُحدَّث المقال بعد ⁦Chapter 1⁩ وبعد كل تحديث يمسّ إنشاء الاتصال أو المنافذ أو قائمة الخوادم.