শাখা ও গবেষণাগারের মধ্যে সংযোগের জন্য রাউটেড VPN নাকি ব্রিজড LAN

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

সংযোগের দুটি উপায়, একটি স্পষ্ট আপস

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

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

রাউটিং আপনাকে কী দেয়

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

তৃতীয়টি হল এটি টানেল আসলে যা বহন করে তার সঙ্গে মেলে। IPsec নীতি হল প্রিফিক্সের জোড়া, এবং প্রতিটি পাশে ফরওয়ার্ডিংয়ের পথ হল গেটওয়েতে ফরওয়ার্ডিং চালু থাকা সাধারণ IP রাউটিং:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

আপনি যা ছাড়েন তা হল সম্প্রচারের মাধ্যমে আবিষ্কার। এটি সত্যিকারের ক্ষতি এবং সবকিছু ব্রিজ করে এড়ানোর বদলে সচেতনভাবে প্রতিস্থাপন করা উচিত।

ব্রিজিংয়ের খরচ

ব্রিজিংকে লেয়ার 2 ফ্রেম টানেলের মধ্য দিয়ে বহন করতে হয়, অর্থাৎ সাধারণ নীতিভিত্তিক টানেলের বদলে IPsec-এর উপরে GRE বা VXLAN-এর মতো এনক্যাপসুলেশন। এটি থাকলে দুই সাইট একটি ব্যর্থতার ডোমেন ভাগ করে। Spanning tree টানেলকে লিঙ্ক হিসেবে দেখে, সম্প্রচার ট্রাফিক টানেলের ব্যান্ডউইথ খায়, এবং যে কোনো ডিভাইস কম বিলম্বের সেগমেন্ট ধরে নেয় সে এমনভাবে ভুল আচরণ করে যা কোনো প্রান্ত থেকে চিহ্নিত করা কঠিন।

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

নিরাপত্তার যুক্তিটিই সাধারণত সিদ্ধান্ত নেয়। ব্রিজ সেই সেগমেন্ট ছড়ায় যেখানে লিঙ্ক-লোকাল প্রোটোকল কাজ করে, তাই শাখার ডিভাইস এমন গবেষণাগার ডিভাইসের সঙ্গে কথা বলতে পারে যেগুলি কখনও বাইরে থেকে পৌঁছানোর মতো ছিল না। গবেষণাগারে একই সমতল নেটওয়ার্কে hypervisor, স্টোরেজ কনসোল ও ব্যবস্থাপনা ইন্টারফেস থাকলে এখন সেটি শাখাসহ একই সেগমেন্ট।

সম্প্রচার ছাড়া নাম

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

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

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

রাউটেড নকশা পরীক্ষাযোগ্য করুন

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

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

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