একই সাবনেটে থাকা দুটি সাইট কেন একটি LAN নয়

দুটি অফিসই 192.168.77.0/24 ব্যবহার করে, আর কেউ একটি টানেলের প্রস্তাব দেয় যাতে তারা এক নেটওয়ার্ক হয়। কথাটি সহজ শোনায় এবং তিনটি আলাদা নকশা লুকিয়ে রাখে: সংঘর্ষে থাকা দুটি স্বতন্ত্র LAN, WAN জুড়ে ইচ্ছাকৃতভাবে প্রসারিত একটি ইথারনেট সেগমেন্ট, এবং দূরের ঠিকানার পক্ষে উত্তর দেওয়া একটি proxy-ARP ব্যবস্থা। কোনটি আপনার আছে তা ঠিক করে হোস্টটি প্যাকেট নিয়ে কী করে, আর উত্তরটি VPN গেটওয়ে জড়িত হওয়ার আগেই দৃশ্যমান।

রাউটারের আগেই হোস্ট সিদ্ধান্ত নেয়

192.168.77.10/24 ঠিকানার একটি হোস্ট গন্তব্যটিকে নিজের প্রিফিক্সের সঙ্গে তুলনা করে। সেই প্রিফিক্সের ভেতরের সবকিছু একই লিংকে, তাই হোস্ট সরাসরি গন্তব্যের লিংক-লেয়ার ঠিকানা সমাধান করে। বাইরের সবকিছু ডিফল্ট গেটওয়েতে যায়।

এই সিদ্ধান্ত হোস্টের স্ট্যাকেই হয়, টানেলে নয়। গেটওয়েতে যোগ করা কোনো রুট সেই প্যাকেট বাঁচাতে পারে না যা হোস্ট কখনো সেখানে পাঠায় না।

তাই যখন 192.168.77.20 কেবল অন্য সাইটে থাকে, স্থানীয় হোস্ট তার জন্য ARP করে এবং কোনো উত্তর পায় না। VPN হ্যান্ডশেক পুরোপুরি সুস্থ থাকতে পারে, অথচ এটি ব্যর্থ হয়। ব্যর্থতাটি রাউটিং সমস্যার মতো নয়, মৃত হোস্টের মতো দেখায়। এই স্বাক্ষর চিনতে পারলে টানেল ডিবাগিংয়ের এক ঘণ্টা বাঁচে।

ARP হলো স্থানীয় লিংকের প্রশ্ন

ARP জিজ্ঞেস করে এই লিংকে ঠিকানাটি কার, আর উত্তরটি এমন কিছু থেকে আসতে হবে যা ব্রডকাস্ট শুনতে পায়। IPsec টানেলের অপর প্রান্তের রাউটার তা শোনে না, যদি না নকশাটি দুটি সাইটকে এক ব্রডকাস্ট ডোমেইনে পরিণত করে।

একই ঠিকানার দুটি ডিভাইস অবস্থা আরও খারাপ করে: সফল সমাধানও বলে দিতে পারে না কোনটি উত্তর দিয়েছে।

নকল ঠিকানা রাউটিংয়ের বাগ নয় এবং কোনো রুট তা ঠিক করে না। হয় সাইটগুলোকে আলাদা প্রিফিক্সে পুনঃসংখ্যায়ন করা হয়, নয়তো ইচ্ছাকৃতভাবে তারা এক লিংক-লেয়ার ডোমেইন হয়।

প্রসারিত সেগমেন্ট ফ্রেম বহন করে, রুট নয়

ব্রিজে যুক্ত ইথারনেট-বহনকারী টানেল দুটি সাইটকে এক লিংক-লেয়ার ডোমেইনের অংশ করে। ARP ব্রডকাস্ট অপর প্রান্তে পৌঁছায়, আর প্রতিটি ব্রিজ শেখে কোন MAC ঠিকানা কোথায় আছে। Linux ব্রিজ ডকুমেন্টেশন ওই MAC-ভিত্তিক ফরওয়ার্ডিং সীমাটি বর্ণনা করে।

এখানে দূরের গেটওয়ে দুটি অভিন্ন সাবনেটের মধ্যে আদৌ রাউটিং করে না। ফ্রেমগুলো এমন একটি আন্ডারলে অতিক্রম করে যা নিজেই IP রাউট করে, আর ব্রিজগুলো ইথারনেট কথোপকথন প্রসারিত করে।

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

Proxy ARP তৃতীয় নকশা

একটি রাউটার দূরের ঠিকানার জন্য ARP-এর উত্তর দিয়ে তারপর সেদিকে রাউট করতে পারে। এতে ব্রডকাস্ট ডোমেইন না টেনেও প্রেরকের কাছে দূরের হোস্টটি একই লিংকে দেখায়।

এটি ব্রিজিংয়ের চেয়ে সংকীর্ণ হাতিয়ার: এটি ফরওয়ার্ডিং, ফেরত রুট এবং প্রতিটি ঠিকানার স্পষ্ট মালিকের উপর নির্ভর করে।

এটি ইচ্ছেমতো নন-IP প্রোটোকলকে রাউটযোগ্যও করে না, এবং ইথারনেট ব্রডকাস্ট ডোমেইন পুনরুৎপাদন করে না। ঠিক এই প্রতিস্থাপনটাই যখন প্রয়োজন তখনই এটি ব্যবহার করুন, স্থগিত পুনঃসংখ্যায়নের শর্টকাট হিসেবে নয়।

প্রয়োজন থেকে বেছে নিন, তারপর যাচাই করুন

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

নিশ্চিত করুন আপনার প্রকৃত নকশা কোনটি হোস্টকে জিজ্ঞেস করে সে গন্তব্য নিয়ে কী করে:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

ব্যর্থ নেবার এন্ট্রিসহ একই-লিংক ফলাফল অনুপস্থিত লিংক-লেয়ার পথের দিকে ইঙ্গিত করে। via ফলাফল গেটওয়ের নাম বলে প্রশ্নটিকে রাউটিংয়ে সরিয়ে দেয়। ব্রিজে ফরওয়ার্ডিং ডেটাবেস দেখুন MAC টানেল পেরিয়ে শেখা হয়েছে কি না। প্রতিটি আউটপুট ডিজাইনের প্রশ্নটি নতুন করে শুরু না করে সংকীর্ণ করে।