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 নেটওয়ার্কিং» নিয়ে আন্দাজ করার বদলে অনুরোধটি মূল্যায়ন করতে পারবেন।