قائمة ألعاب LAN فارغة عبر OpenVPN؟ افحص مسار الاكتشاف

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

افصل الانضمام إلى الجلسة عن العثور عليها

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

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

اختبر الانضمام المباشر قبل أن تمسّ النفق

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

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

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

افهم أين يتوقف البث

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

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

اكتشاف البث المتعدد يواجه المشكلة نفسها بفئة عناوين مختلفة، ويحتاج توجيه بث متعدد أو مرحّلًا بدلًا من استثناء بث.

حين يكون المرحّل مبرَّرًا، أبقِه ضيقًا

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

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

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

لا تستخدم الجسر إلا حين يحتاج التصميم إلى Ethernet

إطارات Ethernet تسير داخل TAP، لذا يمكن أن ينتمي نفق TAP إلى نطاق بث مجسور عن قصد. ومجرد تبديل dev tun إلى dev tap لا يبني ذلك الجسر، ولا يجعل إعداد الخادم متوافقًا، ولا يجعل التطبيق يختار الواجهة الجديدة. أما دليل التجسير في OpenVPN فيصف الترتيب الأوسع لا علاجًا لردهة فارغة واحدة.

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

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