দুই মালিক, এক ঠিকানা: TAP ব্রিজে ডুপ্লিকেট IP

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

ব্রিজে হাত দেওয়ার আগে দ্বন্দ্বের প্রমাণ পড়ুন

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

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

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

সেগমেন্টের প্রতিটি দাবি তালিকাভুক্ত করুন

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

এই ক্রমে তালিকাটি হাঁটুন: প্রতিটি ব্রিজ ডিভাইস ও তার সদস্য পোর্টের ঠিকানা, OpenVPN পুল এবং প্রতি ক্লায়েন্টের যেকোনো নির্দিষ্ট বরাদ্দ, এবং ব্রিজড সেগমেন্ট ঢাকা যেকোনো DHCP সার্ভার। তারপর দ্বন্দ্ব রিপোর্টের হার্ডওয়্যার ঠিকানাটি আপনি যে ইন্টারফেসগুলো পেয়েছেন তার সঙ্গে মেলান।

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

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

ব্রিজকে কেবল সেখানেই নম্বর দিন যেখানে পরিচয় দরকার

সাধারণ হোস্ট ব্রিজে ব্রিজ ডিভাইসটি হোস্টের তৃতীয় স্তরের কনফিগারেশন বহন করে এবং Ethernet ও TAP সদস্যরা পোর্ট হিসেবে কাজ করে। প্রতিটি সদস্যকে নিজের ঠিকানা দেওয়া, বা ঠিকানা না বদলে একটি সেটআপ স্ক্রিপ্ট কয়েকটি মেশিনে কপি করা—এভাবেই এক সেগমেন্টে একই মানের তিন মালিক হয়ে যায়। ফ্রেম ফরওয়ার্ড করতে সদস্যদের নিজেদের পরিচয় দরকার নেই। তাদের দরকার প্রতি হোস্টে ঠিক একটি পরিচয়, যে হোস্টটি সেই সেগমেন্টে পৌঁছানোযোগ্য হতে হবে।

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

আপনি যে ঠিকানাটি মুছতে যাচ্ছেন সেটিই যদি মেশিনে ঢোকার একমাত্র পথ হয়, তবে পরীক্ষা হিসেবে তা মুছে ফেলা একটি স্ব-ঘটিত বিভ্রাট, রোগনির্ণয় নয়। কিছু পরীক্ষা করার আগে আউট-অব-ব্যান্ড পথটি যাচাই করুন।

সংশোধনটি রিবুটেও টিকে থাকুক

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

ওই কনফিগারেশনের মালিক খুঁজুন: নেটওয়ার্ক ম্যানেজার প্রোফাইল, প্রতি-ইন্টারফেস ফাইল, কনটেইনার বা VM সংজ্ঞা, বা cloud-init ফ্র্যাগমেন্ট। সেখানেই তা বদলান, তারপর নতুন মানটিই ফিরে আসে কিনা নিশ্চিত করতে ইচ্ছাকৃতভাবে একটি আক্রান্ত হোস্ট রিবুট করুন। রিবুটই একমাত্র পরীক্ষা যা স্থায়িত্ব প্রমাণ করে।

DHCP রেঞ্জের ভেতরের ব্রিজ ঠিকানাগুলো বাদ হিসেবে সংরক্ষণ করুন, বা সেগুলো রেঞ্জের বাইরে সরান। যে সংরক্ষণ কেবল একটি স্প্রেডশিটে আছে তা বাদ নয়, আর বণ্টনকারী তা পড়বে না।

প্রতিটি ক্লায়েন্ট অনলাইন থাকা অবস্থায় এটি প্রমাণ করুন

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

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

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

উত্তর না পাওয়া অনুসন্ধান পরিষ্কার সেগমেন্টে প্রত্যাশিত ফলাফল। যে অনুসন্ধান প্রতিক্রিয়া টেনে আনে তা আপনাকে অবশিষ্ট মালিকের হার্ডওয়্যার ঠিকানা দেয়, যা শুরুতে Windows ইভেন্ট যে প্রমাণ দিয়েছিল ঠিক তা-ই। সেই আউটপুট পরিবর্তন রেকর্ডের সঙ্গে রাখুন, কারণ ঠিকানাটি অনন্যভাবে ধরে আছে এর একমাত্র প্রমাণ সেটিই।