সেতুতে সংযুক্ত সাইটগুলোর এখনও স্থানীয় ইন্টারনেট এক্সিট সিদ্ধান্ত দরকার

VLAN সম্প্রসারণ পরিষ্কারভাবে পরীক্ষায় উত্তীর্ণ হয়েছে: দুই সাইটের হোস্ট একে অপরকে দেখছে, ফাইল শেয়ার কাজ করছে, প্রিন্টার উত্তর দিচ্ছে। তারপর ছোট সাইটের কেউ খেয়াল করে যে প্রতিটি ডাউনলোড অন্য সাইটের ইন্টারনেট লাইন ব্যবহার করছে, এবং টিকিটটি ব্যান্ডউইথ অভিযোগ হিসেবে আসে। সেতু ঠিক যা চাওয়া হয়েছিল তাই করেছে। এটি দুটি ভবনের মধ্যে ফ্রেম বহন করেছে, এবং ইন্টারনেটের জন্য সেই ফ্রেমগুলো কোন রাউটার ব্যবহার করবে সে সম্পর্কে এর কোনো মতামত ছিল না।

সেতু ফ্রেম বহন করে, সিদ্ধান্ত নয়

লেয়ার 2 সম্প্রসারণ দুটি স্থানকে এক ব্রডকাস্ট ডোমেইনের মতো দেখায়, তাই ARP অনুরোধ, DHCP ব্রডকাস্ট এবং একই সাবনেটের ট্রাফিক সবই টানেল পার হয়। এটিই এর সম্পূর্ণ সেবা। সেতুর ভেতরে কিছুই গন্তব্য ঠিকানা পরীক্ষা করে না, সাইটের আপলিংকের সঙ্গে তুলনা করে না, বা ট্রাফিককে নিকটবর্তী এক্সিটের দিকে চালায় না। প্রতিটি ক্লায়েন্ট এখনও যে ঠিকানা ও মাস্ক দিয়ে কনফিগার করা হয়েছে তা ব্যবহার করে নিজের স্থানীয় বনাম দূরবর্তী সিদ্ধান্ত নিজেই নেয়।

ওই শেয়ার করা সাবনেটে দুটি রাউটার রাখুন, এবং দুটিই সম্ভাব্য গেটওয়ে হয়ে যায়, সেটি ব্যবহারকারী ক্লায়েন্টের নিকটে আছে কি নেই তা নির্বিশেষে।

ক্লায়েন্ট কীভাবে তার গেটওয়ে বেছে নেয়

RFC 1122-এ বর্ণিত IPv4 সিদ্ধান্তটি সহজ। ক্লায়েন্টের সংযুক্ত সাবনেটের ভেতরের গন্তব্যে সরাসরি ARP দিয়ে পৌঁছানো যায়, আর এর বাইরের গন্তব্য কনফিগার করা ডিফল্ট গেটওয়েতে যায়। এজন্যই সাইটগুলোর মধ্যে একই সাবনেটের ট্রাফিক কোনো রাউটারের অংশগ্রহণ ছাড়াই সেতু পার হতে পারে, এবং এজন্যই ইন্টারনেট ট্রাফিক সম্পূর্ণভাবে ক্লায়েন্ট যে গেটওয়ে ঠিকানা পেয়েছে তার ওপর নির্ভর করে। দুটি আচরণ স্বতন্ত্র, এবং কাজ করা একটি ফাইল শেয়ার শুধু প্রথমটিই প্রমাণ করে।

যদি ছোট সাইটের কোনো ক্লায়েন্ট বড় সাইটের রাউটার দিয়ে কনফিগার করা হয়, তবে তার ইন্টারনেট ফ্রেম আগে টানেল পার হয় এবং সেখান থেকেই বেরোয়।

VPN অ্যাপ্লায়েন্সের নিজের ডিফল্ট রুট বদলালে ওই ক্লায়েন্টের গেটওয়ে সরে না, কারণ ক্লায়েন্ট অ্যাপ্লায়েন্সটিকে রাউটার হিসেবে ব্যবহারই করে না। অ্যাপ্লায়েন্সেরও তার দূরবর্তী পিয়ারের জন্য আলাদা রুট দরকার যাতে ওই ফ্রেম বহনকারী টানেল চালু থাকে, আর এই দুটিকে গুলিয়ে ফেলাই সেতু সম্প্রসারণের নিজের পরিবহন ভেঙে পড়ার কারণ।

