فاحص المنفذ يقول مفتوح؟ لماذا لا يستطيع لاعبو Minecraft الانضمام رغم ذلك

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

هذه أربع طبقات مختلفة، وأي فشل في أي منها ينتج الجملة نفسها من اللاعب: لم ينجح الأمر.

الفحص لا يختبر إلا ما يستطيع رؤيته

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

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

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

أربع طبقات بين المقبس واللاعب

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

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

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

لماذا يسلك اللاعب الداخلي مسارًا مختلفًا

اللاعب على الشبكة المحلية نفسها، أو على VPN يصل إلى تلك الشبكة، يحاول الوصول إلى العنوان العام من الداخل. يذهب الطلب إلى عنوان الراوتر الخارجي، وعلى الراوتر أن يعيد ترجمته إلى الداخل، وهو الترتيب الذي يسمى عادة hairpinning أو انعكاس NAT. ويجب أن تتفق الترجمة الأمامية ومسار العودة معًا ليعمل ذلك، وكثير من راوترات المستهلكين لا تطبقه إطلاقًا.

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

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

توثيق Netgate لانعكاس NAT يصف الفرق بين الخارج والداخل وبديل split-DNS بمزيد من التفصيل. اقرأه وصفًا للآلية لا وعدًا بأن أي مزوّد VPN أو راوتر بعينه يدعم كل صيغ loopback.

اجمع الأدلة من كل وجهة نظر

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

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