আপনি একটি সাইট ব্রিজ করেন কারণ কোনো টুল জোর দেয় যে এটি একই নেটওয়ার্কে থাকতে হবে, আর তিন সপ্তাহ পরে আপনি রাত দুইটায় সুইচ লগ পড়ছেন। এই ধরনের অনুমান অনেক বেশি Ethernet-over-IP লিঙ্কের ভাগ্য নির্ধারণ করে। এখানে সত্যিই কেবল একটি পার্থক্য গুরুত্বপূর্ণ: সম্পূর্ণ ফ্রেম কি প্রান্ত থেকে প্রান্তে যায়, নাকি কেবল IP প্যাকেট যায়। নিচের পাঁচটি যাচাই ক্রমে চালান এবং প্রথমটি ব্যর্থ হলে থামুন।

অ্যাপ্লিকেশনটি আসলে তারের উপর কী পাঠায় তা যাচাই করুন

কোনো পণ্যের নাম আলোচনায় আসার আগে, লিঙ্কটি যে ট্রাফিক পার করতে হবে তার এক মিনিট ক্যাপচার করুন: tcpdump -i eth0 -nn -e 'not ip'। -e ফ্ল্যাগটি লিঙ্ক-লেয়ার হেডার প্রিন্ট করে, যা ঠিক সেই অংশটুকু যা রাউটেড টানেল ফেলে দেয়। যদি ক্যাপচার খালি থাকে, আপনার অ্যাপ্লিকেশন IP-তে কথা বলে এবং একটি L3 টানেল সেটি অপরিবর্তিত বহন করে। যদি ফ্রেম দেখা যায়, তবে EtherType লিখে রাখুন, কারণ 0x0806 হল ARP, 0x88cc হল LLDP, এবং কোনো ভেন্ডর মান সাধারণত এমন একটি ডিসকভারি প্রোটোকল বোঝায় যার IP বিকল্প নেই। এই বিন্দুতেই একটি সাধারণ tun ইন্টারফেস আর যথেষ্ট থাকে না।

দূরের দিকেও ক্যাপচারটি পুনরাবৃত্তি করুন। যে ফ্রেম কেবল একটি হোস্টের ভার্চুয়াল সুইচের ভেতরে থাকে, তা WAN জুড়ে ব্রডকাস্ট ডোমেইন টানানোর কারণ নয়।

ডিসকভারিকে লিঙ্ক পার হতে হবে কি না যাচাই করুন

রাউটেড টানেলের কোনো শেয়ার্ড সেগমেন্ট নেই, তাই গ্রুপের কাছে ঠিকানা দেওয়া কোনো কিছুই অন্যপ্রান্তে পৌঁছায় না। ARP, DHCP ব্রডকাস্ট, 224.0.0.251 ঠিকানায় mDNS, SSDP এবং NetBIOS নাম কোয়েরি সবই এমন একটি লিঙ্ক ধরে নেয় যা একসাথে কয়েকটি হোস্ট শুনতে পায়।

এর মধ্যে কোনটির উপর অ্যাপ্লিকেশনটি সত্যিই নির্ভর করে এবং তার জন্য আগে থেকেই কোনো প্রক্সি আছে কি না জিজ্ঞেস করুন। DHCP রিলে, mDNS রিফ্লেকশন এবং স্ট্যাটিক ARP এন্ট্রি প্রত্যেকে একটি নির্ভরতা সরায়, এবং প্রত্যেকটিই চালাতে ও মনিটর করতে হয় এমন আরেকটি সার্ভিস। যখন দুই বা তিনটি বাকি থাকে, ব্রিজ করাই সৎ উত্তর।

অতিরিক্ত হেডার আপনার কত খরচ করায় তা যাচাই করুন

ফ্রেমের থাকার জায়গা দরকার, তাই আপনি যা পাঠান সবকিছুর চারপাশে দ্বিতীয় একটি হেডার স্ট্যাক জড়ানো হয়। VXLAN ওভারলেতে এর অর্থ একটি বাইরের IP হেডার, একটি UDP হেডার এবং একটি 8-বাইট VXLAN হেডার, যা পূর্ণ আকারের 1,500-বাইট পেলোডকে সাধারণ 1,500-বাইট ইন্টারনেট লিঙ্কের পাথ MTU ছাড়িয়ে ঠেলে দেয়। OpenVPN tap মোডে একই দিকে নিজের ওভারহেড যোগ করে। ভেতরের দিকে কম MTU না থাকলে আপনি এমন লিঙ্ক পান যা ping-এর উত্তর দেয় কিন্তু প্রথম বড় ট্রান্সফারেই আটকে যায়।

