হাব ও স্পোক বনাম পূর্ণ মেশ: কোন VPN টপোলজি আপনার সাইটের জন্য মানানসই

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

অন্য কিছুর আগে পিয়ার সম্পর্কগুলো গুনুন

N সংখ্যক সাইটে পূর্ণ মেশের জন্য দরকার N গুণ N বিয়োগ এক, ভাগ দুই, টানেল; হাবের দরকার N। পাঁচটি সাইটে এটি দশ বনাম পাঁচ, যা এখনো সামলানো যায় বলে মনে হয়। পনেরোটিতে এটি 105 বনাম পনেরো, আর পার্থক্য আর গণিতের নয়, জনবলের।

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

সিদ্ধান্ত ট্রাফিকের মিশ্রণ নিক, ছবি নয়

যদি শাখার ট্রাফিক মূলত কেন্দ্রীয় ERP বা ফাইল ক্লাস্টারের অনুরোধ হয়, তবে হাব কোনো আপস নয়, এটিই সঠিক আকৃতি: ট্রাফিক আগেই সেখানে যেতে চেয়েছিল, আর একটি নীতির বিন্দু জোড়া-ভিত্তিক নিয়মের মেশের চেয়ে নিরীক্ষা করা সহজ। শাখাগুলো যখন একে অপরের সঙ্গে ডেটা বিনিময় করে তখন মেশ তার জটিলতার যোগ্য — দুই অফিসের মধ্যে প্রতিলিপি, সাইটগুলোর মধ্যে ভয়েস, ডজনখানেক প্রকৌশলী সারাদিন যে CAD শেয়ার খোলেন।

অস্বস্তিকর ঘটনাগুলো মাঝামাঝি থাকে, আর তারাই সংখ্যাগরিষ্ঠ। সংগঠন চার্ট থেকে অনুমান না করে তর্কের আগে মাপুন।

তালিকাটিকে নিয়ম নয়, নির্ণায়ক হিসেবে পড়ুন। চারটির মধ্যে তিনটি সারি এক দিকে ইঙ্গিত করলে সাধারণত ডিজাইন স্থির হয়; বিভাজন মানে হাইব্রিড, যা বেশিরভাগ পরিণত নেটওয়ার্ক শেষ পর্যন্ত চালায়ই।

হাবকে ফরওয়ার্ড করার নির্দেশ দিতে হয়

দুটি কার্যকর স্পোক-থেকে-হাব টানেল স্পোক-থেকে-স্পোক অ্যাক্সেস তৈরি করে না। হাবের দরকার IP ফরওয়ার্ডিং চালু, প্রতিটি স্পোক নেটওয়ার্কে একটি রুট, ট্রানজিটের অনুমতি দেয় এমন একটি ফায়ারওয়াল নিয়ম এবং ফেরত পথের হিসাব; প্রতিটি স্পোকের দরকার অন্য সাইটের প্রিফিক্সের জন্য একটি রুট। Linux হাবে এটি net.ipv4.ip_forward=1 সঙ্গে FORWARD একটি চেইন যা জোড়াটিকে নীরবে ফেলে না, আর নীতি-ভিত্তিক IPsec-এ এটি ট্রাফিক সিলেক্টর যা দুই প্রান্তে দূরবর্তী স্পোক সাবনেট তালিকাভুক্ত করে। strongSwan-এর ফরওয়ার্ডিং নোট কার্নেল ও ফায়ারওয়ালের দিকটি কভার করে, যখন সেটিই আপনার অনুপস্থিত স্তর। একটি সস্তা পরীক্ষা হলো এক স্পোক থেকে অন্যটির একটি সেবায় ট্রাফিক পাঠানো এবং হাবের কাউন্টার দেখতে থাকা; যে নিয়ম কখনো বাড়ে না, তার অর্থ ক্রমটি ভুল, রুটটি নয়।

কেন্দ্রীয় নীতি-ও দরকারি অংশ। শাখাগুলোকে একে অপরকে না পেয়েও ভাগ করা সেবায় পৌঁছানোর অনুমতি দেওয়া যায়, আর সেই অ্যাক্সেস ম্যাট্রিক্স স্পষ্টভাবে লিখে রাখা মূল্যবান। অনুপস্থিত রুট কোনো পাঠযোগ্য নিয়মের দুর্বল বিকল্প।

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

আগে ব্যর্থতা ডিজাইন করুন, পরে স্বাভাবিক পথ

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

মেশ সেই ঝুঁকি ছড়িয়ে দেয়: এক সাইটের লিংক নামলে অন্যগুলো বিচ্ছিন্ন হয় না। এটি সেই জায়গাগুলোও গুণ করে যেখানে পথ নির্বাচন আপনাকে অবাক করতে পারে, আর অ্যাপ্লিকেশন সেশন এখনো সাহায্য ছাড়া পথ পরিবর্তন টিকে যায় না।

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

পরিবর্তনের খরচে বেছে নিন, তারপর রুট যাচাই করুন

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

তারপর একটির বদলে দুটি ছবি যাচাই করুন। স্বাভাবিক পথের জন্য, traceroute প্রতিটি সাইট থেকে প্রতিটি সেবা প্রিফিক্সে এবং নিশ্চিত করুন হপগুলো ডায়াগ্রামের সঙ্গে মেলে। ব্যর্থতার পথের জন্য, একটি টানেল বন্ধ করুন এবং পুনরাবৃত্তি করুন, কারণ যে রুট কেবল সবকিছু চালু থাকলে কাজ করে তা ডিজাইন করা হয়নি, শুধু কনফিগার করা হয়েছে।

দুটি ছবিই অ্যাক্সেস ম্যাট্রিক্সের সঙ্গে রাখুন, এবং সাইট যোগ হলে সেগুলো আবার দেখুন; আপনি যে খরচ সামলাচ্ছেন তা পরবর্তী পরিবর্তনের খরচ, বর্তমান ছবির সৌন্দর্য নয়।