DHCP-কে অভীষ্ট এক্সিট প্রকাশ করতে দিন

DHCP উত্তরে অপশন 3 ক্লায়েন্টের সাবনেটে রাউটার ঠিকানার তালিকা পছন্দক্রমে দেয়, এবং ক্লায়েন্টরা সাধারণত প্রথমটি নেয় যেটি উত্তর দেয়। প্রক্রিয়াটি ঠিক আছে; মালিকানা যেখানে নকশা ভুল হয়। নিকটতম DHCP সার্ভার নিকটতম গেটওয়ে দেবে ধরে না নিয়ে প্রতিটি সাইটে একটি প্রকৃত লিজ কী দেয় তা লিখে রাখুন।

একটি সমন্বিত অ্যালোকেটর চালান, বা দুটি যা স্পষ্টভাবে একই নীতির জন্য কনফিগার করা, এবং নীতির একটি মালিক দিন। দূরবর্তী সাইটে যোগ করা দ্বিতীয় স্বাধীন অ্যালোকেটর স্থানীয়তা তৈরি করে না, এটি একই ব্রডকাস্ট ডোমেইনের জন্য দুটি কর্তৃপক্ষ তৈরি করে।

শুধু দুই সাইটের সেটিংস একই রকম দেখাতে একটি গেটওয়ে ঠিকানা দুটি স্বাধীনভাবে সক্রিয় রাউটারকে দেবেন না। সেতুতে সংযুক্ত সেগমেন্ট জুড়ে শেয়ার করা ভার্চুয়াল ঠিকানা একটি প্রথম-হপ রিডান্ডেন্সি নকশা যার নিজস্ব চাহিদা আছে, আর হাতে গড়া সংস্করণ ARP দ্বন্দ্ব তৈরি করে যা মাঝেমধ্যে প্যাকেট হারানোর মতো দেখায়। যদি অ্যাপ্লিকেশনটির সত্যিই শেয়ার করা লেয়ার 2 সেগমেন্ট দরকার না হয়, স্থানীয় ডিফল্টসহ আলাদা রাউটেড প্রিফিক্স চালানো সহজ এবং কোনো ঘটনার সময় ব্যাখ্যা করাও সহজ।

চারটি বিষয় আলাদাভাবে পরীক্ষা করুন

একটি নয়, চারটি পর্যবেক্ষণ চান। প্রতিটি সাইটে নতুন DHCP লিজ নিন এবং যে রাউটার ও মাস্ক পেয়েছে তা লিখুন। অন্য সাইটে একই সাবনেটের একটি সেবায় পৌঁছান এবং পথটি রাউটেড ঘুরপথ নয়, সেতু তা নিশ্চিত করুন। প্রতিটি সাইটে পাবলিক ইন্টারনেট থেকে কিছু আনুন এবং কোন আপলিংক তা বহন করেছে তা নিশ্চিত করুন। তারপর টানেল নামিয়ে দিন এবং কী ভাঙে দেখুন, কারণ সেতু ব্যর্থ হলে যে সাইট সব সংযোগ হারায় সে কেউ না জেনেই দূরবর্তী গেটওয়ের ওপর নির্ভর করছিল।

ওই চারটি ফলাফল বলে দেয় আপনার কাছে আন্তঃসাইট সেতু, স্থানীয় এক্সিট, না আকস্মিক ব্যাকহল আছে, এবং সেগুলো সংগ্রহ করতে দশ মিনিট লাগে।

নকশার নীতিটি জমকালো নয়: সেতু পৌঁছানোযোগ্যতা ঠিক করে, DHCP গেটওয়ে ঠিক করে, আর অ্যাপ্লায়েন্সের রাউটিং টেবিল টানেলের নিজের পথ ঠিক করে। তিনটিকে আলাদা আলোচনায় রাখুন, কারণ সবগুলো ঠিক করার চেষ্টা করা একটি পরিবর্তন সাধারণত দুটি ভেঙে দেয়।