সাইটগুলি সংঘর্ষের আগে ব্যক্তিগত VPN ঠিকানা পরিসর পরিকল্পনা করুন

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

যে প্রতিটি স্পেস পৌঁছানোর যোগ্য তা তালিকাভুক্ত করুন

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

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

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

কেন একটি ওভারল্যাপ রাউটিং টেবিলকে পরাজিত করে

একটি রুট হলো একটি প্রিফিক্স এবং একটি পরবর্তী হপ, আর ফরওয়ার্ডিং দীর্ঘতম মিলে যাওয়া প্রিফিক্স বেছে নেয়। যখন দুটি পিয়ারই 192.168.1.0/24 দাবি করে, টেবিলে এর জন্য একটি এন্ট্রি থাকে, তাই উভয় সাইটের ট্রাফিক একই টানেল দিয়ে বেরিয়ে যায়। দ্বিতীয় সাইটটি ভুলভাবে কনফিগার করা নয়; এটি অগম্য কারণ প্রথমটি একই ঠিকানার জন্য উত্তর দেয়। কোনো মেট্রিক তাদের আলাদা করতে পারে না, কারণ মিলটি মেট্রিক দেখার আগেই ঘটে।

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

ক্লায়েন্ট পুল এবং সাইটের পরিসর সচেতনভাবে মাপুন

একটি VPN ক্লায়েন্ট পুল হলো এমন পরিসর যা গেটওয়ে একবারে একটি ঠিকানা দেয়, তাই এর আকার সমবর্তিতাকে সীমিত করে। একটি /24-এ 254টি ব্যবহারযোগ্য ঠিকানা থাকে, যা ছোট দলের জন্য উদার এবং কন্টেইনার চালায় এমন শাখার জন্য সংকীর্ণ; একটি /22 ব্যক্তিগত স্পেসে বাড়তি কোনো খরচ করে না এবং তর্ক দূর করে। পুলটিকে সংলগ্ন রাখুন এবং প্রতিটি সাইটের LAN থেকে দূরে রাখুন, যাতে ক্লায়েন্টের দিকে সারসংক্ষেপ রুট কোনো সাইটকে গিলে না ফেলে। পুল খালি থাকলেও পরিসরটি সংরক্ষিত রাখুন, কারণ লেখা হয়নি এমন পরিসরই পরবর্তী প্রকৌশলী বরাদ্দ করবেন।

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

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

অনুবাদ ও পুনঃসংখ্যায়ন ভিন্ন সমস্যার সমাধান করে

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

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

স্থাপনের আগে দূরের দিক থেকে পরীক্ষা করুন

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

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

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