VPN पर NetBIOS: नाम, डेटाग्राम और सत्र अलग-अलग सेवाएँ हैं
राउटर पर लगाया गया नारा बहुत व्यापक है। जाँचें कि आपका एप्लिकेशन तीनों में से कौन-सी सेवा प्रयोग करता है, और वह नाम ब्रॉडकास्ट से हल करता है या किसी सर्वर से।
«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 के ब्रॉडकास्ट, पॉइंट-टू-पॉइंट और मिश्रित नोड मॉडल बताते हैं कि कोई होस्ट नाम कैसे हल करता है: स्थानीय नेटवर्क से पूछकर, सीधे नाम सर्वर से पूछकर, या एक आज़माकर फिर दूसरा। यह मॉडल इस पर असर डालता है कि कौन-सा यातायात अनुमत होना चाहिए, इस पर नहीं कि एप्लिकेशन बिलकुल काम करता है या नहीं।
प्रबंधित नाम-सर्वर व्यवस्था क्लाइंटों को पॉइंट-टू-पॉइंट रास्ता देती है, पर केवल उन्हीं क्लाइंटों को जो उसका उपयोग करने के लिए कॉन्फ़िगर हैं। नेटवर्क में कहीं सर्वर रख देने से कोई एप्लिकेशन उससे परामर्श नहीं करने लगता, और ब्रॉडकास्ट मोड में छोड़ा गया क्लाइंट स्थानीय खंड से पूछता रहेगा और समय-सीमा तक पहुँच जाएगा। सर्वर का पता क्लाइंट के कॉन्फ़िगरेशन तक पहुँचना चाहिए, उसी प्रबंधन मार्ग से जिसका वह क्लाइंट सम्मान करता है।
इसलिए संबंधित एप्लिकेशन के लिए तीन अवलोकन दर्ज करें: यह सर्वर नाम को पते में कैसे बदलता है, खोज या संदेश भेजना ब्रॉडकास्ट इस्तेमाल करता है या निर्देशित अंतिम बिंदु, और वास्तविक सत्र कौन-सा पता और ट्रांसपोर्ट इस्तेमाल करता है। ये स्वतंत्र तथ्य हैं, और हर एक का अपना समाधान है। एक सफल नाम-समाधान केवल पहले के बारे में प्रमाण है।
TCP/IP पर NetBIOS, NetBEUI नहीं है
दोनों को मिला दिया जाता है क्योंकि दोनों को पुराना कहा जाता है। TCP/IP पर NetBIOS अपनी सेवाएँ IP पैकेटों के भीतर ले जाता है, जिन्हें रूट किया गया टनल पहले से ढोता है। NetBEUI परत 2 का ऐसा प्रोटोकॉल है जिसे रूट नहीं किया जा सकता, और IP टनल केवल इसलिए मनमाने ईथरनेट फ़्रेम नहीं ढोता कि वह IP ढोता है।
IP मार्ग जोड़ने से किसी गैर-IP फ़्रेम को IP एप्लिकेशन में नहीं बदला जा सकता। यदि कोई एप्लिकेशन सचमुच परत 2 के व्यवहार पर निर्भर है, तो विकल्प हैं स्पष्ट रूप से सीमित परत 2 सेवा या एप्लिकेशन को बदल देना; कोई रूटिंग परिवर्तन इनमें से किसी की जगह नहीं लेता।
वह सबसे छोटा बदलाव चुनें जो काम पूरा करे
स्वीकृत DNS नाम और स्पष्ट UNC पथ से पहुँचा जाने वाला मौजूदा SMB शेयर ईथरनेट विस्तार नहीं माँगता। फ़ाइल-सेवा का काम और ब्राउज़िंग का अनुभव अलग-अलग आवश्यकताएँ हैं, और केवल दूसरी पड़ोसी सूची पर निर्भर है। नाम से शेयर तक पहुँचना ब्रॉडकास्ट डोमेन को टनल के पार खींचे बिना काम हल कर देता है।
ब्राउज़िंग ही वह हिस्सा है जो आम तौर पर विफल होता है, और वह चुपचाप विफल होता है। मशीन पथ से शेयर खोल सकती है जबकि आस-पास के कंप्यूटरों की सूची खाली रहती है, क्योंकि सूची ब्रॉडकास्ट खोज से भरती है और पथ DNS इस्तेमाल करता है। यह तय करना कि आपको सूची चाहिए, यह तय करने से अलग आवश्यकता है कि आपको फ़ाइल चाहिए। कुछ भी डिज़ाइन करने से पहले लिखें कि उपयोगकर्ता ने वास्तव में कौन-सी माँग की थी।
जब कोई पुराना एप्लिकेशन सचमुच ब्रॉडकास्ट या गैर-IP फ़्रेम माँगता है, तो नामित स्वामी वाली सीमित परत 2 सेवा का मूल्यांकन करें, या एप्लिकेशन बदल दें। ब्रिज साझा विफलता-डोमेन और नीति-सीमा दोनों बढ़ाता है, और यह NetBIOS लिखा हुआ चेकबॉक्स नहीं, वास्तुकला का निर्णय है। टनल को कौन-से ठोस ऑपरेशन ढोने हैं यह दर्ज करें, तब प्रशासक «पूरे Windows नेटवर्किंग» का अंदाज़ा लगाने के बजाय अनुरोध का मूल्यांकन कर सकेगा।