বিল হেডার বাইটেই থামে না। সুইচ হার্ডওয়্যারে যেসব ব্রডকাস্ট ও মাল্টিকাস্ট সামলায় তা এখন WAN-এ চড়ে, এবং প্রতিটি ব্রিজ করা সাইট একই ঠিকানা প্ল্যান, DHCP স্কোপ ও ডুপ্লিকেট-ঠিকানা আচরণ উত্তরাধিকারসূত্রে পায়। এতে লিঙ্কটি প্রতি সাইটে একটি প্রিফিক্সযুক্ত রাউটেড পুলের তুলনায় অনেক বেশি অডিট-কঠিন হয়ে ওঠে।

বেছে নেওয়ার আগে হিসাবটি করুন। তিনটি সাইটে প্রতিলিপি করা একটি ব্যস্ত সেগমেন্ট যে ফাইল ট্রান্সফারের জন্য এটি তৈরি হয়েছিল তার চেয়ে বেশি ব্রডকাস্ট ট্রাফিক সরাতে পারে।

আপনাকে কোন ধরনের L2 VPN দেওয়া হচ্ছে তা যাচাই করুন

শব্দটি নিজেই অস্পষ্ট, আর এই অস্পষ্টতাই ঠিক করে আপনার ট্রাফিক কে বহন করবে। কখনও এটি পেলোড বোঝায়: IP-এর ভেতরে Ethernet ফ্রেম, অন্য যেকোনো টানেলের মতোই ইন্টারনেট দিয়ে পাঠানো, যেমন VXLAN, ZeroTier এবং OpenVPN-এর tap মোড করে। কখনও এটি কেনা সার্ভিস বোঝায়: একটি ক্যারিয়ার Ethernet সার্কিট বা MPLS সিউডোওয়্যার যা একটি প্রোভাইডার নেটওয়ার্কের ভেতরে দুই সাইটকে যুক্ত করে।

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

ব্রিজ করার আগে সস্তা বিকল্পটি যাচাই করুন

ব্রিজ করা লিঙ্কের বেশিরভাগ অনুরোধ আসে একটিমাত্র ভাঙা লুকআপ থেকে, এমন প্রোটোকল থেকে নয় যার সত্যিই ফ্রেম দরকার। প্রথমে রিজলভার ও সার্চ ডোমেইন রাউটেড টানেল দিয়ে পাঠান: dhcp-option DNS 10.8.0.1 এর সঙ্গে dhcp-option DOMAIN internal.example একটি OpenVPN সার্ভার কনফিগারেশনে অবাক করার মতো অনেকগুলো সমাধান করে দেয়। দূরের দিকে একটি লোকাল ফরওয়ার্ডার কোনো ব্রডকাস্ট ট্রাফিক না সরিয়েই একই কাজ করে।

যদি একটি পুরোনো টুল তখনও ব্যর্থ হয়, তবে সেই টুলটি গন্তব্য সেগমেন্টে একটি প্রক্সি বা জাম্প হোস্টের পিছনে রাখুন। একটি TCP ফরওয়ার্ডার চালানো ব্রিজ করা WAN-এর চেয়ে সস্তা।

সিদ্ধান্তটি ক্রমে শেষ করুন: ট্রাফিক কি নন-IP EtherType বহন করে, ডিসকভারিকে কি পার হতে হবে, MTU কি অতিরিক্ত হেডার শুষে নিতে পারে, প্রোভাইডার সার্কিট কি সত্যিই পাওয়া যায়, এবং রাউটেড বিকল্পটি কি এমন কোনো কারণে ব্যর্থ হয়েছে যা আপনি নাম দিতে পারেন? যেকোনো ধাপে একটি না আপনার কাছে ইতিমধ্যেই থাকা টানেলের পক্ষে তর্ক শেষ করে দেয়। ক্যাপচার ও EtherType তালিকাটি পরিবর্তন রেকর্ডের সঙ্গে সংযুক্ত করুন, কারণ পরের ব্যক্তিও একই প্রশ্ন করবে এবং পরিমাপটি পুনরাবৃত্তি করতে চাইবে না।

সম্পর্কিত নিবন্ধ