দুটি সাইট, একটি সাবনেট: প্রতিটির জন্য আলাদা এলিয়াস ভিউ তৈরি করুন

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

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

প্রতি সাইটে একটি এলিয়াস প্রিফিক্স বেছে নিন

প্রতিটি সাইটকে এমন একটি সম্পূর্ণ এলিয়াস প্রিফিক্স দিন যা এস্টেটে আর কারও নেই। দুই সাইটের পরিকল্পনায় সাইট A-এর 192.168.50.0/24 কে 172.21.10.0/24-তে এবং সাইট B-এর অভিন্ন ল্যানকে 172.21.20.0/24-তে ম্যাপ করা হতে পারে। ক্লাউড VPC ও অন্যান্য VPN পুলসহ প্রতিটি অংশগ্রহণকারী নেটওয়ার্কের বিরুদ্ধে প্রার্থীদের যাচাই করুন। ব্যক্তিগত ঠিকানা-স্থান প্রতিটি প্রতিষ্ঠান ভাগ করে, তাই কোনো রেঞ্জ RFC 1918 হওয়া মানে এখানে তা খালি — তা নয়।

দূরবর্তী ব্যবহারকারীদের কাছে নেটিভ সাবনেট নয়, এলিয়াসটি প্রকাশ করুন। নেটিভ রেঞ্জ স্থানীয় তথ্য হিসেবেই থাকে।

উভয় দিকেই অনুবাদ করুন

উভয় দিকেই অনুবাদ করুন। গন্তব্য ম্যাপিং মালিক সাইটে এলিয়াস ঠিকানাকে নেটিভ ঠিকানায় পুনর্লিখন করে। উৎস ম্যাপিং দূরবর্তী কলারকে এমন এলিয়াসে পুনর্লিখন করে যা অন্য সাইটগুলো আলাদা করতে পারে।

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

নীতি, সিলেক্টর ও রুট কোন পর্যায়ে প্রযোজ্য হয় তা পলিসি-ভিত্তিক IPsec, রুট-ভিত্তিক টানেল ও অন্যান্য পণ্যের মধ্যে আলাদা। আপনি যেটি চালান সেটির জন্য ডিজাইন করুন।

ওভারলে দিয়ে পরিকল্পনাটি বহন করুন

হাবে প্রতিটি এলিয়াস প্রিফিক্সকে তার মালিক সাইট-পথে দিন এবং কেবল কাজটির প্রয়োজনীয় ট্রানজিট অনুমোদন করুন। মেশে প্রতিটি প্রাসঙ্গিক পিয়ারের একই প্রিফিক্স ও নীতি-জ্ঞান দরকার। টানেল যোগ করা নিজে থেকে অস্পষ্ট ঠিকানাকরণ ঠিক করে না।

সম্পূর্ণ সাবনেট প্রকাশ একটি পরিষেবা প্রকাশের চেয়ে বিস্তৃত। যদি কেবল কয়েকটি মেশিন বা পোর্ট দরকার হয়, তবে অ্যাক্সেস নিয়মগুলো ম্যাপিংয়ের চেয়ে সংকীর্ণ রাখুন।

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

প্রত্যেক কলার যে নাম দেখে তা ঠিক করুন

রক্ষণাবেক্ষণ নামগুলোকে কলারের ভিউয়ের সঙ্গে মেলে এমন উত্তর দিন। দূরবর্তী প্রকৌশলী যদি একটি হোস্টনেম রিজলভ করেন, তবে তা সেই সাইটের এলিয়াস ঠিকানা ফেরত দেবে, ভাগ করা নেটিভ রেঞ্জ নয়।

প্রথম রক্ষণাবেক্ষণ উইন্ডোর আগে প্রতি সাইটে DNS ভিউ পরীক্ষা করুন। যে নাম নেটিভ সাবনেটে রিজলভ হয়, তা কলারকে সেই অস্পষ্টতায় ফিরিয়ে নেয় যা পরিকল্পনার অপসারণ করার কথা ছিল।

প্রতি সাইটে রেকর্ড করুন ও যাচাই করুন

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

তৃতীয় সাইট একই ডিফল্ট ল্যান নিয়ে এলে এই ইনভেন্টরিই পার্থক্যটি ধরে রাখে। পলিসি-ভিত্তিক IPsec NAT গাইড একটি নির্দিষ্ট অনুবাদ মডেল নথিভুক্ত করে; এটি প্রতিটি প্ল্যাটফর্মের জন্য চুক্তি নয়।