OpenVPN-এর মাধ্যমে দুটি বোর্ডের মধ্যে বিচ্ছিন্ন TAP ব্রিজ

দুটি ডেভেলপমেন্ট বোর্ডকে একটি ইথারনেট সেগমেন্ট ভাগ করতে হবে, অথচ তাদের বেঞ্চ দুটি আলাদা ভবনে আছে। টানেল আগেই আছে এবং আগেই ইথারনেট বহন করে, তাই বাকি কাজটি তিনটি কমান্ডের মতো দেখায়, কিন্তু তা নয়। হোস্ট একটি ব্রিজকৃত ফ্রেম নিয়ে কী করে, পিসির নিজের ঠিকানাটি কোথায় থাকে, এবং ব্রিজ কোন সীমানা তৈরি করে না—এগুলো তিনটি আলাদা তথ্য, আর দ্বিতীয়টি ভুল করা হলো ল্যাব মাঝে মাঝে কাজ করার এবং তার ম্যানেজমেন্ট অ্যাক্সেস চুপচাপ খারাপ হতে থাকার স্বাভাবিক কারণ। এই তিনটি তথ্যের কোনোটিই টপোলজি ডায়াগ্রামে দেখা যায় না।

নিচের পথটি দুটি লিনাক্স পিসির মধ্যে প্রত্যয়িত TAP সংযোগ, প্রতি বেঞ্চে একটি নির্দিষ্ট তারযুক্ত পোর্ট, এবং পরীক্ষার অংশ নয় এমন একটি ম্যানেজমেন্ট ইন্টারফেস ধরে নেয়। ক্রমটি গুরুত্বপূর্ণ: আগে ফ্রেম, তারপর ঠিকানা, শেষে সীমানা।

ব্রিজ আসলে কী সরায়

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

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

দুটি পিসিতে একই নামগুলো স্থানীয় নাম, ভাগ করা বস্তু নয়। বেঞ্চ দুটির মধ্যে একটি ইথারনেট পথ আছে, দ্বিতীয় কেবল এবং লুপ বন্ধ করা দ্বিতীয় টানেল নেই; যে ব্রিজ একই MAC দুটি পোর্টে আসতে দেখে সে আনন্দেই বৃত্তে বৃত্তে ফরওয়ার্ড করবে।

ব্রিজকে ঠিকানা দিন, তার সদস্য পোর্টগুলোকে নয়

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

প্রতি বেঞ্চে কেন একটি নির্দিষ্ট পোর্ট

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

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

ল্যাব রেঞ্জকে যেকোনো প্রোডাকশন DHCP স্কোপের বাইরে রাখুন। বোর্ডগুলোর পরে যদি গতিশীল ঠিকানাকরণ দরকার হয়, তবে একটি অনুমোদিত অ্যালোকেটর ও একটি পুলই একমাত্র ব্যবস্থা যা পূর্বানুমেয় থাকে; দুটি সাইটের সাধারণ রাউটার একই সেগমেন্টে উত্তর দিলে এমন ঠিকানা তৈরি হয় যা কেউ ব্যাখ্যা করতে পারে না।

যে সীমানা ব্রিজ তৈরি করে না

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

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

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

সবশেষে, পরিবহন ও গোপনীয়তা দুটি আলাদা ক্রয়। TAP ইথারনেট বহন করে; OpenVPN পরিষেবা তার চারপাশের সুরক্ষা জোগায়। VXLAN ওভারলেও ইথারনেট বহন করে এবং নিজে থেকে কোনো গোপনীয়তা দেয় না, তাই একটি অন্যটির বদলে বসালে নিরাপত্তার বৈশিষ্ট্য বদলে যায়, যদিও টপোলজি ডায়াগ্রাম একই দেখায়।

স্থায়িত্ব এবং যে পরীক্ষাগুলো তা প্রমাণ করে

সংযোগের পরে একবার টাইপ করা কমান্ড কোনো কনফিগারেশন নয়। পিসির বিদ্যমান নেটওয়ার্ক ম্যানেজারের মাধ্যমে ব্রিজ, পোর্ট সদস্যপদ ও একক হোস্ট ঠিকানা স্থায়ী করুন, এবং সংযুক্তিকে TAP ডিভাইসের আবির্ভাবের সাথে বেঁধে দিন যাতে পুনঃসংযোগ একটি সদস্য হারানো ব্রিজ রেখে না যায়।

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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