NetBIOS عبر شبكة VPN: الاسم والبيانات والجلسة خدمات منفصلة
الشعار المتعلّق بالموجّهات أوسع من اللازم. تحقّق من أيّ الخدمات الثلاث يستخدمها تطبيقك، وما إذا كان يحلّ الأسماء عبر البثّ أم عبر خادم.
تتكرّر عبارة «NetBIOS لا يعبر الموجّهات» وكأنها حسمت التصميم. وهي لا تحسمه. عادةً يبقى البحث عن الاسم عبر البثّ داخل نطاق البثّ الخاص به، لكن خدمات NetBIOS يمكنها أيضاً استخدام حركة IP موجّهة تعمل بشكل سليم تماماً. السؤال المفيد ليس ما إذا كان NetBIOS يعبر الموجّهات؛ بل أيّ خدمة من خدماته الثلاث يستخدمها تطبيقك.
واجهة برمجية، لا بروتوكول سلكي واحد
يصف RFC 1001 بروتوكول NetBIOS بوصفه واجهةً تبرمج التطبيقات ضدّها، وتحته عدّة وسائط نقل. ويفصل نموذجه TCP/UDP بين خدمة الاسم وتوزيع مخططات البيانات وخدمة الجلسة، ويدعم صراحةً العمل مع بثّ IP أو دونه.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
هذا الجدول هو سبب فشل الشعار. خدمة الجلسة بين مضيفين مسمّيين هي محادثة IP؛ أما مخطط بيانات بثّيّ فليس كذلك. يمكن لتصميم VPN واحد أن يحقّق الأول ولا يحقّق الثاني، والاختبار الذي يثبت الأول لا يقول شيئاً عن الثاني.
أنواع العُقد تحدّد ما يطلبه العميل
تصف نماذج العُقد في RFC 1001 — البثّ والنقطة إلى النقطة والمختلطة — كيف يحلّ المضيف الأسماء: بسؤال الشبكة المحلية، أو بسؤال خادم أسماء مباشرةً، أو بتجربة أحدهما ثم الآخر. ويؤثّر النموذج في الحركة التي يجب السماح بها، لا في عمل التطبيق من أساسه.
يمنح ترتيب خادم أسماء مُدار العملاءَ مساراً من نقطة إلى نقطة، لكن فقط للعملاء المهيّئين لاستخدامه. ووضع خادم في مكان ما على الشبكة لا يجعل التطبيق يستشيره، والعميل المتروك في وضع البثّ سيظل يسأل المقطع المحلي وينتهي إلى مهلة. ويجب أن يصل عنوان الخادم إلى تهيئة العميل، عبر أيّ مسار إدارة يحترمه ذلك العميل.
لذلك سجّل ثلاث ملاحظات للتطبيق المعني: كيف يحوّل اسم الخادم إلى عنوان، وهل يستخدم الاكتشاف أو المراسلة البثّ أم نقطة نهاية موجّهة، وأيّ عنوان ووسيط نقل تستخدمه الجلسة الفعلية. هذه وقائع مستقلة، ولكل منها إصلاحه الخاص. وعملية حلّ اسم ناجحة واحدة ليست دليلاً إلا على الأولى.
NetBIOS عبر TCP/IP ليس NetBEUI
يخلط الناس بين الاثنين لأن كليهما يُوصف بأنه قديم. يحمل NetBIOS عبر TCP/IP خدماته داخل حزم IP، وهي حزم ينقلها النفق الموجّه أصلاً. أما NetBEUI فهو بروتوكول طبقة 2 غير قابل للتوجيه، والنفق IP لا ينقل إطارات إيثرنت عشوائية لمجرّد أنه ينقل IP.
لا يمكن لإضافة مسار IP أن تحوّل إطاراً غير IP إلى تطبيق IP. وإذا كان التطبيق يعتمد فعلاً على سلوك الطبقة 2، فالخيارات هي خدمة محدودة صراحةً للطبقة 2 أو استبدال التطبيق؛ ولا يوجد تغيير في التوجيه يقوم مقام أيٍّ منهما.
اختر أصغر تغيير يفي بالمهمة
مشاركة SMB حالية يُوصل إليها باسم DNS معتمد ومسار UNC صريح لا تحتاج إلى توسعة إيثرنت. فمهمة خدمة الملفات وتجربة التصفح متطلبان مختلفان، والثاني وحده يعتمد على قائمة الجيران. والوصول إلى المشاركة بالاسم يحلّ المهمة دون تمديد نطاق البثّ عبر نفق.
التصفح هو الجزء الذي يفشل عادةً، ويفشل بهدوء. يمكن للجهاز أن يفتح مشاركة عبر المسار بينما تبقى قائمة أجهزة الجوار فارغة، لأن القائمة تُملأ باكتشاف البثّ والمسار يستخدم DNS. وتحديد أنك تحتاج القائمة متطلب مختلف عن تحديد أنك تحتاج الملف. اكتب أيّهما طلبه المستخدم فعلاً قبل أن تصمّم أيّ شيء.
حين يحتاج تطبيق قديم فعلاً إلى البثّ أو إلى إطارات غير IP، قيّم خدمة محدودة للطبقة 2 بمالك مسمّى، أو استبدل التطبيق. فالجسر يوسّع نطاق الفشل المشترك وحدّ السياسة، وهذا قرار معماري لا مربّع اختيار مكتوب عليه NetBIOS. وثّق العمليات المحددة التي يجب أن ينقلها النفق، فيستطيع المسؤول تقييم الطلب بدل التخمين في «كل شبكات Windows».